Re: Surprising bug in sort
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [re-adding the list] According to [EMAIL PROTECTED] on 8/17/2008 10:07 PM: Thank you very much for the clarification, it makes perfect sense to me now - as I said I was surprised that I appeared to have found a bug. I have now reread the documentation and I still don't think it is particularly clear... -k, --key=POS1[,POS2] start a key at POS1, end it at POS2 (origin 1) ...does not mean to me that if I don't supply POS2 then include all fields to the end of the line, but there you go, I don't claim to be a Unix expert. This question comes up frequently. Is there some wording we can use to make it more obvious that omitting POS2 implies end of line, while still being brief enough for --help output? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkipY/sACgkQ84KuGfSFAYDE+QCfUVu+ZM2avBSCKY8XM2gqI6jK dBgAoMeoC8Y/d5Dkn7uShYARQKiI9djW =Gqje -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [fuse-discuss] rm opensolaris ntfs-3g problem
On Thu, 2008-08-14 at 16:25 +0300, Szabolcs Szakacsits wrote: ... ntfs-3g correctly returns ENOTEMPTY but this information gets lost and arrives as success to gnu rm. This indeed looks to be a problem in Solaris. Yup, I agree. Solaris rm(1) has the correct behaviour but using the GNU rm causes strangeness. Here's what happens with sshfs: $ mkdir -p l/l/l/l/l/l/l/l $ /usr/gnu/bin/rm -fr l /usr/gnu/bin/rm: cannot remove directory `l': Not owner $ /usr/bin/rm -fr l $ I've opened a bug to track this on defect.opensolaris.org: 2930 GNU rm causes problems for FUSE Feel free to add comments/update it. -M ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Surprising bug in sort
Eric Blake wrote: According to [EMAIL PROTECTED] on 8/17/2008 10:07 PM: Thank you very much for the clarification, it makes perfect sense to me now - as I said I was surprised that I appeared to have found a bug. I have now reread the documentation and I still don't think it is particularly clear... -k, --key=POS1[,POS2] start a key at POS1, end it at POS2 (origin 1) ...does not mean to me that if I don't supply POS2 then include all fields to the end of the line, but there you go, I don't claim to be a Unix expert. This question comes up frequently. Is there some wording we can use to make it more obvious that omitting POS2 implies end of line, while still being brief enough for --help output? ...end it at POS2 (or the end of the line, if omitted)? -- Matthew For great justice!! -- Captain (Zero Wing) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Surprising bug in sort
Matthew Woehlke [EMAIL PROTECTED] wrote: Eric Blake wrote: According to [EMAIL PROTECTED] on 8/17/2008 10:07 PM: Thank you very much for the clarification, it makes perfect sense to me now - as I said I was surprised that I appeared to have found a bug. I have now reread the documentation and I still don't think it is particularly clear... -k, --key=POS1[,POS2] start a key at POS1, end it at POS2 (origin 1) ...does not mean to me that if I don't supply POS2 then include all fields to the end of the line, but there you go, I don't claim to be a Unix expert. This question comes up frequently. Is there some wording we can use to make it more obvious that omitting POS2 implies end of line, while still being brief enough for --help output? ...end it at POS2 (or the end of the line, if omitted)? Sounds good. Want to write the patch? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Did the options for the Unix sort command change?
Michael Alston [EMAIL PROTECTED] wrote: Question: Did the options for the Unix sort command change? Yes. Some time ago. Why does: % sort -5 myfile no longer sort myfile by keying off of column 5? That precise syntax never worked. However, syntax like this used to be the norm: sort +3 -5 myfile Now, while that is still supported, you usually have to go through hoops (set the _POSIX2_VERSION envvar to some small number) to make it work. For details, read info coreutils standards and then the section on sort. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Surprising bug in sort
Matthew Woehlke [EMAIL PROTECTED] writes: Eric Blake wrote: According to [EMAIL PROTECTED] on 8/17/2008 10:07 PM: Thank you very much for the clarification, it makes perfect sense to me now - as I said I was surprised that I appeared to have found a bug. I have now reread the documentation and I still don't think it is particularly clear... -k, --key=POS1[,POS2] start a key at POS1, end it at POS2 (origin 1) ...does not mean to me that if I don't supply POS2 then include all fields to the end of the line, but there you go, I don't claim to be a Unix expert. This question comes up frequently. Is there some wording we can use to make it more obvious that omitting POS2 implies end of line, while still being brief enough for --help output? ...end it at POS2 (or the end of the line, if omitted)? ...end it at POS2 (default end of line) Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Did the options for the Unix sort command change?
Which website does the best job of presenting usage examples for the sort command, for a non-CS major? You can start with the examples in info coreutils sort. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
RE: Did the options for the Unix sort command change?
Jim, You've taught me to fish, big time! I've been using Unix/Linux systems for decades and was only familiar with the man command for looking up commands. This info coreutils help feature is very informative, on the sort command and many others. What else have I been in the dark about? I guess its true ... Ya don't know what Ya don't know. BR, Mike a.k.a. Rip Van Winkle -Original Message- From: Jim Meyering [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2008 12:55 PM To: Michael Alston Cc: bug-coreutils@gnu.org Subject: Re: Did the options for the Unix sort command change? Which website does the best job of presenting usage examples for the sort command, for a non-CS major? You can start with the examples in info coreutils sort. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Did the options for the Unix sort command change?
Michael Alston wrote: This info coreutils help feature is very informative, on the sort command and many others. ... What else have I been in the dark about? You might find the GNU standards manual interesting reading. http://www.gnu.org/prep/standards/html_node/GNU-Manuals.html#GNU-Manuals http://www.gnu.org/prep/standards/html_node/index.html Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
moot and unposixy error message
Hi,
In src/od.c around line 1820 it says this:
if (limit_bytes_to_format)
{
end_offset = n_bytes_to_skip + max_bytes_to_format;
if (end_offset n_bytes_to_skip)
error (EXIT_FAILURE, 0, _(skip-bytes + read-bytes is too large));
}
Since max_bytes_to_format cannot be negative, the second 'if' will
never trigger, so the whole six lines are moot.
Further, the Open Group says that 'od' should not produce an error
when '-j' plus '-N' is longer than the file, so the above section
can be removed.
http://www.opengroup.org/onlinepubs/7990989775/xcu/od.html --
If count bytes of input (after successfully skipping, if -j skip
is specified) are not available, it will not be considered an error;
the od utility will format the input that is available.
Benno
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: moot and unposixy error message
Benno Schulenberg [EMAIL PROTECTED] writes:
Hi,
In src/od.c around line 1820 it says this:
if (limit_bytes_to_format)
{
end_offset = n_bytes_to_skip + max_bytes_to_format;
if (end_offset n_bytes_to_skip)
error (EXIT_FAILURE, 0, _(skip-bytes + read-bytes is too large));
}
Since max_bytes_to_format cannot be negative, the second 'if' will
never trigger, so the whole six lines are moot.
But the sum can overflow, and since the involved types are unsigned this
has defined (wrap-around) behaviour.
Further, the Open Group says that 'od' should not produce an error
when '-j' plus '-N' is longer than the file, so the above section
can be removed.
This is a good point, however. But end_offset should then be set to
(uintmax_t)-1 on overflow.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Patch to fix data loss with `tail -F'
https://savannah.gnu.org/patch/index.php?6612 Please let me know if you see any issues with this change; I'd like to see it adopted for the next coreutils release. -- Jos Backus jos at catnook.com ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Surprising bug in sort
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 8/18/2008 10:25 AM: This question comes up frequently. Is there some wording we can use to make it more obvious that omitting POS2 implies end of line, while still being brief enough for --help output? ...end it at POS2 (or the end of the line, if omitted)? Sounds good. Want to write the patch? Attached, or 'git pull git://repo.or.cz/coreutils/ericb.git sort'. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiqRB4ACgkQ84KuGfSFAYBjegCff3qY5lyRtG47xJhdqNg0c2On cz4An0dbWmSABQRxR4RwyK8a+6IEuIWT =DvPZ -END PGP SIGNATURE- From edd292f8d4a5845bcc0d01ab080a6fc9f51a36fa Mon Sep 17 00:00:00 2001 From: Eric Blake [EMAIL PROTECTED] Date: Mon, 18 Aug 2008 21:50:27 -0600 Subject: [PATCH] sort: improve usage wording * src/sort.c (usage): Mention that -k defaults to end of line if POS2 omitted. * THANKS: Update. Reported by Tim Ryan. Signed-off-by: Eric Blake [EMAIL PROTECTED] --- THANKS |1 + src/sort.c |3 ++- 2 files changed, 3 insertions(+), 1 deletions(-) diff --git a/THANKS b/THANKS index 021ff6a..ea07d07 100644 --- a/THANKS +++ b/THANKS @@ -521,6 +521,7 @@ Thomas Schwinge [EMAIL PROTECTED] Thomas Wolff[EMAIL PROTECTED] Tim J. Robbins [EMAIL PROTECTED] Tim Mooney [EMAIL PROTECTED] +Tim Ryan[EMAIL PROTECTED] Tim Smithers[EMAIL PROTECTED] Tim Waugh [EMAIL PROTECTED] Toby Peterson [EMAIL PROTECTED] diff --git a/src/sort.c b/src/sort.c index a617517..37eb854 100644 --- a/src/sort.c +++ b/src/sort.c @@ -362,7 +362,8 @@ Other options:\n\ NUL-terminated names in file F\n\ ), stdout); fputs (_(\ - -k, --key=POS1[,POS2] start a key at POS1, end it at POS2 (origin 1)\n\ + -k, --key=POS1[,POS2] start a key at POS1 (origin 1), end it at POS2\n\ +(default end of line)\n\ -m, --merge merge already sorted files; do not sort\n\ ), stdout); fputs (_(\ -- 1.5.6.4 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
