bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Logical expressions and job control


From: Godmar Back
Subject: Re: Logical expressions and job control
Date: Fri, 10 Feb 2023 13:44:42 -0500

Hi Martin,

thank you for your response.

On Fri, Feb 10, 2023 at 1:20 PM Martin Schulte <gnu@schrader-schulte.de>
wrote:

> Hi Godmar!
>
> > For instance:
> >
> > gback@lat2022:~$ sleep 10 && echo yes
> > ^Z
> > [1]+  Stopped                 sleep 10
> > gback@lat2022:~$ fg
> > sleep 10
> > gback@lat2022:~$
> >
> > ...
> >
> > What's the rationale for bash's behavior in this case and is this
> something
> > that should be changed?
>
> I assume this is because sleep "exits" with an exit status of 148
> (=128+SIGTSTP) when it is stopped. If you replace the && with an ;, you get
> "yes" immediately after pressing ^Z.
>
>
So this is a bug, then, perhaps due to a shortcoming in the implementation
that prevents it from storing and resuming the evaluation context within
the currently evaluated boolean expression across stops/continuations?

It appears to be mistaking the wait status for the exit status if your
hypothesis is correct. This would mean that it may be accessing the wait
status returned from `waitpid()` or similar in raw form (status != 0),
without using proper `WIFSTOPPED`/`WIFEXITED` macros to predicate that
test.  That in turn seems unlikely, so maybe it's `if (WIFEXITED() &&
WEXITSTATUS() == 0) ... success else failure` which would apply in the job
control case.

 - Godmar


reply via email to

[Prev in Thread] Current Thread [Next in Thread]