Re: [Help-bash] Closure concept in bash

[Peng Yu]

> You have defined a function "testing" in this script and then are
> trying to call it from 'parallel' which will invoke a completely
> different shell.  That feels awful to me.  Instead I would define them
> in the script called from parallel.

Sometime, it is possible to do so. But it not always, for example, you
have some variable that is read from the command line (using getopt).

> But you have discovered that bash can "export" functions and store
> them as text strings in exported variables.  Then later a different
> bash subshell will parse the environment strings back into live
> functions in a different shell.  Gack.  It works in a limited way but
> the problems of trying to use that in a large scale way are terrible.
>
> Some Problems:
>
> Does 'parallel' call 'bash' or 'sh' later?  I don't know but probably
> it calls sh since that is the standard thing to do.  Depending upon
> the system sh won't understand those exported functions.  (Greg noted
> this problem too.)

I don't know whether parallel uses 'bash' or 'sh'. But it seems that
it understands bash function. Is bash function and sh function
interchangeable?

> Text representations of programs take up a lot of memory space in the
> environment.  And that memory space is parsed by bash later and stored
> in internal form.  It is memory inefficient.
>
> The name space is global.  If you have two programs both using this
> technique then they can collide on names.  You would need to use a
> naming convention (such as myproject_myfunctionname) in order to
> organize around colliding with other uses of the same name.

This is the problem of global variables. Closure can solve this
problem as I mentioned to the other email to Greg and the mailing
list.

> Some Alternatives:
>
> I am sure parallel is nifty and I don't want to disparage it but in
> this context it isn't needed.  If you just want to launch programs in
> the background you would be better off simply launching programs in
> the background.  Within limits.  If I were running ten or even thirty
> lightweight processes then I would simply launch them.

There is a tendency in the mailing trying to make my examples even
simpler than it should be. But please, I have already make them the
simplest, you don't have to make it simpler. If they are made even
simpler, the gist of the problem will be lost.

In my real case, the function can run hours and take GBs of memory.
For the sake of testing, I have to use a very fast function (echo).
But don't assume my real case is that simple.

> I have no idea what problem you are trying to solve.

Call gnu parallel in the most convenient way (meaning using the least
amount of time to type the code, while make it readable and
maintainable).

-- 
Regards,
Peng