On 2015-01-26 at 16:05, Pádraig Brady wrote:
> It should be noted that shell programming is closely related to
> functional programming. […]
>
> By trying to use filters and pipes instead of procedural shell
> statements, you get the advantage of using compiled code, and implicit
> multicore support etc.
Sorry being much late to react, I don’t always check the lists (much
content and no such time ^^') but this thread triggered me in interest.
I, for instance, usually write bash in a pretty lispy style: kebab-case
(instead of the snake_case I more often observed in big system
shellscripts) and parenthesis instead of pipes (`fun-a $(fun-b
$(fun-c))` instead of `fun1 | fun2 | fun3`), maybe due to the effect
lisp had on me (as I learned it pretty much at the same time as advanced
bash), or maybe because while the later style is more linear thus more
simple for simple and linear things, the former fits better to an
arborescent way of expressing things (which I find more natural).
I’m currently trying to learn how to take advantage of streams (not
normal pipes or std(in|out|err) but arbitrary user-defined ones (>&3 and
3<&1 for instance), named/bash-defined ones (necessarily in the other
order it seems, there: {var}<&1 then >&${var}), process substitution
(<(cmd) and >(cmd), sadly lacking a <>(cmd), or I maybe misunderstood
the previous ones), and named pipes) to achieve that form of
arborescence while saving file descriptors (and avoiding opening and
closing a file again and again) and potentially making some
parallelization, but using a lot of streams (as seeable by my preceding
mail on this list) seems to introduce less readability and really little
way of doing arborescent work (I initially hoped for something near
“tee” but more complex, without intermediary files, and builtin).
But then I wonder, command subtitutions execute sequentially (one arg
evaluated at a time) instead of parallely as pipes, but it seems they do
even when suffixing them with “&” anyway… is there any way of
reproducing this arborescent lispy style of programming while keeping
this form of parallelization bash usually simplify by putting forks all
the way?
