Re: Return status of command substitution with $(...) "gets lost"
On 3/11/10 4:24 AM, Marc Herbert wrote: > Chet Ramey a écrit : >>> On the other hand, local is not specified by POSIX. What would it hurt >>> to redefine the exit status of local to reflect the status of any >>> command substitutions performed during the local assignments (short of >>> compatibility with zsh)? >> >> I think that would be a bad idea, and am not inclined to do it. > > Care to elaborate a bit? (preferably on the public list) Because that's not what local and its siblings (declare/typeset/export/ readonly) do. These builtins exist to assign and modify variable attributes. As an added feature, they support value assignment at the same time, but the important function is the attribute setting. They don't need to know how the value was computed. (Yes, a secondary function is to insulate the shell programmer from assignment errors that might otherwise cause the shell to exit, and the ability to create variables with local scope is clearly a hole in Posix.) Since the function is setting the attribute or value, the exit status should reflect whether or not that succeeded. For instance, attempting to modify a read-only variable, or to assign a variable with an invalid name, which would cause a Posix shell to exit, should be reflected in the exit status. For instance, should this succeed or fail? local -r foo=$(echo a; exit 1) After all, the variable was correctly created, and ends up with the desired attribute. Is that not the intent of the statement? To Posix, assignment statements never fail -- assignment errors cause non- interactive shells to exit, period. In that case, it's possible to reflect the exit status of a command substitution in the exit status of a command consisting only of assignment statements, though that has problems of its own and is only reliable on commands consisting of a single assignment. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Return status of command substitution with $(...) "gets lost"
Chet Ramey wrote: > To Posix, assignment statements never fail -- assignment errors cause > non- interactive shells to exit, period. In that case, it's possible > to reflect the exit status of a command substitution in the exit > status of a command consisting only of assignment statements,... It's possible... and required by POSIX, right? At least this is my understanding of section "2.9.1 Simple Commands". More precisely: "... with the exit status of the LAST command substitution performed" Just to make things less abstract, here is some (simplified) code I often find useful: local _res if _res=$( some_code... ); then echo $_res elif _res=$( some_other_code... ); echo $_res else return 1 fi > ... though that has problems of its own and is only reliable on commands > consisting of a single assignment. Here you seem to imply this is actually an "advanced" and thus non-standard feature (why I have no clue). An unreliable feature would never have been standardized for sure...
Re: Return status of command substitution with $(...) "gets lost"
On 03/11/2010 09:27 AM, Marc Herbert wrote: > Chet Ramey wrote: > >> To Posix, assignment statements never fail -- assignment errors cause >> non- interactive shells to exit, period. In that case, it's possible >> to reflect the exit status of a command substitution in the exit >> status of a command consisting only of assignment statements,... > > It's possible... and required by POSIX, right? POSIX says nothing about local. But yes, POSIX requires that: a=$(b) set $? to the status of running the command substitution. > Here you seem to imply this is actually an "advanced" and thus > non-standard feature (why I have no clue). An unreliable feature would > never have been standardized for sure... The question at hand is whether: local a=$(b) should set the exit status to the command substitution (a change in behavior), or to the status of running the 'local' command (the current behavior). I threw out the question about change as a discussion point, but I'm perfectly fine with Chet's response that the current behavior will stay as is. If you'd like 'local' to be standardized in the next version of POSIX, several years from now, that would also be a good goal; help in submitting the proposal to the Austin group would be appreciated. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Return status of command substitution with $(...) "gets lost"
On 3/11/10 11:32 AM, Eric Blake wrote: > If you'd like 'local' to be standardized in the next version of POSIX, > several years from now, that would also be a good goal; help in > submitting the proposal to the Austin group would be appreciated. I thought an early draft of Posix.2 (in those days) included a definition of `local' and its behavior (d9, probably). I just can't lay my hands on a copy right now. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Bash manual - interactive shell definition
On page http://www.gnu.org/software/bash/manual/bashref.html#Bash-Startup-Files Could this sentence: "An interactive shell is one started without non-option arguments, unless -sis specified, without specifying the -c option, and whose input and error output are both connected to terminals (as determined by isatty(3)), or one started with the -i option. " be any more confusing?
