should BASH_ENV be modified at all; is there any alternative?

[fgeorgatos]

This could be coming from either our Lmod (ie. us) or, it could be some of profile.d under Bright;
in any case, undesired (long) output appears and we need to investigate where it comes from:

[userY@nodeX ~]$ time bash -fx bashscript.sh 
+ LMOD_PKG=/usr/share/lmod/lmod
+ LMOD_DIR=/usr/share/lmod/lmod/libexec
+ LMOD_CMD=/usr/share/lmod/lmod/libexec/lmod
+ MODULESHOME=/usr/share/lmod/lmod
+ export LMOD_PKG
+ export LMOD_CMD
+ export LMOD_DIR
+ export MODULESHOME
+ LMOD_VERSION=6.1
+ export LMOD_VERSION
+ '[' : '!=' : ']'
+ unalias ml
+ true
++ echo YES
++ /usr/bin/tr '[:upper:]' '[:lower:]'
+ export_module=yes
+ '[' -n '4.1.2(1)-release' -a yes '!=' no ']'
+ export -f module
+ export -f ml
+ unset export_module
+ '[' -n '' ']'
+ '[' 4 -ge 3 ']'
+ '[' -r /usr/share/lmod/lmod/init/lmod_bash_completions ']'
+ '[' -n '' ']'
[....then the real tracing starts...]

[rtmclay]

That comes from setting BASH_ENV to in your case to /usr/share/lmod/lmod/init/bash. This is how a bash shell script can use the module command. You can either unset BASH_ENV and lose the ability to use the module command in a bash script OR there could be some echo statements added to init/bash to say something like "Start of init/bash for Lmod module command" and "End of init/bash for Lmod module command to start and end the script.

[fgeorgatos]

@rtmclay : thanks for commenting on this! indeed I was suspecting some initialization magic;

we need to understand if the current approach is desired or it can be improved upon;
if possible, I'd rather not have the bash -fx spitting this long sequence; it's confusing users :-(

[fgeorgatos]

There are two sub-issues here:

• one is to stop the bash shell tracing, set +x is the opposite of set -x; use it in the beginning
• 2nd, is to eliminate the need for BASH_ENV altogether (infeasible? caveats?)

[fgeorgatos]

• sub-issue Create/retrieve .spec file for Lmod/6.1 #1 ; it indeed can be suppressed inside /usr/share/lmod/lmod/init/bash w. top-posting:

true '## Lmod initialized ##'
set +x

• sub-issue MODULEPATH definitions under /etc/profile.d must be w. guarded variable #2 ; This has been on the most eye-opening emails I have ever read in HPC context;

  bash requires some hackery to overcome innate behaviour:
  https://sourceforge.net/p/lmod/mailman/message/32649428/

The incredible part on the latter was:

We did a "ulimit -s" in the scripts in /etc/profile.d but for the * programs
that were run by bash users would fail because the system files were not read.

[fgeorgatos]

OK. /usr/share/lmod/lmod/init/bash now includes the set +x and shell tracing is no more annoying.

However, there is the more tricky question about bash initialization overall and the fact that one man's BASH_ENV is another one's bug (ie. only one tool can capture attention of BASH_ENV, ie. it is not a very optimal design as it has now).

[fgeorgatos]

@johnnydevaprasad , @rtmclay
priority of handling this needs to be bumped up, because blindly setting up set +x proves to be a pain:

• unless you unset BASH_ENV, tracing bash -x -c 'echo hello' does not yield the expected output