> On Thu, 12 Aug 2010 08:16:21 -0400, Greg Wooledge <wool...@eeg.ccf.org> >> A return that's run in a subshell doesn't cause the parent shell to >> return.
Granted but that does not mean it should behave like "exit", instead it could simply error like this: $ return bash: return: can only `return' from a function or sourced script It would be so much simpler if the use of "exit" was restricted to shells and subshells while the use of "return" was actually restricted to functions and sourced scripts. Are there many people actually using "return" to exit a subshell? That would not really make code easy to read. Le 13/08/2010 00:49, Martin Schwenke a écrit : > I've been programming in shell for 20 years and this one surprised me. > I have a very strong Unix background and I clearly understand things > like not being able to set variables in subshells. It also surprised > other people, with similar backgrounds, who I showed it to. It is much > less obvious than many other shell subtleties. +1, some time ago I found myself scanning documentation for ages before finding a barely clear answer to these exit/return questions, they deserve at least more documentation. > There are some obvious exceptions to the strict Unix subprocess model in > shell programming (e.g. I can set a variable without exporting it and > see it in a subshell) and I expected this to be one of them. But the unexported variable example goes from parent to child, whereas the ability from a subprocess to exit his parent would be quite a dramatic exception to the rule where a child can never have any side-effect on his parent.