> I cannot change 'close-stream', since you own that module. But for
> 'fwriteerror',
> which I use in GNU gettext - and where I don't want to have spurious, timing-
> dependent error messages - I'm applying this:
I tend to agree with you on EPIPE, but OTOH this is as bad as it can be.
Can't we
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> >* lib/close-stream.c (close_stream): Ignore error EPIPE from fclose.
>> >
>> I know this condition arises only when ignoring or handling SIGPIPE,
>> (which should be rather unusual) but even so, I really dislike the idea
>> of ig
New version of patch: removed one conflicting string from test
misc/sort-version and added test strings from gnulib test-filevercmp.
Kamil
From f9bda7974f25afd920bf95d24fb680ea57adb2f0 Mon Sep 17 00:00:00 2001
From: Kamil Dudka <[EMAIL PROTECTED]>
Date: Fri, 3 Oct 2008 11:03:40 +0200
Subject: [P
Paolo Bonzini wrote:
> Is it possible to implement the "tee
> --ignore-sigpipe" as you did (delaying SIGPIPE until the last input
> closes, which I also think is the right thing to do) while having
> close-stream ignore EPIPE?
Yes it is. The complete patch was posted here:
http://lists.gnu.org/
Jim Meyering wrote:
> > EPIPE is part of the normal shutdown
> > protocol of pipes, when the pipe writer chooses to block or ignore SIGPIPE.
>
> First, you're assuming that the pipe writer chooses to
> block or ignore SIGPIPE
Yes, EPIPE only occurs if SIGPIPE is blocked or ignored.
> which is no
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> > EPIPE is part of the normal shutdown
>> > protocol of pipes, when the pipe writer chooses to block or ignore SIGPIPE.
>>
>> First, you're assuming that the pipe writer chooses to
>> block or ignore SIGPIPE
>
> Yes, EPIPE only occurs
Jim,
> Imagine a scenario in which the pipe reader is expected always to
> be reading, and so the pipe writer can expect that any write failure with
> errno==EPIPE indicates the reader has terminated unexpectedly.
If the writer should terminate first, the reader can still detect the
failure using
Bruno Haible wrote:
> Paolo Bonzini wrote:
>> Is it possible to implement the "tee
>> --ignore-sigpipe" as you did (delaying SIGPIPE until the last input
>> closes, which I also think is the right thing to do) while having
>> close-stream ignore EPIPE?
>
> Yes it is. The complete patch was posted
Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> Jim,
>
>> Imagine a scenario in which the pipe reader is expected always to
>> be reading, and so the pipe writer can expect that any write failure with
>> errno==EPIPE indicates the reader has terminated unexpectedly.
>
> If the writer should terminate fi
Jim Meyering wrote:
> Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>> Jim,
>>
>>> Imagine a scenario in which the pipe reader is expected always to
>>> be reading, and so the pipe writer can expect that any write failure with
>>> errno==EPIPE indicates the reader has terminated unexpectedly.
>> If the
Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>>> Jim,
>>>
Imagine a scenario in which the pipe reader is expected always to
be reading, and so the pipe writer can expect that any write failure with
errno==EPIPE indicates
Paolo Bonzini wrote:
> > http://lists.gnu.org/archive/html/bug-coreutils/2008-09/msg00024.html
>
> Doesn't the comment in patch 2
To make it clear:
- Patch 1 only - applies if close_stdout were modified to ignore EPIPE
always (which Jim has rejected).
- Patch 1 + 2 combined - applies if
Jim Meyering wrote:
> Imagine a scenario in which the pipe reader is expected always to
> be reading, and so the pipe writer can expect that any write failure with
> errno==EPIPE indicates the reader has terminated unexpectedly.
>>>
>>> The above was assuming that SIGPIPE is being igno
Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>
>> Imagine a scenario in which the pipe reader is expected always to
>> be reading, and so the pipe writer can expect that any write failure with
>> errno==EPIPE indicates the reader has terminated unexpectedly.
Hello Jim,
Jim Meyering wrote:
Elbert Pol<[EMAIL PROTECTED]> wrote:
...
That might make the link succeed, but without gmp support in factor.
I had just little time at the moment to test, but if i will build
without the Gmp, what effect this to the Coreutils build?
Almost none: factor would
Bruno Haible wrote:
> Paolo Bonzini wrote:
>>> http://lists.gnu.org/archive/html/bug-coreutils/2008-09/msg00024.html
>> Doesn't the comment in patch 2
>
> To make it clear:
> - Patch 1 only - applies if close_stdout were modified to ignore EPIPE
> always (which Jim has rejected).
> - Pat
Jim Meyering wrote:
> > ... if SIGPIPE is blocked or ignored.
> >
> >> which is not generally recommended.
>
> In some contexts. Some environments (mis-configured login/csh) have
> resulted in the default SIGPIPE handler being SIG_IGN.
I agree that having SIGPIPE blocked or ignoring during an ex
Paolo Bonzini wrote:
> > If you want both scenarios - the "don't know which of the two terminates
> > first"
> > and the "writer must terminate first" - to be supported by close_stream and
> > close_stdout, IMO the program needs to be able to tell these functions about
> > it, probably through a g
> What else do you propose to cover these cases, if not a global variable?
If only one behavior is needed across an entire package, a dummy module
with gl_MODULE_INDICATOR would do. Better than having fwriteerror do
one thing and close_stdout do another.
Paolo
Paolo Bonzini wrote:
> > To make it clear:
> > - Patch 1 only - applies if close_stdout were modified to ignore EPIPE
> > always (which Jim has rejected).
> > - Patch 1 + 2 combined - applies if close_stdout is as it currently is.
>
> What's wrong in having patch 1 + 2 combined with close_
Hi Jim,
Jim Meyering wrote:
Elbert Pol<[EMAIL PROTECTED]> wrote:
...
That might make the link succeed, but without gmp support in factor.
I had just little time at the moment to test, but if i will build
without the Gmp, what effect this to the Coreutils build?
Almost none: factor would wor
Elbert Pol <[EMAIL PROTECTED]> wrote:
...
>>> This is inside the libgmp.la
>>>
>>> # libgmp.la - a libtool library file
>>
>> Thanks, but that's just a wrapper script.
> It fails also when i use the --disable-gmb
Hi Elbert,
Thank you! You've just uncovered a bug!
Fixed by the patch below.
Howeve
Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>> What else do you propose to cover these cases, if not a global variable?
>
> If only one behavior is needed across an entire package, a dummy module
> with gl_MODULE_INDICATOR would do. Better than having fwriteerror do
> one thing and close_stdout do a
Hello Jim,
Thank you! You've just uncovered a bug!
Fixed by the patch below.
However, that problem is independent of the libgmp issue,
so if you apply the patch, your build should get farther.
Actually, there's another: after a failed fork, timeout is
documented to exit with status 125 (EXIT_C
Elbert Pol <[EMAIL PROTECTED]> wrote:
> Hello Jim,
>
>> Thank you! You've just uncovered a bug!
>> Fixed by the patch below.
>> However, that problem is independent of the libgmp issue,
>> so if you apply the patch, your build should get farther.
>>
>> Actually, there's another: after a failed fo
I have built coreutils-6.12 on a GNU/Linux RedHat3 system. When I use
the "cp" command with the --preserve=mode,timestamps switch there is a
problem where a copy to a nfs mounted file system does not set the
timesamp properly.
I show examples below where I run the command on GNU/Linux RedHat3 and
I was trying to build coreutils-6.12 on GNU/Linux RedHat4 and it fails
with the errors shown below.
I was able to build on GNU/Linux RedHat3.
The gcc I am using is 4.2.3. It was built on GNU/Linux RedHat3.
#
gcc -std=g
Sorry, I made a mistake on my first submission of this problem. I was
setup to use the generic GNU/Linux RedHat4 system rather then my gnu
tools.
echo $PATH
/usr/bin:/bin:/usr/X11R6/bin
I was trying to build coreutils-6.12 on GNU/Linux RedHat4 and it fails
with the errors shown below.
I was abl
Warren L Dodge <[EMAIL PROTECTED]> wrote:
> Sorry, I made a mistake on my first submission of this problem. I was
> setup to use the generic GNU/Linux RedHat4 system rather then my gnu
> tools.
>
> echo $PATH
> /usr/bin:/bin:/usr/X11R6/bin
>
> I was trying to build coreutils-6.12 on GNU/Linux RedHa
Hi Jim
I built the snapshot you gave me and indeed it does compile.
I submitted another bug about cp not preserving time when copying to a
nfs mounted directory. It still doesn't work when coreutils is built and
executed on a GNU/Linux RedHat4 system. I could not include this
information in tha
30 matches
Mail list logo
