Bug 287751 - Regression in functionality of tail... breaking scripts.
Regression in functionality of tail... breaking scripts.
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: coreutils (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Ondrej Vasik
: Reopened
: 458827 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2007-09-12 11:22 EDT by Chuck Mead
Modified: 2010-10-22 14:35 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-07-18 03:57:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Chuck Mead 2007-09-12 11:22:46 EDT
Description of problem: tail +2 /etc/ntp.conf does not work as it used to on
rhel4 and before. This breaks pre-existing scripts and in a multi-version
(rhel3,4,5) environment requires multiple versions of the script to be created
and maintained.

Version-Release number of selected component (if applicable):

How reproducible:
for i in $(seq 1 13);do echo $i >> test;done
tail +2 test

Steps to Reproduce:
1. run tail using the + syntax
2. tail refuses to behave as it used to it spews the error "tail: cannot open
`+2' for reading: No such file or directory" and then displays the entire file.
Actual results:
tail refuses to behave as it used to. it spews the error "tail: cannot open `+2'
for reading: No such file or directory" and then displays the file contents.

[root@cnyeodgtw2-new /]# tail +2 test
tail: cannot open `+2' for reading: No such file or directory
==> test <==

Expected results:
[root@undertaker ~]# tail +2 test

Additional info:
Comment 1 Pete Graner 2007-09-21 14:54:54 EDT
This was is intentional behavior introducted by upstream, it is documented in
/usr/share/doc/coreutils-5.97/NEWS. I've pasted it here for reference:

 A few usages still have behavior that depends on which POSIX standard is
  being conformed to, and portable applications should beware these
  problematic usages.  These include:

    Problematic       Standard-conforming replacement, depending on
       usage            whether you prefer the behavior of:
                      POSIX 1003.2-1992    POSIX 1003.1-2001
    sort +4           sort -k 5            sort ./+4
    tail +4           tail -n +4           tail ./+4
    tail - f          tail f               [see (*) below]
    tail -c 4         tail -c 10 ./4       tail -c4
    touch 12312359 f  touch -t 12312359 f  touch ./12312359 f
    uniq +4           uniq -s 4            uniq ./+4

    (*) "tail - f" does not conform to POSIX 1003.1-2001; to read
    standard input and then "f", use the command "tail -- - f".

  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>.

Comment 2 Chuck Mead 2007-09-24 10:00:11 EDT
I will likely be adding more customer comments later but suffice it to say that
I strongly disagree with this type of decision being made. Our customers,
particularly ones with long standing cross platform environments (multiple
version of Unix and RHEL), depend on their scripts continuing to function as
they always have across all their *NIX platforms. To unilaterally make this
change without continuing to support the previous method is without question a
regression and it has genuine impact. To turn and point as the opengroup as the
reason is not justification in my mind for impacting our customers. Could we not
have supported the new "standard" decision taken while continuing to maintain
backwards compatibility?
Comment 3 Chuck Mead 2007-09-25 11:33:11 EDT
More comments from the customer:

"we all know that it's unlikely that redhat will provide a solution here. (this
is even before I entered this tkt). maybe it's time to talk to the account rep
from redhat, and ask, is redhat really serious about providing a enterprise
capable OS that their customers can trust. (instead of 'fix your script for
every (major?) release). we have to find out what the answer is for this
question, otherwise. most likely this issue will show up again. and next time.
it could cause more serious issue."
Comment 4 Chuck Mead 2007-09-25 11:34:17 EDT
More comments from the customer:

"the truth is, we do have a lot of lagacy scripts. and it will take a lot of
effort to rewrite them all to make them posix complaint. all other OS provides
backward compatibility, that make the point of rewriting old scripts even more
Comment 6 Pete Graner 2007-09-25 12:08:04 EDT
After digging around more, in this case talking to upstream there is an
environment var that will allow the usage of the old syntax:

   $ export _POSIX2_VERSION=199209
   $ seq 5 | tail +3

This could be added to the .bashrc, and to the /etc/skel/.bashrc to make sure
the behavior migrate to any new users, if that behavior is desired.

Comment 7 Jim Meyering 2007-09-26 17:32:25 EDT
Do these customers know about the _POSIX2_VERSION envvar
and how that can make tail accept the obsolete option syntax?
Just set it to the right number, and tail +10 will work again.

For example,

    $ export _POSIX2_VERSION=199209
    $ seq 5 | tail +3

So maybe all the customer needs to do is to add

  export _POSIX2_VERSION=199209

to some key .bashrc files?
Or even to the system-level /etc/* files.
Comment 8 Ondrej Vasik 2007-11-13 11:06:07 EST
I'd like to ask as new maintainer of coreutils. 
Is this 'export _POSIX2_VERSION=199209' workaround sufficient for customers? 
Comment 9 Chuck Mead 2008-01-23 13:47:31 EST
I am adding Eric Sammons to the CC list for this.
Comment 10 Stephen Murray 2008-02-27 12:22:40 EST
This change has just bitten us, some scripts written for AS3 and AS4 are now
failing under RHEL5. I don't think we make extensive use of "tail +n" but the
problem is that we really only find out when stuff stops working. I am reluctant
to add "export _POSIX2_VERSION=199209" to all my environments, it seems like a
big hammer that might swat more than just this little fly of a problem. Instead
I am adding it to the specific scripts that make use of this option as and when
I find them.

This kind of change makes linux look really bad, and makes upgrades to new
releases or patch levels a less attractive prospect.

BTW, the man and info pages for "tail" still refer to the deleted "+" option as
being valid.
Comment 11 Darin Langone 2008-03-28 09:06:34 EDT
Can we gat an update in this?  It's been well over 2 months since the last 
update.  As the previous comment states -
I am reluctant
to add "export _POSIX2_VERSION=199209" to all my environments, it seems like a
big hammer that might swat more than just this little fly of a problem.
I think that just about sums this up, ignoring this will not make it go away.
Comment 12 Ondrej Vasik 2008-03-28 09:42:06 EDT
I don't think that changing behaviour in tail in RHEL-5 is good way to go...
This may cause another broken scripts for those who already rely on new
behaviour. Therefore maybe I could recommend smaller hammer which will be much
less dangerous.
Simply add
alias tail="_POSIX2_VERSION=199209 tail" to .bashrc (or to other file at system
level) ... this will change the behaviour only for tail to the old style and
will not break anything else - cause the _POSIX2_VERSION will be not exported -
but used only for a single tail command.
Is the alias workaround more suitable? 
Comment 13 Ondrej Vasik 2008-07-18 03:57:12 EDT
Closing NOTABUG, as it is not regression, not even a bug and it is already
documented in info pages. Documenting in man pages was requested in
https://bugzilla.redhat.com/show_bug.cgi?id=447485 . Will do that for 5.3 . You
could check upstream faq about that change of behaviour as well, I recommend
usage of alias (as I recommended in comment #12)
Comment 14 Ondrej Vasik 2008-08-13 04:06:06 EDT
*** Bug 458827 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.