logo
Comunicação urgente - Comunicação confidencial
Hi! I would like to know if this i encountered is really a bug or i'm i
just doing something wrong? i'm kind off a newbie with linux, so sory if
i ask some silly question or if i am just doing it all wrong.
I am running mandrake linux 10.1 and t
On 7 Apr, G. Vamsee Krishna wrote:
: Would be nice though if it says that `rm' does the same thing to
: directories too. I still remember using `rmdir' on an empty directory
: about 2 years ago when I started using GNU/Linux.
Could we have some more opiniated input on this issue by others?
If
Paul Eggert <[EMAIL PROTECTED]> writes:
> The downside is that the patch assumes the POSIX behavior where read and
> write fail with errno==EINTR when interrupted, and so it won't work on
> ancient hosts where there's no way to get the POSIX behavior even with
> sigaction. These days, though, I d
Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> And the backtrace for the malloc(52) during the signal is :
Thanks for checking.
> #2 0x0804c783 in malloc (bytes=52) at malloc.c:3391
> #3 0x0021fc9b in _nl_make_l10nflist () from /lib/tls/libc.so.6
> #4 0x0021ddce in _nl_find_domain () from /l
On Thu, 7 Apr 2005, G. Vamsee Krishna wrote:
>Would be nice though if it says that `rm' does the same thing to
>directories too. I still remember using `rmdir' on an empty directory
>about 2 years ago when I started using GNU/Linux.
rmdir can still be useful as a less-dangerous alternative to rm
There is a similar problem in csplit.c. The simplest fix there is to
not print an error message when an interrupt occurs and a file can't
be removed afterwards, and I've prepared a draft patch to do that,
which I'd like to test a bit more before installing.
The resulting csplit program still call
Jim Meyering wrote:
Can you determine whether (with your patch) e.g., malloc is ever being
called from the signal handler?
Here is what I got when instrumenting malloc with a fprintf(stderr,
"malloc(%d)\n") :
$ ./dd if=/dev/zero of=/dev/null
malloc(5)
malloc(60)
malloc(12)
malloc(388)
malloc(60)
Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>>If there is no better way to solve the problem, then I'd consider
>>leaving the code the way it is.
>>
> Don't forget, there is my workaround, it stills cause gettext() calls in
> the signal handler, but I cannot make it fail, u
On Thu, 7 Apr 2005, Daniel wrote:
>
> It would probably help someone whos new at linux if it would read
> 'removes the directory specified and all of its content recursively'.
>
Removes the contents of the directory specified and then
removes the directory itself. I think that's the proper way
Jim Meyering wrote:
If there is no better way to solve the problem, then I'd consider
leaving the code the way it is.
Don't forget, there is my workaround, it stills cause gettext() calls in
the signal handler,
but I cannot make it fail, unlike vanilla.
--- coreutils-5.3.0/src/dd.c
+++ coreuti
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Guillaume Chazarain wrote:
>> As it prints a message for the first time, it has to
>> initialize gettext, and I'm not sure this qualifies for the "do as
>> little as possible in a signal handler" rule.
>
> I agree. The list of guaranteed async-safe function
Geert Jan van Oldenborgh <[EMAIL PROTECTED]> wrote:
> a while ago I installed the very useful coreutils on my iMac. However,
> when I tried to upgrade my free software collection with fink it
> refused. The reason turned out to be a bew uname from coreutils, which
> did not recognize the processo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[forwarding to the bug-help2man list (where is it archived?) and Brendan]
For reference on the help2man side of things, CVS coreutils is currently
using the following text in the USAGE_BUILTIN_WARNING macro to document
when a coreutils program may be
Dear Madam, Sir,
a while ago I installed the very useful coreutils on my iMac. However,
when I tried to upgrade my free software collection with fink it
refused. The reason turned out to be a bew uname from coreutils, which
did not recognize the processor:
[srikandi] [13:13] /sw% /usr/local/b
hey guys,
i've just seen something that could maybe be improved. The line in the
quickhelp screen for the rm command ('rm --help') that reads:
-r, -R, --recursive remove the contents of directories recursively
was slightly confusing to me. I didn't figure that it would also delete the
directo
15 matches
Mail list logo
