Re: feature request: sort by human-readable disk sizes
Justin Watt scripsit: > It'd be great if "sort" had an option to sort by the "-h" output of > the "du" command. Likewise df and ls. > Seems like it'd be pretty easy and really useful. What do you think? +1, but -h is not a good option, I think. -- Time alone is real John Cowan <[EMAIL PROTECTED]> the rest imaginary like a quaternion --phma http://www.ccil.org/~cowan ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: error.c: "Unknown system error" should report errno value
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[adding gnulib, as this problem is really a gnulib one, not a coreutils]
According to Martin Koeppe on 9/24/2007 5:46 PM:
>
> On Mon, 24 Sep 2007, Paul Eggert wrote:
>
>> Martin Koeppe <[EMAIL PROTECTED]> writes:
>>
>>> + s = _("Unknown system error");
>>> + fprintf (stderr, ": %s (errno=%d)", s, errnum);
>>
>> I like the idea, but that "errno=" grates a bit, as user diagnostics
>> shouldn't be so low-level. How about this instead?
>>
>> fprintf (stderr, _(": Unknown system error number %d"), errnum);
>
> Ok, I could live with that. My idea was not to change the original
> string to avoid re-translation and to give a clear hint what this number
> is meant to be, i.e. that's an errno value. The number alone is probably
> of no use to any "normal" user anyway. (Though I first had only "(%d)"
> myself.)
The Austin group debated making the next version of POSIX required to
always return a non-NULL result for strerror (although for out-of-range
errors, there was no guarantee that the string had to be unique, as in
printing what the out-of-range value was). However, I think that proposal
has stalled, so the Interix behavior of returning NULL for strerror(-1) is
not yet non-POSIX compliant. I am very much in favor of a gnulib
implementation of strerror that works harder to provide non-NULL results.
> OTOH if strerror() cannot resolve the errno value, then there
> is probably a bigger problem in it, not a normally occuring case
> (generating a user level diagnostic has just failed!), and debugging
> should be made easy. I also think it's a good idea to have ":" and "%d"
> not within the string for easy and uniform translations.
Actually, gettext encourages putting %d in the translation, so that
languages that use pluralization rules in their translation can deal with
it better. In other words, Paul's suggested wording is better.
For reference, here's what cygwin does with unknown errors:
"Unknown error %u"
without translation (but then again, cygwin lacks builtin translation).
- --
Don't work too hard, make some time for fun as well!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG+IJ284KuGfSFAYARAqfAAJ9qulY2G/MT6OaTYAIi0lxU/qFSuACZAZz0
H3Q0B0nThfZQHDJ5Zpywu0Y=
=Idym
-END PGP SIGNATURE-
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
feature request: sort by human-readable disk sizes
It'd be great if "sort" had an option to sort by the "-h" output of the "du" command. For example the current output of du is alphabetized by filename with no options to sort: $ du -h --max-depth=1 4.0K./bin 52M ./code 765M./Desktop 12K ./mail 17M ./music 124K./PDF 5.5G./photos 153M./public_html 652K./ufc 7.3G. What I'm envisioning is something like this: $ du -h --max-depth=1 | sort -h 4.0K./bin 12K ./mail 124K./PDF 652K./ufc 17M ./music 52M ./code 153M./public_html 765M./Desktop 5.5G./photos 7.3G. Seems like it'd be pretty easy and really useful. What do you think? Justin Watt http://justinsomnia.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: error.c: "Unknown system error" should report errno value
On Mon, 24 Sep 2007, Paul Eggert wrote:
Martin Koeppe <[EMAIL PROTECTED]> writes:
+ s = _("Unknown system error");
+ fprintf (stderr, ": %s (errno=%d)", s, errnum);
I like the idea, but that "errno=" grates a bit, as user diagnostics
shouldn't be so low-level. How about this instead?
fprintf (stderr, _(": Unknown system error number %d"), errnum);
Ok, I could live with that. My idea was not to change the original
string to avoid re-translation and to give a clear hint what this
number is meant to be, i.e. that's an errno value. The number alone is
probably of no use to any "normal" user anyway. (Though I first had
only "(%d)" myself.) OTOH if strerror() cannot resolve the errno
value, then there is probably a bigger problem in it, not a normally
occuring case (generating a user level diagnostic has just failed!),
and debugging should be made easy. I also think it's a good idea to
have ":" and "%d" not within the string for easy and uniform
translations. That's probably why %s is used that often I could
imagine.
But with your idea in a debug case one could grep through all the
source files and would also find that it is an errno value which has
been reported. So I'm not against your idea.
Martin
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: error.c: "Unknown system error" should report errno value
Martin Koeppe <[EMAIL PROTECTED]> writes:
> + s = _("Unknown system error");
> + fprintf (stderr, ": %s (errno=%d)", s, errnum);
I like the idea, but that "errno=" grates a bit, as user diagnostics
shouldn't be so low-level. How about this instead?
fprintf (stderr, _(": Unknown system error number %d"), errnum);
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
FAQ -- df Size and Used and Available do not add up
The du and df entry inspired me to add add another related entry to the FAQ. http://www.gnu.org/software/coreutils/faq/#df-Size-and-Used-and-Available-do-not-add-up Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: strange DF (disk full) output
Bauke Jan Douma wrote: > James Youngman wrote: > >There are many things that will normally result in the output of df > >being different to the output of du. Here are some examples: > > ... > > This explanation (well done!) should make it into the FAQ, if only for > its clarity, that's what I think. I think so too. I just added this: http://www.gnu.org/software/coreutils/faq/#df-and-du-report-different-information Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
error.c: "Unknown system error" should report errno value
Hi all,
please consider printing the errno value together with "Unknown system
error" if strerror() failed. It failed for me on Interix for
errno=-1, which I'm interested to know about, just to get an idea what
could be wrong, and that strerror() is not wrong.
Martin--- gnulib/lib/error.c.orig Sat Jul 21 10:10:38 2007
+++ gnulib/lib/error.c Mon Sep 24 20:38:36 2007
@@ -121,15 +121,16 @@
s = strerror (errnum);
#endif
-#if !_LIBC
- if (! s)
-s = _("Unknown system error");
-#endif
-
#if _LIBC
__fxprintf (NULL, ": %s", s);
#else
- fprintf (stderr, ": %s", s);
+ if (s)
+fprintf (stderr, ": %s", s);
+ else
+{
+ s = _("Unknown system error");
+ fprintf (stderr, ": %s (errno=%d)", s, errnum);
+}
#endif
}
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Wrong diagnostic when moving file from unwritable dir
Andreas Schwab <[EMAIL PROTECTED]> wrote: > When moving a file between filesystems, and the source directory is > unwritable, the diagnostic given by mv is wrong: > > $ mkdir /tmp/x; touch /tmp/x/y; chmod -w /tmp/x > $ test $(stat -c %d /tmp/x) -ne $(stat -c %d .); echo $? > 0 > $ mv /tmp/x/y . > mv: cannot remove `/tmp/x/y': Not a directory Thanks for the report. That was fixed by this recent change to remove.c: [I'll mention in NEWS that the fix also affects cross-partition-mv] 2007-09-22 Jim Meyering <[EMAIL PROTECTED]> rm: give a sensible diagnostic when failing to remove a symlink On some systems (those with openat et al), when rm would fail to remove a symlink, it would fail with the misleading diagnostic, "Too many levels of symbolic links". * NEWS: Mention the bug fix. * src/remove.c (is_nondir_lstat): New function. (remove_entry): Use it to catch failed-to-remove symlink (and any other non-dir) here so that we don't fall through and try to treat it as directory, which -- with a symlink -- would provoke the bogus ELOOP failure. * tests/rm/fail-eacces: Add a test for the above. * src/c99-to-c89.diff: Adjust offsets. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Wrong diagnostic when moving file from unwritable dir
When moving a file between filesystems, and the source directory is unwritable, the diagnostic given by mv is wrong: $ mkdir /tmp/x; touch /tmp/x/y; chmod -w /tmp/x $ test $(stat -c %d /tmp/x) -ne $(stat -c %d .); echo $? 0 $ mv /tmp/x/y . mv: cannot remove `/tmp/x/y': Not a directory 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: Seems like a bug...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Anthony on 9/23/2007 12:35 PM: > mv -f .deps/userspec.Tpo .deps/userspec.Po > gcc -std=gnu99 -I. -static -O2 -g -MT utimecmp.o -MD -MP > -MF .deps/utimecmp.Tpo -c -o utimecmp.o utimecmp.c > In file included from utimecmp.c:34: > utimens.h:2: error: conflicting types for 'futimens' > ///usr/include/sys/stat.h:370: error: previous declaration of 'futimens' > was here This has been brought up before, and has been since fixed in git/CVS. The problem was that gnulib implemented a strawman futimens prior to when the Austin working group changed its signature for inclusion in the next revision of POSIX. It will not be an issue when coreutils 6.10 is released. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG96jO84KuGfSFAYARAlAXAJ9Ar/B+sHTvMcdcaZQ1w9UDPNxmCwCgt0RJ HYBtZ87ZOkvwoW1J3ENToD8= =SYNp -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date: next sunday is this sunday?
Martin Bernreuther wrote: > Hello, > > if I invoke date, e.g. > > ~> date > So 23. Sep 20:33:39 CEST 2007 > > and especially using a relative date > with "next" and a weekday, like > > ~> date --date="next sunday" > So 23. Sep 00:00:00 CEST 2007 > > I don't get the next sunday, but this sunday (today) > on a sunday, whereas it works for every other day. > This was done with > ~> date --version > date (GNU coreutils) 6.4 This happens for every day actually. "next sunday" seems to mean starting at today, return the date for the first "sunday" encountered. "this" and "next" seem to be synonymous in this context. Now this is at least confusing because "last sunday" does in fact move back a week, which is not symmetric. Also the info page is contradicting: "In this context, 'last DAY' or 'next DAY' is also acceptable; they move one week before or after the day that DAY by itself would represent." > and also with version 5.2.1. For the latter > ~> date --date="tomorrow next sunday" > seems to give me the expected result, > but not for 6.4, where this is handled like > "tomorrow" alone. I can confirm this. This looks like a definite bug as the info page says that the relative specifiers are cumulative. The older date command did add in the order specified, whereas with the newer one, one can't change the origin date. > If this is not a bug, how can I get the *next* sunday? You could try the following script: http://www.pixelbeat.org/scripts/day which you can use like: ./day mon ./day mon week ./day mon last p.s. In the info page I would include a link to the "Date input formats" node from the "date invocation" node. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
