Re: shred -f -u should ignore nonexistent files (like rm -f does)
Markus Kuhn wrote on 11-02-08 19:58: Feature suggestion: Given that shred -u and rm fulfill very similar functions (make a file go away), it would make sense if their user interface were very similar. In particular, it would be nice if $ shred -u -f abc shred: abc: failed to open for writing: No such file or directory would not output an error message if no file abc exists, just like rm -f abc does not complain about nonexistent files. Then one could use shred -u -f simply as a drop-in replacement for rm -f, e.g. change in a Makefile clean: rm -f *~ to clean: shred -u -f *~ Alternatively, it would be nice if the rm command had a shred-like option to overwrite a file before unlinking it. I disagree -- that would not be nice. Some people what rm to just mv a file, others want it to shred a file as well. Personally, I would have liked rm to run md5sum on the file before deciding whether or not to delete it -- just for the fun of it. But guess what.. you guessed it. bjd ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
new coreutils snapshot
My big test factorization changes broke at least two tests. Thanks to Peter Fales for spotting and reporting the new failures. Here is a new snapshot that fixes them: coreutils snapshot: http://meyering.net/cu/coreutils-ss.tar.gz8.9 MB http://meyering.net/cu/coreutils-ss.tar.lzma 3.6 MB http://meyering.net/cu/coreutils-ss.tar.gz.sig http://meyering.net/cu/coreutils-ss.tar.lzma.sig aka http://meyering.net/cu/coreutils-6.10.53-31d7d.tar.gz http://meyering.net/cu/coreutils-6.10.53-31d7d.tar.lzma ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls --group-directories-first -U
J Would you *please* consider sending a precise suggestion Sorry. OK, To both man page: --group-directories-first group directories before files And info page: `--group-directories-first' Group all the directories before the files and then sort the directories and the files separately using the selected sort key (see -sort option). That is, this option specifies a primary sort key, and the -sort option specifies a secondary key. please add: Doesn't work if -U or -f are present. P.S., can't mail you via my smarthost mx.meyering.net[82.230.74.64] said: 554 5.7.1 hapkido.dreamhost.com[66.33.216.122]: Client host rejected: Access denied ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
new coreutils snapshot [Re: printf failure on HP/UX 10.20 with 6.9.92
Peter Fales [EMAIL PROTECTED] wrote: On Thu, Feb 07, 2008 at 02:11:24AM +0100, Bruno Haible wrote: I committed this. It should fix it. Please test it, since I don't have access to a HP-UX 10 machine. To test it, create a test directory through the command Thanks for the mail. The request to test it may have been directed at me, but I'm not quite sure how to do that. The patches in the mail won't apply to the latest coreutils package, and there doesn't appear to be a gnulib package. Thanks for testing that. In case you're still inclined, here's a coreutils development snapshot: It includes the gnulib fix and tests. coreutils snapshot: http://meyering.net/cu/coreutils-ss.tar.gz8.9 MB http://meyering.net/cu/coreutils-ss.tar.lzma 3.6 MB http://meyering.net/cu/coreutils-ss.tar.gz.sig http://meyering.net/cu/coreutils-ss.tar.lzma.sig aka http://meyering.net/cu/coreutils-6.10.50-2746a.tar.gz http://meyering.net/cu/coreutils-6.10.50-2746a.tar.lzma ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: printf failure on HP/UX 10.20 with 6.9.92
On Thu, Feb 07, 2008 at 02:11:24AM +0100, Bruno Haible wrote: I committed this. It should fix it. Please test it, since I don't have access to a HP-UX 10 machine. To test it, create a test directory through the command Thanks for the mail. The request to test it may have been directed at me, but I'm not quite sure how to do that. The patches in the mail won't apply to the latest coreutils package, and there doesn't appear to be a gnulib package. For the record, here's the temporary patch I used. It seems simpler, and I haven't found any problems yet. Though this change is specifically for the buggy HP-HUX 10.20, it has (AFAIK) no impact on the behavior of any other platforms: diff -ur coreutils-6.10/lib/vasnprintf.c coreutils-6.10.new/lib/vasnprintf.c --- coreutils-6.10/lib/vasnprintf.c 2007-11-26 15:00:20.0 -0600 +++ coreutils-6.10.new/lib/vasnprintf.c 2008-02-04 16:46:47.0 -0600 @@ -1606,6 +1606,7 @@ followed by a positive field width. */ flags |= FLAG_LEFT; width = (unsigned int) (-arg); + a.arg[dp-width_arg_index].a.a_int = width; } else width = arg; @@ -2085,6 +2086,7 @@ followed by a positive field width. */ flags |= FLAG_LEFT; width = (unsigned int) (-arg); + a.arg[dp-width_arg_index].a.a_int = width; } else width = arg; @@ -2590,6 +2592,7 @@ followed by a positive field width. */ flags |= FLAG_LEFT; width = (unsigned int) (-arg); + a.arg[dp-width_arg_index].a.a_int = width; } else width = arg; @@ -3613,6 +3616,7 @@ followed by a positive field width. */ flags |= FLAG_LEFT; width = (unsigned int) (-arg); + a.arg[dp-width_arg_index].a.a_int = width; } else width = arg; -- Peter Fales Alcatel-Lucent Member of Technical Staff 2000 Lucent Lane Room: 1C-436 Naperville, IL 60566-7033 Email: [EMAIL PROTECTED] Phone: 630 979 8031 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
ls --group-directories-first -U
Mention in the ls docs at --group-directories-first, that -U nullifies its effects, sorry :-) ls (GNU coreutils) 6.10 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: the `--color' option of `ls' shadows the shortcut evaluation scheme of `' and `||'
Day wrote: I found this bug when I tried a tiny script which checks a directory is empty or not. [ $(ls -A ./dir) ] echo Not Empty || echo Empty So far so good. After `mkdir ./dir' and without adding anything into ./dir, run the script, the echoed message is Empty. But when adding the `--color' option to `ls', The --color option forces color codes on. You wanted to use 'ls --color=auto' instead. [ $(ls -A --color ./dir) ] echo Not Empty || echo Empty Using --color=auto allows ls to selectively turn color on or off depending upon whether the output is a tty device or not. That is the right option for you to use instead of --color which is the same as saying --color=always. Obviously you don't want to use any --color* options there at all. But I assume this is reduced from a larger test case where if seen in the real case would make more sense. the echoed message is always Not Empty, regardless of the fact that ./dir is actually EMPTY. Below is the tested result. Although I think it is a little strange that 'ls --color=always' does output terminal initialization codes when there is nothing to list I don't think this can be catagorized as a bug when color has been forced on manually. This doesn't happen with --color=auto for instance. [ $(ls -A --color ./dir) ] echo Not Empty || echo Empty How did you happen to run into using 'ls --color' in a test such as this? That seems an unfortunate option choice there. I recommend not using --color there. But obviously you already thought of that and so I have to ask what you were doing that caused it to be there? Why not simply avoid saying anything there? Why not simply use 'ls' without color? Could you say a few more words about how you came about this problem? Thanks Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: the `--color' option of `ls' shadows the shortcut evaluation scheme of `' and `||'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Day on 2/11/2008 8:35 PM: | | [ $(ls -A --color ./dir) ] echo Not Empty || echo Empty | | the echoed message is always Not Empty, regardless of the fact that ./dir is actually EMPTY. Below is the tested result. Thanks for the report. However, this is not necessarily a bug. By itself, --color is documented to mean --color=always, in which case ls outputs command sequences to initialize and restore colors back to normal: $ ls -A --color | od -tx1z 000 1b 5b 30 6d 1b 5b 6d .[0m.[m 007 And since that is output (even though it does not show up on the terminal), the string is non-empty, hence the result of the [] test. You really want the color output to be supressed in this context (in $() command substitution, the output is not a terminal, so color escape sequences don't normally make sense to the downstream client), so you should consider using --color=auto instead: $ ls -A --color=auto | od -tx1z 000 It may be worth considering a patch to coreutils, such that plain --color implies --color=auto rather than --color=always. For example, this would match how 'git config' reacts when interpreting color options (where 'auto' and 'true' are synonyms, and 'always' must be explicit). It may also be worth a patch to ls to omit color sequences altogether if there is no other output, although this may be more difficult to code and/or justify. - -- 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 iD8DBQFHsSpu84KuGfSFAYARAtC2AJ9tkXl1dAXlU9JcXiAOq7B6Te7I5ACdEL5G tbFOIuLMuC30mMwqXvLfsVE= =3aQY -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
the `--color' option of `ls' shadows the shortcut evaluation scheme of `' and `||'
I found this bug when I tried a tiny script which checks a directory is empty or not. [ $(ls -A ./dir) ] echo Not Empty || echo Empty After `mkdir ./dir' and without adding anything into ./dir, run the script, the echoed message is Empty. But when adding the `--color' option to `ls', [ $(ls -A --color ./dir) ] echo Not Empty || echo Empty the echoed message is always Not Empty, regardless of the fact that ./dir is actually EMPTY. Below is the tested result. day[~]$ mkdir dir day[~]$ ls -l dir total 0 day[~]$ [ $(ls -A ./dir) ] echo Not Empty || echo Empty Empty day[~]$ [ $(ls -A -F --color ./dir) ] echo Not Empty || echo Empty Not Empty day[~]$ [ $(ls -A -F ./dir) ] echo Not Empty || echo Empty Empty day[~]$ [ $(ls -A --color ./dir) ] echo Not Empty || echo Empty Not Empty Version Info: ls (GNU coreutils) 6.9 GNU bash, version 3.1.17(2)-release Linux zenwalk 2.6.23.12 #1 SMP PREEMPT Wed Dec 19 14:34:44 CET 2007 i686 AMD Turion(tm) 64 X2 AuthenticAMD GNU/Linux PS: I have also tested on Ubuntu 7.10, the same result. So I think it's a common bug. -- DAY's dAi Yi ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
shred -f -u should ignore nonexistent files (like rm -f does)
Feature suggestion: Given that shred -u and rm fulfill very similar functions (make a file go away), it would make sense if their user interface were very similar. In particular, it would be nice if $ shred -u -f abc shred: abc: failed to open for writing: No such file or directory would not output an error message if no file abc exists, just like rm -f abc does not complain about nonexistent files. Then one could use shred -u -f simply as a drop-in replacement for rm -f, e.g. change in a Makefile clean: rm -f *~ to clean: shred -u -f *~ Alternatively, it would be nice if the rm command had a shred-like option to overwrite a file before unlinking it. Thanks, Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
