[bug #1212] wishlist: ls sort case insensitive option
Follow-up Comment #9, bug #1212 (project coreutils): http://hotsecretarysex.pornlivenews.com/articles/636683/hot-secretary-in-stocking Hot secretary in stocking http://hotsecretarysex.pornlivenews.com/articles/636682/secretary-sex-video Secretary sex video http://hotsecretarysex.pornlivenews.com/articles/636681/boss-fucking-secretary Boss fucking secretary http://hotsecretarysex.pornlivenews.com/articles/636680/secretaries-in-short-skirts-stockings Secretaries in short skirts stockings http://hotsecretarysex.pornlivenews.com/ Secretary sex. Secretaries in short skirts. Secretary fuck, secretary in stocking ___ 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
Re: Bug in uname
On Mon, 8 Dec 2008, Eric Blake wrote: The information contained in this e-mail may be privileged and/or Sending mail from an account that adds a disclaimer longer than the body of your message is considered poor netiquette. This disclaimer is unenforceable on a publicly archived mailing list, but some people refuse to reply on principle. Hi Eric, I agree these disclaimers can be annoying, but there's no clue to the sender that bug-coreutils@gnu.org represents a publically archived mailing list. I'm not sure there's even an implied license to copy and re-publish the text of this email, although _I_ know that's what MHonArc will do on http://lists.gnu.org/ Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
RE: Bug in uname
Thanks for maintaining a less-than-glorious, but useful utility. I did check to make sure I was getting the expected version of uname: which uname /bin/uname , but attempting to repeat the symptom got proper behavior!??: uname -a Linux cloudy 2.6.25-14.fc9.x86_64 #1 SMP Thu May 1 06:06:21 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux A look at my history shows the command I originally used: uname -a uname: extra operand `-a' Try `uname --help' for more information. Oh goody, identical commands, different behavior... cat | od -c uname -a 000 u n a m e 342 200 223 a \n \n 014 It appears that the web page I cut-n-pasted from was rendered using a UTF8 character (0xE28093) that just happens to look like a hyphen on my terminal. Nevermind :-) Sorry about the .sig; it's the burden that comes of working for a financial company. Further sorry about the false alarm. Walter -Original Message- From: Eric Blake [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2008 7:31 PM To: Walter Coole Cc: bug-coreutils@gnu.org Subject: Re: Bug in uname -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Walter Coole on 12/8/2008 1:28 PM: uname -a uname: extra operand `-a' Thanks for the report. Are you sure you don't have any aliases or shell functions interfering? Depending on your shell, 'which uname' or 'type uname' will tell you. ... ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
date(1): -d argument parsing error
Hi. date(1) command parses next $day_of_week_today (where $day_of_week_today is today's day name) incorrectly: $ date Tue Dec 9 17:16:50 GMT 2008 $ date -d next `date +%A` Tue Dec 9 00:00:00 GMT 2008 It should print the next Tuesday's date, i.e. today + 7 days. Cheers, Jan. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date(1): -d argument parsing error
On Tue, Dec 9, 2008 at 5:19 PM, Jan Minář [EMAIL PROTECTED] wrote: Hi. date(1) command parses next $day_of_week_today (where $day_of_week_today is today's day name) incorrectly: $ date Tue Dec 9 17:16:50 GMT 2008 $ date -d next `date +%A` Tue Dec 9 00:00:00 GMT 2008 It should print the next Tuesday's date, i.e. today + 7 days. The date parser does not support as input weekday names in arbitrary languages; see the documentation for the date command. Fortunately, the problem is simple to work around, by overriding the locale selection for the inner date command:- $ date -d next `LC_ALL=C date +%A` mercredi 10 décembre 2008, 00:00:00 (UTC+) James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
rm: option -I and --interactive=once are not behaving equivalently
Hi, Regarding to the manpage and comments in rm.c, the option -I of rm is meant to be the same as --interactive=once It isn't, since when removing a write-protected file, rm prompts if --interactive=once is given, but it doesn't prompt, if -I is given. This behaviour of rm -I is surprising, since rm even prompts before removing a write-protected file, if no extra interactivity is asked for. It can be changed easily by changing line 268 of rm.c from x.interactive = RMI_NEVER; to x.interactive = RMI_SOMETIMES; (see attached diff) --- src/rm.c 2008-12-10 00:31:33.0 +0100 +++ src/rm-new.c 2008-12-10 00:33:24.0 +0100 @@ -265,7 +265,7 @@ break; case 'I': - x.interactive = RMI_NEVER; + x.interactive = RMI_SOMETIMES; x.ignore_missing_files = false; prompt_once = true; break; ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date(1): -d argument parsing error
2008/12/10 James Youngman [EMAIL PROTECTED]: $ date -d next `LC_ALL=C date +%A` mercredi 10 décembre 2008, 00:00:00 (UTC+) ^^^ You've just demonstrated that the bug is present in the French localization as well -- the you got is *today*, not *next* Wednesday, as it should be. Cheers, Jan. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
split() command
Dear Sir, why does split() command has different options in different UniX systems? i.e. -a option does not work on some Unix machines... Is this because of long option and short option difference? Thanks, YB ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: split() command
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Yongsheng Bai on 12/9/2008 8:38 PM: Dear Sir, why does split() command has different options in different UniX systems? i.e. -a option does not work on some Unix machines... Your example of 'split -a' is required by POSIX, so it should work on any Unix system, even when GNU coreutils are not installed: http://www.opengroup.org/onlinepubs/9699919799/utilities/split.html but other options, like 'split -C', are GNU extensions. Is this because of long option and short option difference? Long options are also a GNU extension. By the very definition of extension, you cannot expect other Unix platforms to provide the same set of extensions as GNU coreutils, although you should be able to install GNU coreutils on pretty much any of today's common Unix systems to get your favorite GNU extensions. - -- 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 iEYEARECAAYFAkk/O08ACgkQ84KuGfSFAYC12gCg1z0NhHVziNoF/N8T3O5jrkXw 2ScAn0/dqieLHt1P5k5XQXCpSOU2ZdGj =yLtM -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: split() command
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [please keep replies on the list, and don't top-post] According to Yongsheng Bai on 12/9/2008 8:51 PM: Thanks, Sir. But, how can I fix this problem? - split: invalid option -- d Try `split --help' for more information. split: invalid option -- a Try `split --help' for more information. Please paste the actual command that you typed, so we have a chance of diagnosing what you typed wrong. Based on the error message, you are probably using GNU split, so at least that isn't a factor. Also, type 'split --version' to verify which version of split you are using. - -- 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 iEYEARECAAYFAkk/PsoACgkQ84KuGfSFAYDT1gCfRnKKJtI9DFjCv58fFCDplr2V 0ooAoIp78UGWIW2u2Y0pYJM0ZWSud9Se =B8JU -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
