Re: sort --random-sort

Frederik Eaton [EMAIL PROTECTED] writes: I still think what I sent is ready to apply. I took a look at the patch quoted in that email and have some comments and suggestions. It's more conservative to minimize the changes to the ISAAC code. The simplest thing to do for now is to put it into a

Re: sort --random-sort

Paul, Thank you for submitting a patch of your own. I still think what I sent is ready to apply. I took a look at the patch quoted in that email and have some comments and suggestions. It's more conservative to minimize the changes to the ISAAC code. The simplest thing to do for now

Feature request: add option to show directories first

Hi, I think that an option which lets the user to see the usual file listing sorted alphabetically, but with directory entries grouped before the files, would be very useful. I mean; if C is a folder, B and A files; the normal output is: A B C with a new option like this one I'm

Re: sort --random-sort

Paul Eggert [EMAIL PROTECTED] wrote: ... As a documentation issue, I'd feel more comfortable calling this a hashed sort rather than a random sort. Using the word random has the wrong connotations, since the sort doesn't generate a random permutation of the input. So I would prefer option

Re: Feature request: add option to show directories first

Hi, Eric Blake wrote: [The fact that you sent this request to the old bug-fileutils list instead of bug-coreutils makes me wonder if you have the latest version of coreutils. However, your request is still not present in CVS coreutils.] sorry; I did not know that bug-fileutils was

Re: sort --random-sort

By the way, here is a patch corresponding to my current version of the code. Frederik diff -N -ur -x '*.in' -x Makefile -x configure -x dircolors.h -x groups -x '*~' -x wheel.h -x 'localedir.*' -x 'stamp-*' -x wheel-size.h -x alloca.h -x .deps -x charset.alias -x getdate.c -x ref-add.sed -x

Re: rm issue

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 12/2/2005 2:00 PM: However, we could have an option along those lines. Users who prefer that behavior then could alias rm to rm-with-the-option. FreeBSD has an -I option, with the following meaning: -I

rm --p

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 $ rm --p rm: option `--p' is ambiguous Try `rm --help' for more information. Yet `rm --help' only mentions --preserve-root, since --presume-input-tty is intentionally undocumented. Is there a slick way to tell getopt_long that a particular option

Re: rm --p

Eric Blake [EMAIL PROTECTED] wrote: $ rm --p rm: option `--p' is ambiguous Try `rm --help' for more information. Yet `rm --help' only mentions --preserve-root, since --presume-input-tty is intentionally undocumented. Is there a slick way to tell getopt_long that a particular option must

Re: rm --p

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 12/3/2005 2:19 PM: Thanks for the prod. I don't know of a mechanism in getopt_long to do that. But it is worth changing. I'll probably just add a leading `-' to the undocumented (for-testing-only) option name.

Re: rm --p

Eric Blake [EMAIL PROTECTED] wrote: According to Jim Meyering on 12/3/2005 2:19 PM: Thanks for the prod. I don't know of a mechanism in getopt_long to do that. But it is worth changing. I'll probably just add a leading `-' to the undocumented (for-testing-only) option name. Indeed, rm

Re: Endian options for od

dcoffin AT cybercom DOT net wrote: Eric Blake wrote: Thanks for the patch, but it has several problems. First, I'm not sure we need short options, or that the documentation need call out Intel and Motorola (after all, there are other chip manufacturers as well, Motorola has spun off

Re: nl-command bug

Silvano Catinella wrote: I have discovered a little bug in nl command written by Scott Bartram and David MacKenzie. When I push an ASCII-color-text into the pipe used by nl, I can see a very strange behavior. Thanks for the report. But this does not look like a bug in nl to me. Usually, if

Re: df reports bind mounts creating noisy output

Paul Eggert wrote: I've installed the patch along the lines that I proposed in early October about this issue. Here it is again, slightly modified to also treat inaccessible mounts as dummies, since they can happen with shadowed mount points. I just finished testing this and it resolves my

Apparently irrational behaviour in sort

I have a text file whose lines each contain two dates, of the format MM-DD-. I want to sort these lines into order from oldest to most recent - that is, first by , then by MM, then by DD. After I parse out the spaces using sed, the only whitespace remaining in the file is the blocks of