I'll often run a little file full of shell commands and want to see the command followed by the output so I'll run it like so:
bash -x ./files.txt > symbols.txt
Before fedora 28, that would result in symbols.txt showing the commands in files.txt with a '+' in front of them followed by the output from the command.
In fedora 28, I'm now getting 93 lines of absolute gibberish showing up before the first command which looks like this nonsense:
+ unset _mlre _mlIFS _mlshdbg + '[' 0 = 1 ']' + export MODULES_RUN_QUARANTINE=LD_LIBRARY_PATH + MODULES_RUN_QUARANTINE=LD_LIBRARY_PATH ... + PATH=/usr/share/Modules/bin:.:/userland/tom/scripts:/userland/tom/profile/progs/bin/amd64-lx:/userland/tom/profile/progs/bin/i86-lx:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local + export PATH ++ manpath + manpath=/usr/share/man:/usr/local/man:/usr/local/share/man:/usr/man + [[ ! :/usr/share/man:/usr/local/man:/usr/local/share/man:/usr/man: =~ :/usr/share/man: ]] + '[' -n '' ']'
What the heck is this nonsense?
On Tue, May 15, 2018 at 11:15:08AM -0400, Tom Horsley wrote:
In fedora 28, I'm now getting 93 lines of absolute gibberish showing up before the first command which looks like this nonsense:
So, this is pretty clearly not "gibberish" or "nonsense" -- it's obviously shell statements setting, unsetting, and exporting variables.
- export MODULES_RUN_QUARANTINE=LD_LIBRARY_PATH
- MODULES_RUN_QUARANTINE=LD_LIBRARY_PATH
... and it looks to be part of the Environment Modules package (not to be confused with Modularity in Fedora -- naming things is hard).
What the heck is this nonsense?
Probably you have installed, and perhaps enabled, the environment-modules package.
On Tue, 15 May 2018 11:24:28 -0400 Matthew Miller wrote:
Probably you have installed, and perhaps enabled, the environment-modules package.
Not me, anaconda did it :-). I've now erased it and things are back to normal. Thanks. (I read the description of this in rpm -i, and I still have no idea what it is good for).
On Tue, May 15, 2018 at 11:43:59AM -0400, Tom Horsley wrote:
Not me, anaconda did it :-). I've now erased it and things are back to normal. Thanks. (I read the description of this in rpm -i, and I still have no idea what it is good for).
It is very commonly used in high performance computing and other academic/research environments in combination with software installed in a shared NFS tree (or AFS, although probably not so much anymore).
I'm not sure what exactly pulled it in for you -- possibly a new soft dependency of some package you have installed.
Matthew Miller wrote:
On Tue, May 15, 2018 at 11:43:59AM -0400, Tom Horsley wrote:
Not me, anaconda did it :-). I've now erased it and things are back to normal. Thanks. (I read the description of this in rpm -i, and I still have no idea what it is good for).
It is very commonly used in high performance computing and other academic/research environments in combination with software installed in a shared NFS tree (or AFS, although probably not so much anymore).
I'm not sure what exactly pulled it in for you -- possibly a new soft dependency of some package you have installed.
On my system it's been installed for many releases. The difference between f27 and f28 is that environment-modules was updated from 3.2 to 4.1. The newer release includes this very noisy output. There is a way to disable most of it, by setting MODULES_SILENT_SHELL_DEBUG=1.
https://github.com/cea-hpc/modules/issues/121 was filed regarding the xtrace output (initially at SourceForge before the project moved, it appears).
It's easier to remove it though, for anyone that doesn't need it. That's what I'll be doing. It is a rather ugly effect. Arguably, the default should be silent. I can't imagine how many users would want it enabled just because they ran a script with -x for testing.
It looks like scl-utils requires it. If environment-modules is updated to 4.1 in the next RHEL, that will be a fun surprise for many of those users -- who are far more likely to have scl-utils installed, I imagine.
I wrote:
It looks like scl-utils requires it. If environment-modules is updated to 4.1 in the next RHEL, that will be a fun surprise for many of those users -- who are far more likely to have scl-utils installed, I imagine.
Talking with Matthew, I filed a ticket about this issue: https://bugzilla.redhat.com/1578587
(It's either fitting or ironic that it's a very verbose bug entry about a tool being too verbose. ;)
Looking closer, environment-modules is pulled in because scl-utils is part of the workstation-product group (and as been since at least f21).
I think the change in environment-modules is undesirable, but I'm not sure what the best solution may be. While it might be an option to drop scl-utils from the workstation group on Fedora, that doesn't solve the problem so much as hides it.
Ideally the debugging should be disabled by default upstream and done in a way that doesn't clutter the output even as much as when MODULES_SILENT_SHELL_DEBUG=1 is set.
On Tue, 15 May 2018 11:58:56 -0400 Matthew Miller wrote:
I'm not sure what exactly pulled it in for you -- possibly a new soft dependency of some package you have installed.
It was listed as coming from the @anaconda repo when I removed it, so it is apparently installed by default on the workstation live image. I see it was installed on my old fedora 27 boot partition as well, but it didn't have the bizarre side effects back in fedora 27, so I never noticed it. The only thing that depended on it was scl-utils, which I also don't need for anything, so they are both gone now.
On Tue, May 15, 2018 at 11:24:28AM -0400, Matthew Miller wrote:
Probably you have installed, and perhaps enabled, the environment-modules package.
I have that package installed on F27. And it's anything but clear whether it's enabled or not ...
Is it safe to say it's not enabled if these two path variables return zero? :
$HOME/.modulesbeginenv $MODULESBEGINENV
(from 'man module')
Thanks in anticipation
Wolfgang