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
Description: OpenPGP digital signature
