On Thu, Dec 1, 2011 at 9:16 AM, Reuti <re...@staff.uni-marburg.de> wrote:
> is this really only a multi line problem? I mean: then output of env shows
> something like:
>
> foobar=() { echo yes
> }
>
> but even if you make one line out of it (with an additional ";") it can't be
> defined this way AFAICS:
>
> $ foobar() { echo yes; }
> $ export -f foobar
>
> Putting all in one line throws an error, especially with an = in the way.
If SGE records the environment variables correctly, then the execution
side (execd/shepherd) should be able to handle bash modules like any
other env. variables.
There's nothing special about those bash module functions as far as I
can tell - In fact, we can define bash modules via tcsh:
[rayson@computer ~]$ tcsh
[rayson@computer ~]$ setenv foobar2 "() { echo yes \
? }"
[rayson@computer ~]$ bash
[rayson@computer ~]$ foobar2
yes
So bash looks for the special sequence: "()" at the beginning and then
newline + "}" at the end of the environment variable's value.
Which is what we are doing now - instead of treating the newline as
the end of the env. variable's value, we look for NULL, and then we
transform new lines to some special value at job submission time; and
then at job execution time we convert those special sequences back to
the original value. Thus if everything is setup correctly, SGE itself
does not need to understand bash modules and can transport them from
the submission side to the execution side.
Rayson
>
> ==
>
> The workaround could be: define it as usual, but in a starter method.
>
> #!/bin/sh
> foobar() { echo yes; }
> export -f foobar
> exec "$@"
>
> For cosmetic reasons I would then even suggest to remove all foobar()=
> definitions from the SGE created environment file.
>
> -- Reuti
> _______________________________________________
> users mailing list
> users@gridengine.org
> https://gridengine.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@gridengine.org
https://gridengine.org/mailman/listinfo/users
