cat - -
Bet you don't document anywhere that/why $ echo a|cat - - will only give one a. Or maybe even raise an error... ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat - -
[EMAIL PROTECTED] wrote: Bet you don't document anywhere that/why $ echo a|cat - - will only give one a. Or maybe even raise an error... Seems obvious to me. Perhaps the following is more obvious :) $ echo mouse | cat - - Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat - -
On Monday 14 January 2008, [EMAIL PROTECTED] wrote: Bet you don't document anywhere that/why $ echo a|cat - - will only give one a. what were you expecting to happen ? it is not possible for cat to re-read stdin once it has consumed it. -mike signature.asc Description: This is a digitally signed message part. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat - -
MF what were you expecting to happen ? it is not possible for cat to MF re-read stdin once it has consumed it. Yes, but you don't document it I bet. At least not in the path that starts with man cat. Just reading the coreutils docs, one wouldn't know why $ date|cat q b - c q - q - b worked except stdin only showed up once... Hmmm maybe also some pipes would also... ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat - -
On Tuesday 15 January 2008, [EMAIL PROTECTED] wrote: what were you expecting to happen ? it is not possible for cat to re-read stdin once it has consumed it. Yes, but you don't document it I bet. At least not in the path that starts with man cat. Just reading the coreutils docs, one wouldn't know why $ date|cat q b - c q - q - b worked except stdin only showed up once... Hmmm maybe also some pipes would also... this isnt a cat/coreutils/stdin specific issue. *any* program that consumes a read-destructive source would have the same problem. at the basic level, cat is functioning correctly: you told it to read from stdin as much as it could and that is exactly what cat did. the fact that stdin was empty after the first time means you got no output the second+ time around. you could make the same argument that if you wrote to a fifo and tried to cat it multiple times, cat was misbehaving. -mike signature.asc Description: This is a digitally signed message part. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat - -
Yes yes. I'm just saying supposing a theoretical new user's first encounter with all this stuff was the document trail that started with the cat man page, then he would think - was broken. So still an understanding of Unix is implied as the docs perhaps describe 95% but not yet 100% of what one needs to know. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat - -
On Jan 16, 2008 12:01 AM, [EMAIL PROTECTED] wrote: Yes yes. I'm just saying supposing a theoretical new user's first encounter with all this stuff was the document trail that started with the cat man page, then he would think - was broken. The best place to document this could well be a new-user document. Explaining that once you've read all the data from a pipe, you can't rewind it, and explaining that in one place is probably more helpful than stating it as a caveat on the handling of - in hundreds of utilities. Such a document would also be a good place to explain the handling of wildcards and so forth too. But the main problem is to figure out where to put such a document so that new users will actually read it. What do you think? So still an understanding of Unix is implied as the docs perhaps describe 95% but not yet 100% of what one needs to know. I think exposition of general principles probably belongs somewhere else. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat - -
J But the main problem is to figure out where to put such a document J so that new users will actually read it. What do you think? Somewhere around $ info -o - coreutils|grep -C 2 Intro ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
mkdir bug with -m and -p together
-p does not use the mode from -m for parent directories: # mkdir -p -m 700 foo/bar # ls -ld foo foo/bar The directory foo does not have the correct permissions. I can imagine: # mkdir -p -m 500 foo/bar Causing problems though, but unless it's easy to handle, I would ignore it (the user got what he requested). -Ariel ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
PDT timezone bug in GNU coreutils date v6.9
To whom it may concern: I believe I have identified a bug in the GNU coreutils date utility when handling the PDT timezone. I'm running Fedora 8 kernel 2.6.23.9-85.fc8, and the command date - -version reports: date (GNU coreutils) 6.9 When using the -d option to display the specified time (vs now), this version of the date command apparently does not recognize PDT as a valid timezone. For example: $ date -d Tue Jan 14 08:25:26 EST 2008 +%s 1200317126 $ date -d Tue Jan 14 08:25:26 EDT 2008 +%s 1200313526 $ date -dTue Jan 14 08:25:26 PST 2008 +%s 1200327926 $ date -dTue Jan 14 08:25:26 PDT 2008 +%s date: invalid date `Tue Jan 14 08:25:26 PDT 2008' Note that EST, EDT and PST work fine, however, PDT is listed as invalid. Note that I have tested this same command with a much earlier version of the date utility, and it worked fine when using PDT as the timezone. Thanks! ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: PDT timezone bug in GNU coreutils date v6.9
On Tue, 15 Jan 2008, [EMAIL PROTECTED] wrote: I believe I have identified a bug in the GNU coreutils date utility when handling the PDT timezone. I'm running Fedora 8 kernel 2.6.23.9-85.fc8, and the command date - -version reports: date (GNU coreutils) 6.9 [snip] $ date -dTue Jan 14 08:25:26 PDT 2008 +%s date: invalid date `Tue Jan 14 08:25:26 PDT 2008' Note that EST, EDT and PST work fine, however, PDT is listed as invalid. Odd, this seems to depend on your current timezone setting: $ export TZ=UTC $ date -dTue Jan 14 08:25:26 PDT 2008 +%s 1200324326 $ export TZ=America/Los_Angeles $ date -dTue Jan 14 08:25:26 PDT 2008 +%s date: invalid date `Tue Jan 14 08:25:26 PDT 2008' or put more simply: $ TZ=America/Los_Angeles date -d '12:00 PDT' date: invalid date `12:00 PDT' This report can be generalised to using the time_zone_table entry corresponding to the local DST state *not* currently in effect gives an error. A few more examples (which depend on today's date): $ TZ=Europe/London date -d '12:00 BST' date: invalid date `12:00 BST' TZ=America/Chicago date -d '12:00 CDT' date: invalid date `12:00 CDT' TZ=America/New_York date -d '12:00 PDT' Tue Jan 15 14:00:00 EST 2008 TZ=Pacific/Auckland date -d '12:00 NZST' date: invalid date `12:00 NZST' Although the coreutils documentation cautions about using ambiguous timezone labels like this, I don't see any mention of (or reason for) the error message you've found. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: PDT timezone bug in GNU coreutils date v6.9
Philip Rowlands [EMAIL PROTECTED] writes: Although the coreutils documentation cautions about using ambiguous timezone labels like this, The actual problem is the reverse of the original complaint. Coreutils should reject a usage like 'date -d Tue Jan 14 08:25:26 EDT 2008 +%s', because that time stamp is invalid. Coreutils is not smart enough to correctly reject the time stamp now. Fixing this bug would take some time and is low priority. In the mean time, though, portable code shouldn't rely on invalid time stamps. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
