On Fri, 2 Dec 2022 at 20:28, Ulrich Windl
wrote:
> Surprisingly "declare XXX=$(false);echo $?" outputs "0" (not "1")
>
"Surprising" is subjective.
There is no indication in the manual page that "declare" ignores the exit
> code of commands being executed to set values.
>
Framing this as `decla
Chet Ramey writes:
> On 12/2/22 5:28 AM, Ulrich Windl wrote:
>> Surprisingly "declare XXX=$(false);echo $?" outputs "0" (not "1")
>> There is no indication in the manual page that "declare" ignores the
>exit code of commands being executed to set values.
>
> Why do you think it should? `declare' h
On 12/2/22 5:28 AM, Ulrich Windl wrote:
Surprisingly "declare XXX=$(false);echo $?" outputs "0" (not "1")
There is no indication in the manual page that "declare" ignores the exit code
of commands being executed to set values.
Why do you think it should? `declare' has a well-defined return sta
On Fri, Dec 02, 2022 at 11:28:50AM +0100, Ulrich Windl wrote:
> Surprisingly "declare XXX=$(false);echo $?" outputs "0" (not "1")
https://mywiki.wooledge.org/BashPitfalls#pf27
On Fri, 2 Dec 2022 at 21:29, Ulrich Windl
wrote:
> Surprisingly "declare XXX=$(false);echo $?" outputs "0" (not "1")
> There is no indication in the manual page that "declare" ignores
> the exit code of commands being executed to set values.
The above is not surprising at all.
'declare' is a bu
Surprisingly "declare XXX=$(false);echo $?" outputs "0" (not "1")
There is no indication in the manual page that "declare" ignores the exit code
of commands being executed to set values.
Actually I's consider it to be a ASH bug, not a documentation bug.
Found in the real code (intended to trigger
