Bug 287751

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

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?

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

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

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
   3
   4
   5

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.

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
    3
    4
    5

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.

I'd like to ask as new maintainer of coreutils. 
Is this 'export _POSIX2_VERSION=199209' workaround sufficient for customers? 

I am adding Eric Sammons to the CC list for this.

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.

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.

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? 

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)
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Old-tail-plus-N-syntax-now-fails

*** Bug 458827 has been marked as a duplicate of this bug. ***