OK: myfunc () { VAR="$( return 1 )" || { some_error_trap } some_code } FAIL: myfunc () { local VAR"$( return 1 )" || { some_error_trap } some_code } ofcourse 'return 1' means some action which returns a returncode, but above code_snippet is a good test. IMHO it should work, i see no reason for not allowing that such style...(error_trap is never reached in 2nd example)
You example is unclear. Do you mean something like this? myfunc() { local VAR="$(false)" || { echo FAIL; }; echo DONE; }; myfunc It does not print FAIL in bash either. This does: myfunc() { VAR="$(false)" || { echo FAIL; }; echo DONE; }; myfunc I tested ash and hush and both match bash.
> Do you mean something like this? > > myfunc() { local VAR="$(false)" || { echo FAIL; }; echo DONE; }; myfunc yes, if 'false' means: an action, that produces a returncode != 0 > I tested ash and hush and both match bash. You are right, but this means that bash and hush are also affected - or is there a reason for "forgetting" the returncode?
to be more clear: 'false' and 'return 1' is exactly the same in this example 8-)
what you're trying to do and what behavior you have a problem with still isnt clear. instead of talking in pseudo code, post a small example of real code that isnt behavior the way you want. f() { return 1; } f if [ $? -eq 1 ] ; then echo "this should be executed" else echo "this should not be executed" fi the handling of local in hush should match bash because (1) local is not in POSIX so we have no official spec and (2) bash is the most widely used shell, so differing in behavior is just brain dead.
> clear. instead of talking in pseudo code, post a small example of real code _phonebook_get () { local NAME="$1" local NUMBER # returns a valid phonenumber, if entry exists # otherwise returns false ... } _send_sms () { local DESTINATION="$1" local TEXT="$2" local PROVIDER="$( uci get system.service.sms.provider )" local NUMBER="$( _phonebook_get $DESTINATION )" || { logger "user '$DESTINATION' unknown" return 1 } _send_sms_$PROVIDER "$NUMBER" "$TEXT" } > the handling of local in hush should match bash because (1) local is not in > POSIX so we have no official spec and (2) bash is the most widely used shell, > so differing in behavior is just brain dead. hmm, I understand your argument - but I still think, that BASH is in this case not correctly implemented. Close the ticket, I have to open a ticket @bug-bash....
then you need to bring it up on the bash lists. if bash changes behavior, we'll change hush to match. you can change your code easily by splitting the local and assignment in the mean time: local foo foo=$(false) || echo
(In reply to comment #2) > > Do you mean something like this? > > > > myfunc() { local VAR="$(false)" || { echo FAIL; }; echo DONE; }; myfunc > > yes, if 'false' means: > an action, that produces a returncode != 0 No. 'false' is not something. Such command exists. It exits with exitcode 1. My example was meant to be typed in at shell prompt literally, without any modifications. That's what good bug report should do: provide exact recipe to reproduce the bug. Yours wasn't exact. > > I tested ash and hush and both match bash. > > You are right, but this means that bash and hush are > also affected - or is there a reason for "forgetting" > the returncode? First, if we match bash, it means we don't break scripts written for bash. This is good regardless of whether bash behavior is correct or not. Second, who says it should be preserved? "local a=b" is not the same as "a=b". "local a=b" is running a builtin called "local". Every builtin has exitcode, just like normal commands. in this case it has exitcode 0: "I succeeded" "a=b" is an assignment. It's not a command. It has no exitcode. IOW: exitcode of the last command is preserved across "a=b".
BTW, it's not like we are lazy to fix this and looking for the excuses. The fix is very trivial. It's just I really don't think it's a bug.
> "local a=b" is running a builtin called "local". Every builtin has exitcode, > just like normal commands. in this case it has exitcode 0: "I succeeded" > > "a=b" is an assignment. It's not a command. It has no exitcode. IOW: exitcode > of the last command is preserved across "a=b". That sounds correct and clear to me, ticket can be closed IMHO. Thanks for your explanation.