On Monday 17 March 2008, Shai Berger wrote: > On Monday 17 March 2008, Bob Proulx wrote: > > Shai Berger wrote: > > > That is, +3 is treated as a file-name instead of as --lines=+3, > > > like it always had, > > > > That behavior is intentional. Please see this FAQ entry for more > > information: > > > >http://www.gnu.org/software/coreutils/faq/#Old-tail-plus-N-syntax-now-fails > > I think that's a design mistake, but there's no use arguing about it on > this bug, is there?... >
Upon slightly deeper checking, maybe there is use arguing about it on this bug. There's two data points I want to bring: 1. The coreutils faq linked above says that tail's behavior was changed to conform with standards, arguing that > The problem is that “+” is a valid filename character and is not an > expected option character. Options are supposed to start with a “-” > character. It has always been a bad idea to eat up an additional character > as an additional option specifier. This is now no longer allowed by the > standards. The tail command is now required to respect that “+” is not an > option and treat it as a filename. and, quoting from the news file, that > These changes are in response to decisions taken in the January 2005 > Austin Group standardization meeting. For more details, please see > "Utility Syntax Guidelines" in the Minutes of the January 2005 > Meeting http://www.opengroup.org/austin/docs/austin_239.html. But if you look at these minutes, you see that they actually say the exact opposite: > tail: Add to the Rationale: "Earlier versions of this standard supported the > following forms in the Synopsis section: > > tail -[number][b|c|l][f] [file] > tail +[number][b|c|l][f] [file] > > These forms are no longer specified by this standard, but may be present in > some implementations." Also add to the OPTIONS "except that '+' may be > recognized as an option delimiter as well as '-'." + is explicitly allowed to specify options, and tail +N is specifically not disallowed. 2. As a comparison and reference, Cygwin includes a 'tail' that claims to be GNU coreutils tail 6.9 (as opposed to 6.10 in Sid), and supports tail +N. No POSIX* environment variable was set in either system. So if I get things correctly, POSIX 1003.1-2001 requires the obsolescence of tail +N. The decision at a later meeting, which is quoted as authoritative, is to revert this requirement. Some modern systems -- some distributions of recent versions of GNU coreutils -- followed this decision, but the Debian distribution chooses to follow the older standard. If things are as I described them, this seems like a valid bug in Debian coreutils (and a curious interpretation of the 2005 decision by GNU coreutils developers). What am I missing? Respectfully, Shai.
