[GE users] Error with "export -f" shell (bash) functions

fx d.love at liverpool.ac.uk
Wed Jan 13 21:42:05 GMT 2010

    [ The following text is in the "utf-8" character set. ]
    [ Your display is set for the "ISO-8859-10" character set.  ]
    [ Some characters may be displayed incorrectly. ]

rayson <rayrayson at gmail.com> writes:

> Note that the SGE clients happily record all the function variables,
> but bash internally puts a newline before the closing }.

I'm not sure exactly what this is about, and how we haven't seen it here
if it's triggered by modules.  However, bash will put a newline after
all statements in a function in the environment as far as I can tell,
and if newlines in environment values aren't treated properly, it's a
more general issue.

> bash does not like the function body to be all in one line, at least
> the closing } needs to be in a new line -- if I put everything all in
> one line, bash complains, and if I put the closing } in a new line,
> bash is happy:

No, one-liners are fine; the function body is any compound command and a
{}-list requires a terminating newline or semicolon (in sh generally):

  $ func2 () { echo a; echo b;}
  $ func2
  $ printenv func2
  () {  echo a;
   echo b

> So, I think it is not too hard to fix this problem -- we only need to
> make sure that the closing } is recorded during job submission, and it
> is set correctly during the environment variable setup stage in
> shepherd.

I suspect it generally needs to treat the environment correctly, but I
haven't looked at the code.  It should be perfectly fine to have
newlines in arbitrary environment values.

(Dr) Dave Love
?E-Science?, Computing Services Department, University of Liverpool
AKA fx at gnu.org


To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].

More information about the gridengine-users mailing list