Red Hat Bugzilla – Bug 173431
tail +N syntax broken / missing
Last modified: 2007-11-30 17:11:17 EST
Description of problem:
coreutils-5.93-1's tail no longer responds to the +N argument correctly,
where N is an integer.
In every version of tail I have ever used, on Linux / Solaris / Unix,
'tail +N' means 'cat the file from the Nth line' .
It means this on FC-4 ( coreutils-5.2.1-48.1 )
$ echo '1
3' > f
$ tail +2 f
$ tail -1 f
But no longer on FC-5 :
$ tail +2 f
tail: cannot open `+1' for reading: No such file or directory
==> f <==
This is most annoying, and will break many scripts that use the '+N' feature -
eg. the dhcdbd-1.9 Makefile, which will now have to use perl instead.
The +N feature is especially useful for use in conjunction with grep -n
to cat lines that follow the first matching line in a file.
Please give us back +N !
The correct syntax for this is "tail -n +2 f". You can get the old syntax
(which does not conform to the current POSIX spec) back like this:
seq 1 3 > f
tail +2 f
See the info page aobut this:
info coreutils "Standards Conformance"
*** Bug 203535 has been marked as a duplicate of this bug. ***
but then iÂ´am wondering - when the old syntax does not conform the current
POSIX spec, why the MAN pages says:
If the first character of N (the number of bytes or lines) is a +, print
beginning with the Nth item from the start of each file, otherwise, print
the last N items in the file.
Would it be possible to get a package with the functionallilty - like the MAN
Ehringer: you are mis-interpreting the man page. Here is what it actually says:
output the last N lines, instead of the last 10
If the first character of N (the number of bytes or lines) is a â+â,
In other words, the N here is the one from --lines=N. The case described is for
--lines=+1 (for example).
The '-n, --lines=N' syntax is the common way of describing that there is a short
option (-n) and a long option (--lines), both of which take an argument N. So
this is a short way of saying '-n N, --lines=N'.
*** Bug 203537 has been marked as a duplicate of this bug. ***
Sorry for misunderstood...
*** Bug 217174 has been marked as a duplicate of this bug. ***
*** Bug 229151 has been marked as a duplicate of this bug. ***