[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