3 ms·
Sometimes we want to write functions that have side effects. Subshell functions don't have side effects. Sometimes you don't want side effects, but sometimes yo
by quotemstr 5y ago
Sometimes we want to write functions that have side effects. Subshell functions don't have side effects. Sometimes you don't want side effects, but sometimes you do, and it's silly to completely foreclose on even the possibility of using side effects.
- chaps 5y agoIsn't grep your friend in this situation? I'm really not sure why you can't have side effects in this scenario.
- quotemstr 5y agoWhat on earth does grep have to do with side effects?
- chaps 5y agoAnd what makes you think side effects aren't possible in the model described? Think of grep as a way to control flow. If one side effect happens, send to stdout one thing. Another side effect, send something else. Then iterate over those outputs.
- rablackburn 5y agoA “side-effect” in this case is the ability for a function you call to do something “outside” of itself. For example, to change the value of a global variable. It’s generally considered best practice (in the functional programming community at least) to write “pure” functions (that is, functions without side effects) because it’s much easier to reason about what they are doing. So good news, subshells can _only_ be pure (the only way to get anything back from them is if they write some string to stdout), but sometimes you do actually want to have some side-effects (imagine a function that reads a config file and then wants to set some of the global variables to the values found there). Well, bad luck. If you use the subshell syntax you literally can’t do that.
- yissp 5y agoThe article didn't say you should always use subshells for functions, no exceptions. Just that most of the time it probably makes more sense to do so. And subshell functions can still have side effects like interacting with the filesystem, they just can't modify the parent shell's environment.