https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205176
Jilles Tjoelker <jil...@freebsd.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |Works As Intended
CC| |jil...@freebsd.org
Status|New |Closed
--- Comment #3 from Jilles Tjoelker <jil...@freebsd.org> ---
Although this may be confusing, I see no way to fix it.
To avoid major compatibility problems, make must continue to use sh's -e
option. Unfortunately, the shell language and environment do not really permit
a proper "abort on error" mechanism, and therefore and for historical reasons,
-e has various confusing properties. To avoid making things even more confusing
and becoming incompatible with other shells, this will not change.
The confusing property that is biting you here is that the left command of a &&
control operator is considered "tested", so its failure does not cause the
shell to exit. This includes everything nested within the left command.
Replacing the && after done in cycle2 with a ; will fix your problem.
As an exception, a subshell's non-zero exit status may cause the shell to exit
even if that exit status was caused by a "tested" command within the subshell.
Therefore, the part (echo $$i && false) does not cause this kind of problem.
See also the commit message for r291605: Say it with me, "I will not chain
commands with && in Makefiles". This should be fine if the command is in a
sub-shell such as: (cmd1 && cmd2)
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
