On 11/02/10 02:14, Michael Stone wrote:
FAIL: tail-2/inotify-hash-abuse2 (exit: 1)
==
tail: `f' has become inaccessible: No such file or directory
./tail-2/inotify-hash-abuse2: line 34: kill: (13733) - No such process
./tail-2/inotify-hash-abuse2: line
On 11/02/10 10:29, Pádraig Brady wrote:
On 11/02/10 02:14, Michael Stone wrote:
FAIL: tail-2/inotify-hash-abuse2 (exit: 1)
==
tail: `f' has become inaccessible: No such file or directory
./tail-2/inotify-hash-abuse2: line 34: kill: (13733) - No such
hello
i faced a very strange behaviour with the coreutils 8.4 chmod tool:
i mounted a dvd-ram and didn't recognize that it was mounted read-only
(don't know why, actually). my first thought was that the access rights
to the files were set improper. because the disk stores only archival
stuff for
hello
using -h with du on a directory tree can produce results several
gigabytes *below* the actual value. this is quite annoying (and just
plain wrong), especially when trying to burn a cd/dvd.
regards,
Dennis Heuer dh-b...@online.de
On Thu, 11 Feb 2010, dh-b...@online.de wrote:
using -h with du on a directory tree can produce results several
gigabytes *below* the actual value. this is quite annoying (and just
plain wrong), especially when trying to burn a cd/dvd.
du -h doesn't do what you expect. Quoting the manual:
Hello!
My question is the following:
Will there be a '-m' or '--chars' option for tail and head? Because, when
processing Unicode, the -c (--bytes) option isn't very useful.
Well, of course, it does what it should do - but I think it was designed with
byte==char in mind (which is probably why
According to richard.wos...@gmx.de on 2/11/2010 6:10 AM:
Hello!
My question is the following:
Will there be a '-m' or '--chars' option for tail and head? Because, when
processing Unicode, the -c (--bytes) option isn't very useful.
Eventually, when someone contributes a maintainable patch
dh-b...@online.de 写道:
hello
i faced a very strange behaviour with the coreutils 8.4 chmod tool:
i mounted a dvd-ram and didn't recognize that it was mounted read-only
(don't know why, actually). my first thought was that the access rights
to the files were set improper. because the disk
On Thu, 11 Feb 2010 21:54:19 +0800
jeff.liu jeff@oracle.com wrote:
could you supply more info?
am not shure what you want to hear? as written, there was no message on
screen. after the mistake, i remounted the dvd-ram with -o rw and tried
again (using arrow up and enter) and it worked.
Pádraig Brady P at draigBrady.com writes:
I noticed a few more extraneious '.' in --help output
+++ b/src/base64.c
@@ -62,10 +62,9 @@ Base64 encode or decode FILE, or standard input, to
standard output.\n\
\n), program_name);
fputs (_(\
-w, --wrap=COLS Wrap encoded lines
On 11/02/10 15:25, Eric Blake wrote:
Pádraig BradyPat draigBrady.com writes:
I noticed a few more extraneious '.' in --help output
+++ b/src/base64.c
@@ -62,10 +62,9 @@ Base64 encode or decode FILE, or standard input, to
standard output.\n\
\n), program_name);
fputs (_(\
Alan Curry wrote:
I already answered this the first time it was sent. The archive has my
message:
http://lists.gnu.org/archive/html/bug-coreutils/2010-02/msg00020.html
Sorry. I missed seeing that message when it went by. But there it is
in the archive. I had missed it. Thanks for
Alan Curry wrote:
Tom writes:
I'm using Ubuntu 9.10 (32-bit).
I'm trying to use an ASR-33 Teletype (uppercase only)
Are you trying to write the best message this mailing list has ever aseen?
Because so far, it is.
I agree. It puts my vt100 to shame. :-)
As you can see, iuclc is set
--
From: Bob Proulx b...@proulx.com
Sent: Thursday, February 11, 2010 12:32 PM
To: Tom tl...@twcny.rr.com; bug-coreutils@gnu.org
Subject: Re: Stty bug?
Alan Curry wrote:
Tom writes:
I'm using Ubuntu 9.10 (32-bit).
I'm trying to use an ASR-33
Pádraig Brady wrote:
...
Actually there are a few more instance of that (due to me):
$ grep -E -.* [A-Z] *.c | grep -v FILE
base64.c: -d, --decode Decode data\n\
base64.c: -i, --ignore-garbage When decoding, ignore non-alphabet
characters\n\
base64.c: -w, --wrap=COLS
On 11/02/10 21:29, Jim Meyering wrote:
Pádraig Brady wrote:
...
Actually there are a few more instance of that (due to me):
$ grep -E -.* [A-Z] *.c | grep -v FILE
base64.c: -d, --decode Decode data\n\
base64.c: -i, --ignore-garbage When decoding, ignore non-alphabet
dh-b...@online.de 写道:
On Thu, 11 Feb 2010 21:54:19 +0800
jeff.liu jeff@oracle.com wrote:
could you supply more info?
am not shure what you want to hear? as written, there was no message on
screen. after the mistake, i remounted the dvd-ram with -o rw and tried
again (using arrow up
Hi All
I had my thunderstorm cloud flying over my head again and managed to
drop this mail.
I suggest kill eatin' names instead of numbers example:
kill 'process name'
and ps sorting processes alphabetically example:
ps -'free letter'
thanks, have a good time
and don't make myself bad weather,
Is it possible to change the formatting of man pages so that
they are not justified and have no hyphenation?
If so, which files have to be modified, and what would need to
be changed?
--
Chris F.A. Johnson, http://cfajohnson.com
Author:
Pro Bash
According to Jan Girke on 2/11/2010 3:36 PM:
Hi All
I had my thunderstorm cloud flying over my head again and managed to
drop this mail.
I suggest kill eatin' names instead of numbers example:
kill 'process name'
And how exactly do you propose mapping 'process name' back to a particular
On Thursday 11 February 2010 17:36:55 Jan Girke wrote:
I suggest kill eatin' names instead of numbers example:
kill 'process name'
what's wrong with `killall` ?
-mike
signature.asc
Description: This is a digitally signed message part.
21 matches
Mail list logo
