|
From: Paul M. <pau...@gm...> - 2021-10-14 15:15:11
|
You could also get complicated and implement this as a script, that tests that the first argument is a valid shell name (that list is a bit long).
And then either echos a warning, or assumes a default if it is not a shell (you should have it echo out some help if there are no arguments).
On 10/14/2021 9:45 AM, Paul Markfort wrote:
>
> I use a (BASH) alias for that (the second one makes it easy to specifically test in bash).
>
> alias test-module-anyshell='tclsh $MODULESHOME/default/libexec/modulecmd.tcl $* 2>&1'
> alias test-module-bash='tclsh $MODULESHOME/default/libexec/modulecmd.tcl bash $* 2>&1'
>
> Basically, it echos out what will be sent to the "eval" command of the shell.
>
> So if you want to know what a module will actually do, you just use test-module-bash {command} {module_name}.
>
> example:
>
> test-module-bash load junk
>
> Or:
> test-module-anyshell bash load junk
> test-module-anyshell csh load junk
>
>
>
> The output can be redirected to a file (it will include all the stdout and stderr output).
>
>
> On 10/14/2021 7:33 AM, Sternberg, Michael G. via Modules-interest wrote:
>> Xavier,
>>
>> Indeed, thank you for integrating this!
>>
>> Now that "module sh-to-mod" is implemented internal to modulecmd.tcl, an interesting question and opportunity comes up: Would it be useful – or even necessary for consistency – to have sh-to-mod *filter out* (i.e., not issue) modifications of module-internal variables, like I did pragmatically with grep? Such internals would not be of interest for later deployment of the generated module, and make for an "Inception" challenge to modulecmd on eventual load. Having module invocations already occur in the input is certainly an edge case, but one that could well come up in porting situations.
>>
>> Michael Strelnikov: Could you illustrate the motivation of your question?
>>
>>
>> With best regards,
>> Michael
>>
>>
>>> On Oct 13, 2021, at 23:50, Xavier Delaruelle <xav...@gm...> wrote:
>>> […] Please note that the createmodule.py script has been replaced by the
>>> "sh-to-mod" sub-command of module:
>>> https://modules.readthedocs.io/en/latest/MIGRATING.html#sh-to-mod-sub-command
>>> Regards,
>>> Xavier
>>>
>>> Le jeu. 14 oct. 2021 à 02:10, Sternberg, Michael G. via
>>> Modules-interest <mod...@li...> a écrit :
>>>>
>>>> […] you could let Modules itself do the work of gathering and interpreting the accumulated changes of environment vars:
>>>> echo module load foo > /tmp/foo.sh
>>>> createmodule.py /tmp/foo.sh \
>>>> | grep -Ev '(_modshare|MODULES_LM|_LMFILES_|LOADEDMODULES)'
>>
>>
>> _______________________________________________
>> Modules-interest mailing list
>> Mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>>
>
--
--------------------------------------------------------
The views and opinions expressed above are strictly
those of the author(s). The content of this message has
not been reviewed nor approved by any entity whatsoever.
--------------------------------------------------------
Paul FM Info: http://paulfm.com/~paulfm/
--------------------------------------------------------
|
