Re: old style tail(1) options and bin/57483

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 30 Jun 2023 15:37:02 +0300
    From:        Valery Ushakov <uwe%stderr.spb.ru@localhost>
    Message-ID:  <ZJ7Mbm3i0+b/UW4D%pony.stderr.spb.ru@localhost>

  | What exactly are we aiming for here?  Do we want to support postfix
  | options in something like old style +<n>qF ?

What we want I will leave for others to determine, but in v7 tail
there was a single (optional) "option" (must be argv[1] or nothing)
in the form +/- [NNN] [bclr]

That is, to be treated as this option it had to start with either '+' or '-'.
If one of those was the first char, then came an optional string of digits,
followed by one of 'b' 'c' 'l' or 'r' (or nothing at all).   Anything else
as the terminating char there was an error.  Anything following
that character (if present) was ignored.   If its first char was not '+'
or '-' argv[1] was simply ignored.

For 'r' a digit string (or missing one) with value 0 was treated as as
many lines as fit in the final 4KB (or something like that), and the lines
were printed "backwards" (last line first) - all other variants printed the
output in the order it appeared in the file.   For all other cases, a
digit string of 0 (or missing) just meant 0.   'b' multiplied that number
by 512 (ie: blocks) and then treated it as characters (like 'c').
'c' did nothing, the number was simply a char count, l (and r) caused the
number to mean lines.   Leading '+' skipped that much from the start of
the file, leading '-' started that much before the end of the file
(with caveats as to how much was possible).

If this option was missing, the default was "-10l".   (print the final 10
lines of the file).

Only one file was handled (and as usual, if no file arg was given, stdin
was used).   But somewhat bizarrely, the file arg had to be argv[2], if
argv[1] was present, but didn't start with a '+' or '-' it was simply
ignored (so "tail file" would read stdin, not file).

Supporting all of that certainly seems pointless, if not impossible.
Doing what tail's "obsolete()" function does, and looking for this
form of option, anywhere in the arg list, seems to simply be wrong.

The earliest CSRG version that is in the SCCS files, is from 1980,
and so probably for BSD 4.0 and already had added the 'f' option, and
allowed the 'b' 'c' 'l' and 'r' chars (and 'f') to follow the number
in any order, and any number of them (though obviously, some combinations
made no sense).   It still required the single file arg to be argv[2]
if present - that remained until what is close to our current version
arrived, the checkin log message says:
	new version from scratch; POSIX 1003.2 version
in July 1991 (which means that it would only have been in one or more
of the 4.4 (semi) releases I think, ie: not 4.3).

Until the new version appeared, with POSIX style options, there was still
just a single optional "option" and a single optional "file".

kre