Debian Bug report logs - #339085
coreutils: tail and sort does not recognize the option +n

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Stefan Luethje <stefan+debian@luethje.ch>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: coreutils: tail and sort does not recognize the option +n

Date: Mon, 14 Nov 2005 22:15:57 +0100

Package: coreutils
Version: 5.93-2
Severity: critical
Justification: breaks the whole system



-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14+mppe
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages coreutils depends on:
ii  libacl1                       2.2.32-1   Access control list shared library
ii  libc6                         2.3.5-7    GNU C Library: Shared libraries an

coreutils recommends no packages.

-- no debconf information

The programs tail and sort does not recognize the option +n:

tail +2 /etc/hosts
tail: cannot open `+2' for reading: No such file or directory

This breaks a lot of software and the result is garbage. The complete system can run into an undefined state.

Message #10 received at 339085-close@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: 339085-close@bugs.debian.org

Subject: Bug#339085: fixed in coreutils 5.93-3

Date: Mon, 14 Nov 2005 19:02:06 -0800

Source: coreutils
Source-Version: 5.93-3

We believe that the bug you reported is fixed in the latest version of
coreutils, which is due to be installed in the Debian FTP archive:

coreutils_5.93-3.diff.gz
  to pool/main/c/coreutils/coreutils_5.93-3.diff.gz
coreutils_5.93-3.dsc
  to pool/main/c/coreutils/coreutils_5.93-3.dsc
coreutils_5.93-3_i386.deb
  to pool/main/c/coreutils/coreutils_5.93-3_i386.deb
fileutils_5.93-3_all.deb
  to pool/main/c/coreutils/fileutils_5.93-3_all.deb
shellutils_5.93-3_all.deb
  to pool/main/c/coreutils/shellutils_5.93-3_all.deb
textutils_5.93-3_all.deb
  to pool/main/c/coreutils/textutils_5.93-3_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 339085@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Stone <mstone@debian.org> (supplier of updated coreutils package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Mon, 14 Nov 2005 20:55:57 -0500
Source: coreutils
Binary: shellutils coreutils fileutils textutils
Architecture: source all i386
Version: 5.93-3
Distribution: unstable
Urgency: low
Maintainer: Michael Stone <mstone@debian.org>
Changed-By: Michael Stone <mstone@debian.org>
Description: 
 coreutils  - The GNU core utilities
 fileutils  - The GNU file management utilities (transitional package)
 shellutils - The GNU shell programming utilities (transitional package)
 textutils  - The GNU text file processing utilities (transitional package)
Closes: 338821 339085
Changes: 
 coreutils (5.93-3) unstable; urgency=low
 .
   * Remove --enable-pam from selinux rules (we don't use our su for selinux)
   * [99] Revert change to POSIX version override (I forgot about +n usage)
     I once again *strongly* urge people to convert to more portable syntax.
     (search NEWS for POSIX 1003.1-2001)
     (Closes: #339085)
   * [57] Patch from Petr Salinger to fix selinux build problems on non-linux
     systems (Closes: #338821)
Files: 
 7dcbce4bb21ea00cde54dee820456c8c 959 utils required coreutils_5.93-3.dsc
 bca9ab2355d7da328b72ed59c0fbe579 43676 utils required coreutils_5.93-3.diff.gz
 c275da977abe96729aa075956826864a 9526 oldlibs extra textutils_5.93-3_all.deb
 ee810e44750effd1ed58f0284a5861f0 9516 oldlibs extra fileutils_5.93-3_all.deb
 87b41207777c746261fb987a2220fd6d 9524 oldlibs extra shellutils_5.93-3_all.deb
 41d5d7edd9818cd8a7ea0e609cb457a9 2864682 utils required coreutils_5.93-3_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iQCVAwUBQ3lMAQ0hVr09l8FJAQIKwgQAo+DJHdtFRZTpHlInrLaez5BKiyEntIjG
6pQ8Laag3kCzawiMt0LNVbRbDulHW0u7YsxLrrntEkR18gh2h5BbSJpYTNcMl2i1
w25BFlHc1vDcfgp51nKjRV08RGHfHa2bxpBqLnu1+GCgrg5lOqXjah+xyKd8V5Yf
9QJgTfcrfQw=
=RUmf
-----END PGP SIGNATURE-----

Message #15 received at 339085@bugs.debian.org (full text, mbox, reply):

From: Josh Triplett <josh@freedesktop.org>

To: 339085@bugs.debian.org

Subject: tail +n stopped working again

Date: Thu, 25 May 2006 17:24:06 -0700

[Message part 1 (text/plain, inline)]

reopen 339085
thanks

[control BCCed]

$ seq 1 10 | tail +5
tail: cannot open `+5' for reading: No such file or directory

- Josh Triplett

[signature.asc (application/pgp-signature, attachment)]

Message #22 received at 339085@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: Josh Triplett <josh@freedesktop.org>, 339085@bugs.debian.org

Subject: Re: Bug#339085: tail +n stopped working again

Date: Thu, 25 May 2006 20:59:51 -0400

On Thu, May 25, 2006 at 05:24:06PM -0700, you wrote:
>$ seq 1 10 | tail +5
>tail: cannot open `+5' for reading: No such file or directory

Yeah, it's intentional (see changelog). I don't intend for this version 
to enter testing yet, so people reading this please don't be tempted to 
close or downgrade the bug. 

Mike Stone

Message #29 received at 339085@bugs.debian.org (full text, mbox, reply):

From: Josh Triplett <josh@freedesktop.org>

To: Michael Stone <mstone@debian.org>

Cc: 339085@bugs.debian.org

Subject: Re: Bug#339085: tail +n stopped working again

Date: Thu, 25 May 2006 20:22:41 -0700

[Message part 1 (text/plain, inline)]

Michael Stone wrote:
> On Thu, May 25, 2006 at 05:24:06PM -0700, you wrote:
>> $ seq 1 10 | tail +5
>> tail: cannot open `+5' for reading: No such file or directory
> 
> Yeah, it's intentional (see changelog). I don't intend for this version
> to enter testing yet, so people reading this please don't be tempted to
> close or downgrade the bug.

I had already seen the changelog entry.  I reopened the bug to request
that this syntax continue to work.  How often do people tail files named
with a plus sign follwed by a number (and can't just use tail ./+NUM or
tail -- +NUM), versus how many people have tail +NUM burned into finger
memory?  The same applies to sort +NUM.  Furthermore, third-party
software will likely still rely on this for quite some time to come.  I
do agree that packages should get fixed to avoid this issue by using
tail -n +NUM and sort -k NUM+1, and all the packages in Debian may even
have these fixes in place already (though it looks like they don't; see
368909 for an example regarding usage of sort +NUM in cvs), but changing
tail and sort to no longer support this behavior for interactive use or
third-party software violates user expectations in a big way.

If you *do* decide to go this route, then at a minimum this change needs:
* An entry in debian/NEWS.Debian.gz , including an explanation of the
environment variable setting (_POSIX2_VERSION=199209) needed to get the
previous behavior, and a pointer to 'info coreutils "Standards
conformance"',
* A note in the tail and sort manpages, including the same explanation
and pointer,
* A mail to various appropriate places, including debian-user,
debian-devel-announce, and anywhere else that seems appropriate, and
* An extremely good justification for why we should break this syntax,
and what it gains us to do so.  "Precisely conform to POSIX 1003.1-2001"
by itself may or may not qualify.  This justification should get
included in all three of the above.

- Josh Triplett

[signature.asc (application/pgp-signature, attachment)]

Message #34 received at 339085@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: 339085@bugs.debian.org

Subject: coreutils and posix compliance changes

Date: Sat, 27 May 2006 13:19:29 -0400

See 5.96-3 for my current strategy for dealing with these changes.

Mike Stone

Message #39 received at 339085@bugs.debian.org (full text, mbox, reply):

From: Adeodato Simó <dato@net.com.org.es>

To: Michael Stone <mstone@debian.org>, 339085@bugs.debian.org

Subject: Re: coreutils and posix compliance changes

Date: Wed, 31 May 2006 02:50:29 +0200

* Michael Stone [Sat, 27 May 2006 13:19:29 -0400]:

> See 5.96-3 for my current strategy for dealing with these changes.

Can this bug be closed, then?

-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
                                  Listening to: Javier Álvarez - Goodbye

Message #44 received at 339085@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: Adeodato Simó <dato@net.com.org.es>

Cc: 339085@bugs.debian.org

Subject: Re: coreutils and posix compliance changes

Date: Tue, 30 May 2006 22:27:08 -0400

On Wed, May 31, 2006 at 02:50:29AM +0200, Adeodato Simó wrote:
>* Michael Stone [Sat, 27 May 2006 13:19:29 -0400]:
>> See 5.96-3 for my current strategy for dealing with these changes.
>
>Can this bug be closed, then?

No. I'd like to see how it goes before the package migrates to testing.

Mike Stone

Message #49 received at 339085@bugs.debian.org (full text, mbox, reply):

From: Zack Weinberg <zackw@panix.com>

To: Debian Bug Tracking System <339085@bugs.debian.org>

Subject: coreutils: You can't make this change. Not now, and quite probably never.

Date: Fri, 02 Jun 2006 20:35:07 -0700

Package: coreutils
Version: 5.96-3
Followup-For: Bug #339085

I want to add emphasis and additional justification to Josh Triplett's
request that the old (POSIX-1992) command line syntax continue to work.

On this issue, I speak primarily as a (semi-retired) GCC maintainer.
Every other month or so for the past few years - ever since upstream
coreutils dropped the old syntax - someone has tried to build GCC on
top of a hand-built coreutils, found that the configure script relies
on the old syntax, and complained to the mailing list.  We then would
have to explain to this person that the configure script cannot be
updated to the new syntax.

Yes, I said *can not* be updated.  You see, GCC still supports systems
other than bleeding edge GNU... in particular, it still supports systems
where the coreutils equivalent had its functionality *frozen*, in every
detail, as of POSIX-1992.  I know for a fact that this is the case for
releases of Solaris up to and including (2.)8, and I strongly suspect
it is still true even for the most recent releases.  It has also been
reported to be the case for various releases of HP-UX and AIX.  On these
systems, POSIX-2001 syntax like "tail -n 1" simply *does not work*.

Now, personally I would be quite happy to see all such obsolete
proprietary Unixes die the death, but that's not the world we live in
today, and I doubt it will happen - not for at least another decade.
Therefore, people writing portable shell scripts have to keep using the
old syntax, and that means GNU coreutils needs to keep supporting it.
In the default mode, and without any diagnostics.

I am cranky about this because I've explained it over and bloody over
again to the aforementioned people who are confused why they can't build
GCC, and I've also explained it over and over to coreutils upstream, who
just do not seem to understand why they are wrong to hew to the letter of
POSIX-2001.  See http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00102.html
for my most recent go-round with coreutils upstream -- I disagree with
some of the things he says in response but did not have time to continue
the argument; in particular, he says "yabbut +n syntax isn't portable
either" when he could make it be so by ceasing this silly insistence on
removing it.

I advise in the strongest possible terms that Debian just plain ignore
upstream on this issue, and leave POSIX-1992 the default, ideally
forever.  And, moreover, please stop advocating that people change their
scripts, because some of us can't, and we're tired of the nagging.

zw

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-686-smp
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages coreutils depends on:
ii  libacl1                       2.2.37-1   Access control list shared library
ii  libc6                         2.3.6-9    GNU C Library: Shared libraries
ii  libselinux1                   1.30-1     SELinux shared libraries

coreutils recommends no packages.

-- no debconf information

Message #54 received at 339085@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: Zack Weinberg <zackw@panix.com>, 339085@bugs.debian.org

Subject: Re: Bug#339085: coreutils: You can't make this change. Not now, and quite probably never.

Date: Sat, 03 Jun 2006 08:03:30 -0400

On Fri, Jun 02, 2006 at 08:35:07PM -0700, you wrote:
>detail, as of POSIX-1992.  I know for a fact that this is the case for
>releases of Solaris up to and including (2.)8, and I strongly suspect

That's simply not true. Solaris has obsolete syntax in /usr/bin, and 
more modern syntax in /usr/xpg4/bin. So, for example, /usr/xpg4/bin/tail 
-n 2 will work even if /usr/bin/tail -n 2 doesn't. That's been true 
since at least solaris 2.5, which was end-of-lifed in 1999. This sounds 
to me more like not understanding solaris' path structure than an actual 
issue. HP/UX has been supporting -n syntax and calling +N syntax 
obsolete at least since version 10. AIX since at least 4.something. The 
-n syntax was a part of the older POSIX release, so anything calling 
itself POSIX 1992 compliant should be able to support it.

Mike Stone

Message #59 received at 339085@bugs.debian.org (full text, mbox, reply):

From: bob@proulx.com (Bob Proulx)

To: Zack Weinberg <zackw@panix.com>, 339085@bugs.debian.org

Subject: Re: Bug#339085: coreutils: You can't make this change. Not now, and quite probably never.

Date: Sat, 3 Jun 2006 08:34:47 -0600

Zack Weinberg wrote:
> It has also been reported to be the case for various releases of
> HP-UX and AIX.  On these systems, POSIX-2001 syntax like "tail -n 1"
> simply *does not work*.

Just a detail clarification...
HP-UX 10.20, arguably the oldest HP-UX version still in active use
anywhere, supports the 'tail -n#' syntax.  It was released in 1996 and
it was officially at end of life in mid 2003[1][2].

Bob

[1]  http://www.hp.com/softwarereleases/releases-media2/history/slide2.html

[2]  http://www.hp.com/softwarereleases/releases-media2/discon/0303.htm

Message #64 received at 339085@bugs.debian.org (full text, mbox, reply):

From: "Zack Weinberg" <zackw@panix.com>

To: "Michael Stone" <mstone@debian.org>

Cc: 339085@bugs.debian.org

Subject: Re: Bug#339085: coreutils: You can't make this change. Not now, and quite probably never.

Date: Sat, 3 Jun 2006 12:56:30 -0700

On 6/3/06, Michael Stone <mstone@debian.org> wrote:
> On Fri, Jun 02, 2006 at 08:35:07PM -0700, you wrote:
> >detail, as of POSIX-1992.  I know for a fact that this is the case for
> >releases of Solaris up to and including (2.)8, and I strongly suspect
>
> That's simply not true. Solaris has obsolete syntax in /usr/bin, and
> more modern syntax in /usr/xpg4/bin.

Yes, I'm aware.  However, a portable shell script cannot assume
/usr/xpg4/bin is in PATH, nor can it add it, nor can it go and invoke
/usr/xpg4/bin/foo explicitly (the user may have gone to some trouble
to install shell utilities that they want used, and set PATH
accordingly); so in practice, what I said remains true.

[And, for the record, official end-of-life dates have approximately
zero effect on whether or not GCC drops support for a system, and are
therefore not useful evidence for this argument.]

zw

Message #69 received at 339085@bugs.debian.org (full text, mbox, reply):

From: "Zack Weinberg" <zackw@panix.com>

To: "Bob Proulx" <bob@proulx.com>

Cc: 339085@bugs.debian.org

Subject: Re: Bug#339085: coreutils: You can't make this change. Not now, and quite probably never.

Date: Sat, 3 Jun 2006 13:02:14 -0700

On 6/3/06, Bob Proulx <bob@proulx.com> wrote:
> Just a detail clarification...
> HP-UX 10.20, arguably the oldest HP-UX version still in active use
> anywhere, supports the 'tail -n#' syntax.

Are you absolutely certain that the version of tail in /bin or
/usr/bin supports that syntax?  I have  this dim memory that the
situation was similar to Solaris - i.e. modern tools in
/usr/something/bin, not in /usr/bin, portable scripts are still hosed.
They certainly did do similar crazy things for the sake of backward
compatibility, e.g. requiring you to add a special object to the link
if you wanted your binaries to honor SIGXCPU, because SIGXCPU was only
in Unix95...

zw

Message #74 received at 339085@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: Zack Weinberg <zackw@panix.com>

Cc: 339085@bugs.debian.org

Subject: Re: Bug#339085: coreutils: You can't make this change. Not now, and quite probably never.

Date: Sat, 03 Jun 2006 21:24:56 -0400

On Sat, Jun 03, 2006 at 12:56:30PM -0700, Zack Weinberg wrote:
>[And, for the record, official end-of-life dates have approximately
>zero effect on whether or not GCC drops support for a system, and are
>therefore not useful evidence for this argument.]

Frankly, that's your problem, not my problem.

Mike Stone

Message #79 received at 339085@bugs.debian.org (full text, mbox, reply):

From: "Zack Weinberg" <zackw@panix.com>

To: "Michael Stone" <mstone@debian.org>

Cc: 339085@bugs.debian.org

Subject: Re: Bug#339085: coreutils: You can't make this change. Not now, and quite probably never.

Date: Sat, 3 Jun 2006 19:30:34 -0700

On 6/3/06, Michael Stone <mstone@debian.org> wrote:
> On Sat, Jun 03, 2006 at 12:56:30PM -0700, Zack Weinberg wrote:
> >[And, for the record, official end-of-life dates have approximately
> >zero effect on whether or not GCC drops support for a system, and are
> >therefore not useful evidence for this argument.]
>
> Frankly, that's your problem, not my problem.

The way I see it,  as long as upstream and 3rd-party software
developers are in the position GCC is in - and GCC continues to
support such old systems because our users demand it, not because we
want to - the constraints those old systems place on our shell
scripting  *are* your problem.

But let's back off a level here.  Please explain to me why you want to
make posix.2001 the default.  It is not a thing I see any benefit to,
and therefore the negative consequences loom much larger in my mind
than they do in yours.  I assume you do see some benefit to it or you
wouldn't be advocating it...  I'm willing to be convinced.

zw

Message #84 received at 339085@bugs.debian.org (full text, mbox, reply):

From: bob@proulx.com (Bob Proulx)

To: Zack Weinberg <zackw@panix.com>

Cc: 339085@bugs.debian.org

Subject: Re: Bug#339085: coreutils: You can't make this change. Not now, and quite probably never.

Date: Sat, 3 Jun 2006 22:16:54 -0600

Zack Weinberg wrote:
> Bob Proulx wrote:
> > Just a detail clarification...
> > HP-UX 10.20, arguably the oldest HP-UX version still in active use
> > anywhere, supports the 'tail -n#' syntax.
> 
> Are you absolutely certain that the version of tail in /bin or
> /usr/bin supports that syntax?

Yes.  I am absolutely certain.  This was my main desktop for years and
years and I still have it up and running today.

  printf "one\ntwo\nthree\n" | /usr/bin/tail -n2
  two
  three
  uname -a
  HP-UX hpbox B.10.20 A 9000/785 2003339568 two-user license
  model
  9000/785/C360
  /usr/bin/tail -?
  Usage: tail [-f] [-b number] [file]
         tail [-f] [-c number] [file]
         tail [-f] [-n number] [file]
  Obsolescent usage: tail [+-[n][l|b|c]] [-f] [file]

> I have this dim memory that the situation was similar to Solaris -
> i.e. modern tools in /usr/something/bin, not in /usr/bin, portable
> scripts are still hosed.

On HP-UX 10.01 and later /bin and /usr/bin were combined into /usr/bin
and /bin is now a symlink to /usr/bin.  Similarly for /lib which is
now a symlink to /usr/lib.  Theoretically use of /bin is deprecated
there but obviously there needs to be /bin/sh or all #!/bin/sh scripts
would be broken and so the /bin symlink can never go away.  But this
means there is only one main bin directory and that is /usr/bin with
all programs in it.

HP-UX does funny things with tools installed in /opt/<package>/bin
where paths to those tools are listed in /etc/PATH and /etc/profile
includes all /etc/PATH paths into your PATH at login time.  This means
that after installation you must log out and log back in to get your
PATH set up correctly.  That is an unfortunate design choice akin to
some operating systems requiring a reboot after software installation.
Note that RH also has a similar design problem with their use of
/etc/profile.d/* scripts so this is not solely an HP-UX problem.

Additionally there is /usr/ccs/bin which is where the native K&R
compiler and linker live.  On HP-UX /usr/ccs/bin is required to be in
PATH in addition to /usr/bin.  But that is the old K&R compiler and
not the modern ANSI compiler.  Included in /opt is /opt/ansic/bin
which is where the c89 ANSI compiler lives if installed.  But again in
both cases the paths to them are included in the file /etc/PATH and
are placed into the PATH by /etc/profile at login time.  I don't
prefer the design choice but it *is* functional as installed, just not
pretty.  Also note that on a minimum system only the old K&R compiler
is installed in /usr/ccs/bin and the c89 ANSI compiler is an
additional optional product in /opt/ansic/bin which may not be
installed at all.

> They certainly did do similar crazy things for the sake of backward
> compatibility, e.g. requiring you to add a special object to the
> link if you wanted your binaries to honor SIGXCPU, because SIGXCPU
> was only in Unix95...

Yes.  And the 'ps -H' as in 'ps -efH' option to sort by parent-child
process relationship is only available if the UNIX95 variable is set.
I have an alias ps='UNIX95=1 ps' just for that reason.  And there are
other things too.

Bob

Message #89 received at 339085@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: Zack Weinberg <zackw@panix.com>

Cc: 339085@bugs.debian.org

Subject: Re: Bug#339085: coreutils: You can't make this change. Not now, and quite probably never.

Date: Sun, 04 Jun 2006 07:36:15 -0400

On Sat, Jun 03, 2006 at 07:30:34PM -0700, Zack Weinberg wrote:
>The way I see it,  as long as upstream and 3rd-party software
>developers are in the position GCC is in - and GCC continues to
>support such old systems because our users demand it, not because we
>want to - the constraints those old systems place on our shell
>scripting  *are* your problem.

The bottom line is that the functionality does exist, there is a way to 
use it, and you choose not to do so. I don't think it is reasonable to 
expect that unix froze 15 years ago and can never change. If you make a 
decision that something has to work on a bunch of obsolete platforms, 
you're going to have to go through gyrations to make it happen. If your 
instructions can't say "put /usr/xpg4/bin at the front of the path", 
that's your choice--but don't expect it to constrain the rest of the 
world. The reason you're in that situation is that sun decided more than 
decade ago that a transition was too hard. I wonder if they thought at 
the time that they'd be frozen in place for this long.

Mike Stone

Message #94 received at 339085@bugs.debian.org (full text, mbox, reply):

From: Pierre Habouzit <pierre.habouzit@m4x.org>

To: Michael Stone <mstone@debian.org>, 339085@bugs.debian.org

Cc: Zack Weinberg <zackw@panix.com>

Subject: Re: Bug#339085: coreutils: You can't make this change. Not now, and quite probably never.

Date: Sun, 4 Jun 2006 14:02:58 +0200

[Message part 1 (text/plain, inline)]

Le Dim 4 Juin 2006 13:36, Michael Stone a écrit :
> On Sat, Jun 03, 2006 at 07:30:34PM -0700, Zack Weinberg wrote:
> >The way I see it,  as long as upstream and 3rd-party software
> >developers are in the position GCC is in - and GCC continues to
> >support such old systems because our users demand it, not because we
> >want to - the constraints those old systems place on our shell
> >scripting  *are* your problem.
>
> The bottom line is that the functionality does exist, there is a way
> to use it, and you choose not to do so. I don't think it is
> reasonable to expect that unix froze 15 years ago and can never
> change. If you make a decision that something has to work on a bunch
> of obsolete platforms, you're going to have to go through gyrations
> to make it happen. If your instructions can't say "put /usr/xpg4/bin
> at the front of the path", that's your choice--but don't expect it to
> constrain the rest of the world. The reason you're in that situation
> is that sun decided more than decade ago that a transition was too
> hard. I wonder if they thought at the time that they'd be frozen in
> place for this long.

what is the point of not supporting tail +n syntax, does it breaks 
anything ?
-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[Message part 2 (application/pgp-signature, inline)]

Message #99 received at 339085@bugs.debian.org (full text, mbox, reply):

From: "Zack Weinberg" <zackw@panix.com>

To: "Michael Stone" <mstone@debian.org>

Cc: 339085@bugs.debian.org

Subject: Re: Bug#339085: coreutils: You can't make this change. Not now, and quite probably never.

Date: Sun, 4 Jun 2006 12:57:35 -0700

I could say that I think you're seriously underestimating the problem
here, but you probably think I'm seriously overestimating it, and
we're not going to get anywhere playing is-not, is-so games.

Instead, I'll ask again: What do you see as the advantage of removing
support for these older command line syntaxes?  I would be a lot less
hostile to the change if I could see any upside at all.  (I disbelieve
that the amount of code necessary to support them is significant.)

zw

Message #104 received at 339085@bugs.debian.org (full text, mbox, reply):

From: bob@proulx.com (Bob Proulx)

To: Pierre Habouzit <pierre.habouzit@m4x.org>, 339085@bugs.debian.org

Subject: Re: Bug#339085: coreutils: You can't make this change. Not now, and quite probably never.

Date: Sun, 4 Jun 2006 22:05:56 -0600

Pierre Habouzit wrote:
> what is the point of not supporting tail +n syntax, does it breaks 
> anything ?

A conforming POSIX 1003.1-2001 implementation is supposed to treat
arguments with a leading "+" as a file name, not as an option.  Some
people do actually start file names with a "+" sign.  (Often used in
GNU arch projects for one example.)  There is no way to make everyone
happy.

  printf "one\ntwo\nthree\n" > ++foo
  tail ++foo
  tail: +: invalid suffix character in obsolescent option

  printf "one\ntwo\nthree\n" > +1
  tail +1
  ...hang reading stdin instead of file +1...

Both of those examples work with POSIX conforming implementations.

Bob

Message #109 received at 339085@bugs.debian.org (full text, mbox, reply):

From: Pierre Habouzit <pierre.habouzit@m4x.org>

To: Bob Proulx <bob@proulx.com>, 339085@bugs.debian.org

Subject: Re: Bug#339085: coreutils: You can't make this change. Not now, and quite probably never.

Date: Mon, 5 Jun 2006 10:54:28 +0200

[Message part 1 (text/plain, inline)]

Le Lun 5 Juin 2006 06:05, Bob Proulx a écrit :
> Pierre Habouzit wrote:
> > what is the point of not supporting tail +n syntax, does it breaks
> > anything ?
>
> A conforming POSIX 1003.1-2001 implementation is supposed to treat
> arguments with a leading "+" as a file name, not as an option.  Some
> people do actually start file names with a "+" sign.
well, I can see a good compromise here: +[0-9][0-9]* can be treated 
as -n $1 whereas any other +.... can be treated as a file.

> (Often used in GNU arch projects for one example.)
right, I already new that choice of names was crappy, here is 
yet-another-reason.

> There is no way to make everyone happy.
>
>   printf "one\ntwo\nthree\n" > ++foo
>   tail ++foo
>   tail: +: invalid suffix character in obsolescent option

which is understood correctly if you auto-guess that ++foo is in fact a 
file.

>   printf "one\ntwo\nthree\n" > +1
>   tail +1
>   ...hang reading stdin instead of file +1...

someone writing that is completely crazy and there is a simple way to do 
that without depending on the implementation:

  tail -- +1

I really am convinced that change would make more harm that il would 
avoid.
-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[Message part 2 (application/pgp-signature, inline)]

Message #114 received at 339085@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: Pierre Habouzit <pierre.habouzit@m4x.org>, 339085@bugs.debian.org

Subject: Re: Bug#339085: coreutils: You can't make this change. Not now, and quite probably never.

Date: Mon, 05 Jun 2006 05:49:33 -0400

On Mon, Jun 05, 2006 at 10:54:28AM +0200, Pierre Habouzit wrote:
>I really am convinced that change would make more harm that il would 
>avoid.

Fine, argue upstream & with the posix committee. 

Mike Stone

Message #119 received at 339085@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@not.so.argh.org>

To: 339085@bugs.debian.org

Subject: coreutils: keep +n-syntax

Date: Mon, 5 Jun 2006 12:38:23 +0200

* Michael Stone (mstone@debian.org) [060605 12:22]:
> On Mon, Jun 05, 2006 at 10:54:28AM +0200, Pierre Habouzit wrote:
> >I really am convinced that change would make more harm that il would 
> >avoid.
> 
> Fine, argue upstream & with the posix committee. 

Hm, seems that I missed that posix now requires us to not allow +n
anymore. When was that added?


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/

Message #124 received at 339085@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: Andreas Barth <aba@not.so.argh.org>, 339085@bugs.debian.org

Subject: Re: Bug#339085: coreutils: keep +n-syntax

Date: Mon, 05 Jun 2006 07:03:26 -0400

On Mon, Jun 05, 2006 at 12:38:23PM +0200, you wrote:
>* Michael Stone (mstone@debian.org) [060605 12:22]:
>> On Mon, Jun 05, 2006 at 10:54:28AM +0200, Pierre Habouzit wrote:
>> >I really am convinced that change would make more harm that il would 
>> >avoid.
>> 
>> Fine, argue upstream & with the posix committee. 
>
>Hm, seems that I missed that posix now requires us to not allow +n
>anymore. When was that added?

The 2001 version finally removed the +n form, which was marked as 
obsolescent for a long time prior to that. It's part of an ongoing 
effort to rationalize the standard utilities. (They should all follow 
the "utility syntax guidelines"[1], so there are fewer special cases to 
worry about.) The only exception I can think of offhand is dd, which is 
such a martian that there's no chance of sanely transitioning it.

Mike Stone

1. http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap12.html#tag_12_02

Message #129 received at 339085@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@not.so.argh.org>

To: 339085@bugs.debian.org

Subject: Re: Bug#339085: coreutils: keep +n-syntax

Date: Mon, 5 Jun 2006 14:00:15 +0200

* Michael Stone (mstone@debian.org) [060605 13:41]:
> On Mon, Jun 05, 2006 at 12:38:23PM +0200, you wrote:
> >Hm, seems that I missed that posix now requires us to not allow +n
> >anymore. When was that added?

> The 2001 version finally removed the +n form, which was marked as 
> obsolescent for a long time prior to that.

Well, as far as I know rules there are three cases:
1. "You must do foo"
2. "You must not do foo"
3. no regulation about foo

For tool implementors, 3. is no rule. For tool users, 3. means that you
cannot rely on foo being done or not if your tools by that standard;
they might however do so because they follow different standards / are
backwards-compatible / ...

Up to now, I was under the impression that the +n-syntax falls in posix
under case 3.

However, if you discuss with upstream authors about stopping to use +n
in scripts, they usually say that this is a non-option for them, as they
cannot give up on the old non-posix compatible systems. For debian, it
is of course way easier - but then you have a (even if small) patch to
maintain, which puts additional maintainer costs on you for very small
value. (I'm not argueing about maintainer scripts - they should be
posix of course, as there is no upstream.)

So, the question is, what do we gain on either way:

- remove +n-syntax:
  - reduces code base;
  - no need to maintain extra patch to keep +n (unless we can convince
    upstream also :)
- keep +n-syntax:
  - no need to maintain extra patches relative to upstream in lots of
    packages;
  - old shell scripts still run; [1]


Of course, if you prefer that I discuss this with upstream, I could do
that. However, I believe that the proper way to deal with requests is to
discuss that with the Debian maintainer(s), and only if they tell
someone to speak with upstream, do it.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/

Message #134 received at 339085@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: Andreas Barth <aba@not.so.argh.org>, 339085@bugs.debian.org

Subject: Re: Bug#339085: coreutils: keep +n-syntax

Date: Mon, 05 Jun 2006 10:16:25 -0400

On Mon, Jun 05, 2006 at 02:00:15PM +0200, you wrote:
>Up to now, I was under the impression that the +n-syntax falls in posix
>under case 3.

No, up to now it was specifically allowed for legacy reasons. When that 
was removed, it falls back to normal argument syntax. Extensions which 
begin with "-" meet the syntax guidelines, but extensions which begin 
with "+" do not. Again, this is to reduce surprise for users, who are 
told "posix command arguments begin with '-'".

>Of course, if you prefer that I discuss this with upstream, I could do
>that. However, I believe that the proper way to deal with requests is to
>discuss that with the Debian maintainer(s), and only if they tell
>someone to speak with upstream, do it.

I already did so--I have absolutely no interest in debating this.

Mike Stone

Message #139 received at 339085@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@not.so.argh.org>

To: Michael Stone <mstone@debian.org>

Cc: 339085@bugs.debian.org

Subject: Re: Bug#339085: coreutils: keep +n-syntax

Date: Mon, 5 Jun 2006 16:23:37 +0200

* Michael Stone (mstone@debian.org) [060605 16:16]:
> On Mon, Jun 05, 2006 at 02:00:15PM +0200, you wrote:
> >Of course, if you prefer that I discuss this with upstream, I could do
> >that. However, I believe that the proper way to deal with requests is to
> >discuss that with the Debian maintainer(s), and only if they tell
> >someone to speak with upstream, do it.
> 
> I already did so--I have absolutely no interest in debating this.

Ok, what is the best place to discuss this?

Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/

Message #144 received at 339085@bugs.debian.org (full text, mbox, reply):

From: bob@proulx.com (Bob Proulx)

To: Andreas Barth <aba@not.so.argh.org>, 339085@bugs.debian.org

Subject: Re: Bug#339085: coreutils: keep +n-syntax

Date: Mon, 5 Jun 2006 23:03:51 -0600

Andreas Barth wrote:
> Ok, what is the best place to discuss this?

The GNU coreutils home page is here:

  http://www.gnu.org/software/coreutils/

The best place to discuss upstream GNU coreutils issues is on the
bug-coreutils@gnu.org mailing list.  You do not need to be subscribed
to post there but I will encourage it anyway.

  http://lists.gnu.org/mailman/listinfo/bug-coreutils

This topic has been discussed at length upstream previously.  The
mailing list archives are located here:

  http://lists.gnu.org/archive/html/bug-coreutils/

Sarching for "POSIX 1003.1-2001 tail" should give quite a few related
hits on previous discussions of this.

Bob

Message #149 received at 339085@bugs.debian.org (full text, mbox, reply):

From: "Albert Cahalan" <acahalan@gmail.com>

To: 339085@bugs.debian.org, mstone@debian.org, zackw@panix.com, bob@proulx.com

Subject: this matters

Date: Sun, 18 Jun 2006 13:07:36 -0400

I'm on the austin-group mailing list, which is the discussion
list for the POSIX committee.

According to discussion on the austin-group mailing list,
the POSIX spec never intended to disallow the traditional
syntax. Very rarely is traditional syntax disallowed, and only
with some major justification.

Normally I'd say the POSIXLY_CORRECT environment
variable would be useful, but this isn't even a correct
interpretation of POSIX!

As for Solaris, /usr/xpg4/bin is not normally used. Sun put
it there as a checkbox item. It's about as relevant as the
POSIX subsystem provided with Windows.

Then again, that points to a solution. If the Solaris way
is any example to be used, then we can do likewise.
Install the defective "tail" and "head" in /usr/xpg4/bin
where it won't bother anybody.

SGI tends to require that an environment variable _XPG
be set to a positive integer. (not sure on this specific issue)
Setting UNIX95 to 1 (as HP sometimes uses) is OK too.

The "invalid suffix character in obsolescent option" message
from "tail ++foo" is crap. If the "+" is followed by a non-digit,
then obviously the tradtitional syntax is not being used.

I sure hope "tail -6 foo" and "head -6 foo" are not also
getting hit by this. Last I argued with upstream, they were.

Message #156 received at 339085@bugs.debian.org (full text, mbox, reply):

From: Filipus Klutiero <ido@vif.com>

To: 339085@bugs.debian.org

Subject: Status update?

Date: Sun, 23 Jul 2006 18:20:49 -0400

Michael, this bug report is pretty long, and opened at critical severity 
against a required package since many monthes, and has also reached 
testing by error. Would you please send an update summarizing what you 
think should be done before closing this bug?

Message #157 received at 339085-close@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: Filipus Klutiero <ido@vif.com>, 339085-close@bugs.debian.org

Subject: Re: Bug#339085: Status update?

Date: Sun, 23 Jul 2006 20:27:54 -0400

On Sun, Jul 23, 2006 at 06:20:49PM -0400, you wrote:
>Michael, this bug report is pretty long, and opened at critical severity 
>against a required package since many monthes, and has also reached 
>testing by error. Would you please send an update summarizing what you 
>think should be done before closing this bug?

Hmm. I don't immediately see why 5.96-3 got into testing. C'est la
vie. Given that, and since the world doesn't seem to have come to an end 
over the issue, I'll just close the bug. 

Mike Stone

Message #162 received at 339085@bugs.debian.org (full text, mbox, reply):

From: Filipus Klutiero <ido@vif.ca>

To: control@bugs.debian.org

Cc: 339085@bugs.debian.org

Subject: Re: Bug#339085: Status update?

Date: Sun, 23 Jul 2006 22:25:15 -0400

reopen 339085
close 339085
thanks

Michael Stone a écrit :

> On Sun, Jul 23, 2006 at 06:20:49PM -0400, you wrote:
>
>> Michael, this bug report is pretty long, and opened at critical 
>> severity against a required package since many monthes, and has also 
>> reached testing by error. Would you please send an update summarizing 
>> what you think should be done before closing this bug?
>
>
> Hmm. I don't immediately see why 5.96-3 got into testing. C'est la
> vie. Given that, and since the world doesn't seem to have come to an 
> end over the issue, I'll just close the bug.
> Mike Stone

Thanks for the quick reply. Your reply didn't seem to change anything to 
the bug, so I'm marking the bug as closed and not found in any version.
The reason the bug got into testing is that I closed the bug in 5.93-3, 
but the bug was still open. britney doesn't do version tracking, which 
is usually just conservative, but in the case of bugs that are 
reintroduced, it is not strict enough. I didn't think about that, so 
sorry for taking the risk to break testing (I'm glad this didn't happen).

Send a report that this bug log contains spam.