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 2 3' > f $ tail +2 f 2 3 $ tail -1 f 3 But no longer on FC-5 : $ tail +2 f tail: cannot open `+1' for reading: No such file or directory ==> f <== 1 2 3 $ 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: export _POSIX2_VERSION=199209 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. ***
Hi, 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 pages saing?
Ehringer: you are mis-interpreting the man page. Here is what it actually says: -n, --lines=N 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. ***
Ok thanks! Sorry for misunderstood... # bye eike
*** Bug 217174 has been marked as a duplicate of this bug. ***
*** Bug 229151 has been marked as a duplicate of this bug. ***