Jean Delvare dixit: >On mer., 2017-03-22 at 10:12 +0100, Jean Delvare wrote: >> One of our customers recently asked us about the different behavior of >> constructs involving pipes in ksh scripts. I explained to them that >> mksh spawns a sub-shell for the right hand side of each pipe, and >> therefore whatever happens on that side of the pipe has no effect on >> the main shell. > >I have a hard time convincing the customer that the behavior is as >expected. They quote the manual page: > >"A function can be made to finish immediately using the return >command;" > >Which indeed isn't what's happening.
Of course it isn’t because the return command is not called from within a function but from within a subshell which, while contained in a function, is not “in a function”. This is no different to any non-last part of a pipeline in such shells — calling return in anything BEFORE a pipe would also not “work” as requested. >The read loop FAQ (about pipes spawning subshells) mentions the >inability to propagate variable changes back to the original shell, but >says nothing about the altered effect of "return" or "exit". It has not come up as a problem so far. >May I suggest that the manual page gets updated in the following ways: Yes, thank you. >I can prepare and send a patch doing (some of) these changes if you >agree with them. > >Maybe it would also make sense to add a specific paragraph or section >somewhere about subshells. In various places, the manual page explains Feel free to send such a patch. >that a given construct will (or will not) spawn a subshell, but there >is no central place explaining what a subshell is nor the limitations >that it creates. You probably know more than I do on the topic. I know >about the variable propagation (or more generally the separate >environments), return and exit, but maybe there is more? A subshell involves fork(), it’s as easy as that.
