Hi,
Am 01.12.2011 um 14:31 schrieb Prentice Bisbal:
>> <snip>
>> I finally had some time to dig around on my systems, and here's what I
> found. Some of this will be obvious to experienced RHEL admins/users,
> but I'm just trying to be complete, and provide a full explanation for
> future googlers:
>
> 1 ./etc/bashrc or /etc/profile will source the files in /etc/profile.d,
> which includes modules.sh
>
> 2. /etc/profile.d/modules.sh will call /usr/share/Modules/init/$shell or
> /usr/share/Modules/init/sh:
>
> $ more modules.sh
> shell=`/bin/basename \`/bin/ps -p $$ -ocomm=\``
> if [ -f /usr/share/Modules/init/$shell ]
> then
> . /usr/share/Modules/init/$shell
> else
> . /usr/share/Modules/init/sh
> fi
>
> Since my shell is bash, /usr/share/Modules/init/bash is called.
>
> 3. Amongst other things, /usr/share/Modules/init/bash defines the
> function module() and then exports it in the first two lines of code:
>
> module() { eval `/usr/bin/modulecmd bash $*`; }
> export -f module
>
> As you can see, there is a closing bracet, which is missing from the SGE
> environment. Looking at the output of the 'env' command, I can confirm
> that the full definition of module (from opening brace to closing brace)
> makes it to my normal interactive, non-SGE environment. It looks like
> this in the output of env:
>
> module=() { eval `/usr/bin/modulecmd bash $*`
> }
>
> Notice, however, that the semicolon in the original definition is now a
> new-line command. Which makes sense, but it must be tripping SGE due to
> the known bug with multi-line environment variables in SGE 6.2u5, which
> is what I'm using, as Reuti pointed out.
>
> It looks like I could just remove the environment modules packages from
> my systems, but I do plan on using them in the near future, so I need to
> fix this. I didn't have modules installed when running RHEL 5, so that
> explains why this error just popped up after the upgrade to RHEL 6. Will
> upgrading to an SGE 6.2 update greater than 5 fix my problem? Is an
> update after u5 even available now, post-Oracle?
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.
==
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
[email protected]
https://gridengine.org/mailman/listinfo/users
