On Thu, Oct 03, 2024 at 03:19:09PM +0300, Anssi Saari wrote:
> writes:
>
> > What actually happens seems completely different to me: the shell
> > gets the EPIPE from the dying tee before it can see the EINTR, right?
>
> That depends. tee -i will ignore SIGINT but ./script gets it. So it can
> k
writes:
> What actually happens seems completely different to me: the shell
> gets the EPIPE from the dying tee before it can see the EINTR, right?
That depends. tee -i will ignore SIGINT but ./script gets it. So it can
keep writing in the pipe, from the script proper or its SIGINT handler
and e
Greg Wooledge (12024-10-02):
> In that case, there are THREE foreground processes which receive a SIGINT:
>
> * The interactive shell, which ignores it, because interactive shells
>always ignore SIGINT.
You are very right on the rest, but this is a mistake: the interactive
shell is not in th
On Wed, Oct 02, 2024 at 08:17:34AM -0400, Greg Wooledge wrote:
[...]
Thanks for your (as always) very exhaustive description.
> What I'm mostly trying to convey here, though, is that signals do not
> *propagate* from one process to another in any kind of automatic way.
That's more or less what
On Wed, Oct 02, 2024 at 13:59:04 +0200, to...@tuxteam.de wrote:
> On Wed, Oct 02, 2024 at 02:43:11PM +0300, Anssi Saari wrote:
> > Running ./script |& tee -i log works as expected. The script gets the
> > INT signal and cleans up.
>
> Understood.
>
> > To me, "signal passing up the pipe" is an ap
On Wed, Oct 02, 2024 at 02:43:11PM +0300, Anssi Saari wrote:
> writes:
[...]
> > Explain to us what you really mean by "signals pass up the pipe", then
> > things
> > might become clearer.
>
> I realize I didn't spell it out. It's the, to me, obvious solution to
> Tim's problem, as he wrote:
>
writes:
> On Tue, Oct 01, 2024 at 01:53:26PM +0300, Anssi Saari wrote:
>> Greg Wooledge writes:
>>
>> > On Mon, Sep 30, 2024 at 14:08:19 +0300, Anssi Saari wrote:
>> >> Tim Woodall writes:
>> >>
>> >> > However on trying to debug something else, I wanted to run it like this:
>> >> >
>> >> > .
On Tue, Oct 01, 2024 at 01:53:26PM +0300, Anssi Saari wrote:
> Greg Wooledge writes:
>
> > On Mon, Sep 30, 2024 at 14:08:19 +0300, Anssi Saari wrote:
> >> Tim Woodall writes:
> >>
> >> > However on trying to debug something else, I wanted to run it like this:
> >> >
> >> > ./script |& tee log
>
Greg Wooledge writes:
> On Mon, Sep 30, 2024 at 14:08:19 +0300, Anssi Saari wrote:
>> Tim Woodall writes:
>>
>> > However on trying to debug something else, I wanted to run it like this:
>> >
>> > ./script |& tee log
>> >
>> > and now it doesn't clean up if I it.
>>
>> Just a point here about
On Sat, 28 Sep 2024, Michael Kjörling wrote:
On 28 Sep 2024 16:28 +0100, from debianu...@woodall.me.uk (Tim Woodall):
Hmmm, I've managed to fix it. The problem seems to be related to using
echo in the exit trap itself while both stderr and stdout are redirected
- e.g. via |& tee log
If I chang
On Mon, Sep 30, 2024 at 14:08:19 +0300, Anssi Saari wrote:
> Tim Woodall writes:
>
> > However on trying to debug something else, I wanted to run it like this:
> >
> > ./script |& tee log
> >
> > and now it doesn't clean up if I it.
>
> Just a point here about tee since I didn't see anyone else
Tim Woodall writes:
> However on trying to debug something else, I wanted to run it like this:
>
> ./script |& tee log
>
> and now it doesn't clean up if I it.
Just a point here about tee since I didn't see anyone else mention
it. tee has had the -i option to ignore interrupt signals for ages.
On 28 Sep 2024 16:28 +0100, from debianu...@woodall.me.uk (Tim Woodall):
> Hmmm, I've managed to fix it. The problem seems to be related to using
> echo in the exit trap itself while both stderr and stdout are redirected
> - e.g. via |& tee log
>
> If I change the echo in the trap function to /bin
On Sat, 28 Sep 2024, Greg Wooledge wrote:
On Sat, Sep 28, 2024 at 14:53:10 +0100, Tim Woodall wrote:
Is there a way in bash to guarantee that a trap gets called for cleanup
in a script?
#!/bin/bash
trap cleanup EXIT
cleanup() {
...
}
This works in bash -- i.e., it calls the cleanup functi
On Sat, Sep 28, 2024 at 15:17:47 +0100, Alain D D Williams wrote:
> On Sat, Sep 28, 2024 at 10:13:59AM -0400, Greg Wooledge wrote:
> > On Sat, Sep 28, 2024 at 14:53:10 +0100, Tim Woodall wrote:
> > > Is there a way in bash to guarantee that a trap gets called for cleanup
> > > in a script?
> >
> >
On Sat, Sep 28, 2024 at 10:13:59AM -0400, Greg Wooledge wrote:
> On Sat, Sep 28, 2024 at 14:53:10 +0100, Tim Woodall wrote:
> > Is there a way in bash to guarantee that a trap gets called for cleanup
> > in a script?
>
> #!/bin/bash
> trap cleanup EXIT
> cleanup() {
> ...
> }
>
> This works i
On Sat, Sep 28, 2024 at 14:53:10 +0100, Tim Woodall wrote:
> Is there a way in bash to guarantee that a trap gets called for cleanup
> in a script?
#!/bin/bash
trap cleanup EXIT
cleanup() {
...
}
This works in bash -- i.e., it calls the cleanup function regardless
of whether the shell exits b
On 9/28/24 15:53, Tim Woodall wrote:
Is there a way in bash to guarantee that a trap gets called for cleanup
in a script?
I have a script that works perfectly normally and cleans up after
itself, even if it goes wrong.
However on trying to debug something else, I wanted to run it like this:
./
Is there a way in bash to guarantee that a trap gets called for cleanup
in a script?
I have a script that works perfectly normally and cleans up after
itself, even if it goes wrong.
However on trying to debug something else, I wanted to run it like this:
./script |& tee log
and now it doesn't
19 matches
Mail list logo
