[bug #20883] sort -u -n drops more lines than expected
Update of bug #20883 (project coreutils): Assigned to:None = rwp Open/Closed:Open = Closed ___ Follow-up Comment #1: Thanks for the report but this is not a bug but simply a misunderstanding of what sort is using as a sort key. Note that since this is an anonymous bug posting I cannot respond other than by posting a response to the bug. By default sort will consider the entire line as the sort key. When using the -n numeric sort flag this is still true. The reason sort -u is collapsing lines is because the sort key cause sort to believe the lines are equivalent. Unless -k is specified to restrict the sort key the default key is the entire line. The way to sort that input numerically on two different fields is to use the -k option to select both fields. Try this: sort -k1,1n -k2,2n -u 1 1 1 2 1 3 2 1 3 1 That will provide the result that you are looking to achieve. ___ Reply to this item at: http://savannah.gnu.org/bugs/?20883 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
.. anomaly in rmdir -p?
Hi all, I do not know if this is a bug or a feature, but suppose the following situation: Assume you create two subdirectories: mkdir dir1 mkdir dir2 Now, if you say rmdir -p dir1 dir1 is removed as expected and no further action is taken. Howver, if you instead say: rmdir -p dir2/../dir1 (which after expansion denotes the same directory) then you get the error message dir2/..: Directory not empty, probably since .. is handled like an ordinary directory segment specifier. You frequently get expressions like dir2/../dir1 in Makefiles, when paths are concatenated. I wonder, if rmdir should remove by file path expansion all occurrences of .. and . from the path before taking any further action. This would avoid the above annoying behavior. Or does the Posix standard demand the current behavior? Btw., I am referring to coreutils 6.9 on a linux redhat fc7 system. [When answering, please cc: to me, since I am not subscribed to this list. Thanks!] Greetings, Juergen ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: .. anomaly in rmdir -p?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Juergen Reuter on 8/24/2007 7:47 AM: rmdir -p dir2/../dir1 (which after expansion denotes the same directory) then you get the error message dir2/..: Directory not empty, probably since .. is handled like an ordinary directory segment specifier. Ahh, but dir1 WAS deleted, as requested. It was only when rmdir moved on to the next section, dir2/.., that a failure was detected. I wonder, if rmdir should remove by file path expansion all occurrences of .. and . from the path before taking any further action. This would avoid the above annoying behavior. Or does the Posix standard demand the current behavior? Thanks for the report. You are correct that POSIX requires the behavior: http://www.opengroup.org/onlinepubs/009695399/utilities/rmdir.html However, GNU rm also provides the --ignore-fail-on-non-empty option, which silences the message that you found annoying. And if you want to rely only on standardized features, then this idiom works pretty well in makefiles when $(directory) might contain ..: rmdir -p $(directory) 2/dev/null || : - -- 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 iD8DBQFGzufY84KuGfSFAYARAgWCAJ9ttJkMTHKmnt9ZRCdvj6ow8anWKQCfRMKh 3aOxq9b1sZS4NEiFyd6nClM= =o/Y1 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #18927] feature request: user defined format for ls output
Follow-up Comment #3, bug #18927 (project coreutils): Nor colorizing the output, print sizes in human-readable format, etc, etc. find != ls ___ Reply to this item at: http://savannah.gnu.org/bugs/?18927 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
md5sum
Not a bug, but a feature request. It would be nice if you were able to check a file against a checksum. E.g.: $ md5sum --compare f81064ee2b508c452bd9eef829da162e Logging.pm Logging.pm Does NOT match $ md5sum --compare f81064ee2b508c452bd9eef829da162e Logging.pm Logging.pm OK Ryan Duval Software Engineer - ePrize Labs __ ePrize One ePrize Drive Pleasant Ridge, MI 48069 DD: (248) 543-6512 Main: (248) 543-6800 Fax: (248) 543-3777 [EMAIL PROTECTED] Interactive Promotion Results www.eprize.com http://www.eprize.com/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #1212] wishlist: ls sort case insensitive option
Follow-up Comment #4, bug #1212 (project coreutils): I found out that unsetting LANG fixes the case sensitivity (README is supposed to came before main.c, dammit!), but will it be missing UTF capability without the LANG=en_US.UTF-8 that was default in my distro? ___ Reply to this item at: http://savannah.gnu.org/bugs/?1212 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
