bug#14174: BUG REP: tee takes an annoyingly long time in some system.

2013-04-11 Thread Bernhard Voelker
tag 14174 + moreinfo close 14174 thanks On 04/10/2013 11:48 AM, Gao, Jie (Kyrie, HPIT-DS-CDC) wrote: Hello sir, Not sure if it is tee's problem. Tee works well in my workstation, but it will take a long time on cluster. See the example below. Could you if possible show me the reason why

bug#14174: BUG REP: tee takes an annoyingly long time in some system.

2013-04-11 Thread Pádraig Brady
Bringing back on list. I didn't intend to take off list sorry. Details below... On 04/11/2013 06:57 AM, Gao, Jie (Kyrie, HPIT-DS-CDC) wrote: On 04/10/2013 09:53 PM, Pádraig Brady wrote: On 04/10/2013 10:48 AM, Gao, Jie (Kyrie, HPIT-DS-CDC) wrote: Hello sir, Not sure if it is tee's

bug#14024: Test failure in coreutils 8.13

2013-04-11 Thread Ellis N. Thomas
Pádraig, The Gnu bug-coreutils Archives does not seem to have linked my reply message of April 10, 2013, and your reply as below, to our previous messages for bug#14024 on and before March 27, 2013. See my message of 27 March 2013 21:08:09 GMT (in archive as 17:08) for details

bug#14189: ls -d bug ??

2013-04-11 Thread r...@electronicstheory.com
To: The most gracious and brilliant authors of the ever useful ls command. (The title is quite heartfelt - no sarcasm intended). I have to wonder. I've been using *nix of various kinds for nigh unto 15 years. I ran into an issue today that I've seen many times, and it still irks me. I've

bug#14024: Test failure in coreutils 8.13

2013-04-11 Thread Bob Proulx
Ellis N. Thomas wrote: The Gnu bug-coreutils Archives does not seem to have linked my reply message of April 10, 2013, and your reply as below, to our previous messages for bug#14024 on and before March 27, 2013. The mailing list archive tracks messages on the mailing list. The BTS (bug

bug#14189: ls -d bug ??

2013-04-11 Thread Assaf Gordon
Hello Ray, Others can provide more detailed information about the rational of the dot file, but regarding your questions: r...@electronicstheory.com wrote, On 04/11/2013 02:17 PM: Once in a blue moon, a person would like to view the subdirectories of the directory you are in, without seeing

bug#14189: ls -d bug ??

2013-04-11 Thread Bob Proulx
tags 14189 + notabug close 14189 thanks http://www.gnu.org/software/coreutils/faq/#ls-_002dd-does-not-list-directories_0021 r...@electronicstheory.com wrote: Once in a blue moon, a person would like to view the subdirectories of the directory you are in, without seeing all the various files.

bug#14189: ls -d bug ??

2013-04-11 Thread Paul Eggert
On 04/11/13 11:17, r...@electronicstheory.com wrote: Is there some reason it can't give me what (it appears) the manual says (and what makes sense) it should? Sounds like there's a bug in the manual; it shouldn't say that ls -d outputs only directories. Can you please mention the wording

bug#14189: ls -d bug ??

2013-04-11 Thread Eric Blake
On 04/11/2013 03:13 PM, Bob Proulx wrote: If you didn't want it to list only the name of the directory and not the contents then why did you use the -d option? Since -d specifically prevents it from listing the contents. ls -d, I would think, would tell you the same data that ls would

bug#14189: ls -d bug ??

2013-04-11 Thread Eric Blake
On 04/11/2013 03:31 PM, Eric Blake wrote: But for a full list of all subdirectory names excluding '.' and '..', you need three globs; and either a shell option that suppresses a glob that has no match, or ignoring the errors when ls tries to warn you when a glob doesn't match: Portable (but

bug#14024: Test failure in coreutils 8.13

2013-04-11 Thread Pádraig Brady
On 04/11/2013 03:30 PM, Ellis N. Thomas wrote: Pádraig, The Gnu bug-coreutils Archives does not seem to have linked my reply message of April 10, 2013, and your reply as below, to our previous messages for bug#14024 on and before March 27, 2013. See my message of 27 March 2013

bug#14189: ls -d bug ??

2013-04-11 Thread Bob Proulx
Bob Proulx wrote: 10.1 `ls': List directory contents == The `ls' program lists information about files (of any type, including directories). Options and file arguments can be intermixed arbitrarily, as usual. For non-option command-line