Chris's Wiki :: blog/unix/BashWhyFunctionImport Commentshttps://utcc.utoronto.ca/~cks/space/blog/unix/BashWhyFunctionImport?atomcommentsDWiki2014-11-06T17:20:24ZRecent comments in Chris's Wiki :: blog/unix/BashWhyFunctionImport.By Chris Siebenmann on /blog/unix/BashWhyFunctionImporttag:CSpace:blog/unix/BashWhyFunctionImport:c4e8034fd32febd4626824f6430aa963ee028ebbChris Siebenmann<div class="wikitext"><p>lotheac: I think I was unclear in my entry. By 'subshell' I didn't mean
a directly <code>fork()</code>'d copy of the main process but a new <code>exec()</code>'d
shell process that is a descendent of your main shell. In many
environments there are a number of these and they are created quite
frequently (especially back in 1989, when people working in graphical
Unix environments spent most of their time in shells in <code>xterm</code>s instead
of in a browser).</p>
<p>Beyond being a performance improvement, this also strikes me as natural
and Unixy. If the shell can export things into the environment so that
future descendent shells can import them, why restrict that to plain
variables? Allow it to export and import everything instead.</p>
<p>(There are potential issues with this, but at least <code>rc</code> sidestepped
them by having an explicit flag that said 'do not import functions
from the environment'. Rc scripts almost always use this flag in their
'<code>#!</code>' line. I suspect that the V8 shell had a similar option.)</p>
</div>2014-11-06T17:20:24ZBy Christian Neukirchen on /blog/unix/BashWhyFunctionImporttag:CSpace:blog/unix/BashWhyFunctionImport:770608968f5e9cce2da05a75b1adb0a6d715b8b3Christian Neukirchenhttp://chneukirchen.org/<div class="wikitext"><p>Indeed, the Research Unix v8 shell had this feature too (as well as a shellshock-style bug, which they fixed).</p>
<p>One nice use could be to use <code>find . -exec myshellfn</code>.</p>
<p>Another use could be to transport shell functions over ssh. Not sure everyone thinks that is a good idea, but I'd like it.</p>
</div>2014-11-06T14:35:10ZBy opk on /blog/unix/BashWhyFunctionImporttag:CSpace:blog/unix/BashWhyFunctionImport:8d22b6e7d5c9cd8e783749915bb553bf1027c6e9opk<div class="wikitext"><p>You might find this old post from Rob Pike interesting. This might imply that the v8 shell also exported functions: <a href="http://marc.info/?l=9fans&m=111558921626149">http://marc.info/?l=9fans&m=111558921626149</a></p>
<p>I'm fairly sure you're right about performance being the original driver behind exportable functions. Along with overriding commands for test harnesses, performance is the other use for exported functions I've seen cited in the wake of shellshock.</p>
<p>The ksh and zsh solution to the problem is autoloadable functions. So you have FPATH (or fpath in array form) as an analogous variable to PATH and files containing functions are only read when used. Even on moderate hardware, these make a difference to startup times given a good collection of functions. For something like the zsh completion functions, it is massive. Zsh also allows for preparsing into wordcode files. Exported functions don't save on parsing the functions as you somewhat imply in your post.</p>
</div>2014-11-06T08:41:43ZBy lotheac on /blog/unix/BashWhyFunctionImporttag:CSpace:blog/unix/BashWhyFunctionImport:b56083c989a7b921530776ac4fdeaf8d6bec8f9blotheac<div class="wikitext"><p>You don't mention that subshells, ie. direct children of the parent shell, don't need to exec after fork. If the child process is a clone of the parent, it already has access to every function and variable defined in the parent, even if they aren't exported. I'm still having trouble understanding why this feature exists - I can't imagine the usecase for passing functions to indirect children (started by your editor perhaps) being so common that it would warrant a performance enhancement like this.</p>
</div>2014-11-06T08:21:35Z