|
From: Xavier D. <xav...@gm...> - 2025-01-29 19:25:58
|
I think the following kind of code should handle other modes (like
unload) and Modules v3:
if {[module-info type] eq {Tcl} && [module-info mode] eq {load}} {
puts stdout ...
} else {
set-alias ...
}
Xavier
Le mer. 29 janv. 2025 à 16:12, Paul Markfort <pau...@gm...> a écrit :
>
> the puts should work with 3.2.12
> But yes it will break the unload (it will just redefine the alias).
>
> You will have to put in code (that is both 3.2 and 4.8 compatible) to not only check what mode you are in, but also what shell it is producing code for (so you only use the alias command for shells that support it).
> Then run the puts accordingly (one to define the alias, another to undefine it).
>
> If the alias definition works for 3.2.12, you could check what version of modules is calling the module (then use the standard method if it is 3.2.12).
>
> It is important to remember that modules work by producing code (with puts) that is output to the shell's eval command.
>
>
> Another "fix" would be to define the alias to source a particular file, and have that file have the commands.
> Like:
> set-alias mycommand "source /usr/local/bin/_mysubcommand.csh"
>
> Then put the commands in the _mysubcommand.csh file.
>
> #!/bin/tcsh
> bsub -R "select[type==X64LIN && osrel==$osrel]" myapp
>
> Note, if bsub does not make any changes in the shell's environment, then the alias could be:
> set-alias mycommand "/usr/local/bin/_mysubcommand"
> And _mysubcomand should be executable.
> Or, you could skip the alias, and put a "mysub" executable in a path that is only available when the module is loaded.
>
>
>
>
>
> On 2025-01-29 8:40 AM, Andreas Frank wrote:
> > Thank you Laurent and Xavier.
> >
> > And thanks for the hint with the puts-workaround.
> > That may be feasible, although I have to see whether we can keep
> > compatibility with Module 3.2 this way, which is required here for some
> > modulefiles.
> >
> > And wouldn't this break the unload mechanism?
> >
> > BR,
> > Andreas
> >
> >
> > Am Mi., 29. Jan. 2025 um 15:03 Uhr schrieb Xavier Delaruelle <
> > xav...@gm...>:
> >
> >> Many thanks Laurent for your analysis.
> >>
> >> I have created a ticket to fix this issue that is still present on
> >> latest version:
> >> https://github.com/envmodules/modules/issues/565
> >>
> >> From what I understand, the bracket characters should be espaced when
> >> producing output for csh/tcsh shells.
> >>
> >> Laurent you see the $osrel variable not replace maybe because you
> >> define the alias content between curly braces (that inhibit variable
> >> expansion).
> >>
> >> In the mean time Andreas, I suggest you to use the puts command to
> >> manually craft the shell code:
> >>
> >> #%Module
> >> set osrel 80
> >> puts stdout "alias mycommand bsub\\ -R\\ \"select\\\[type==X64LIN &&
> >> osrel==$osrel\\\]\"\\ myapp;"
> >>
> >> Best regards,
> >> Xavier
> >>
> >> Le mer. 29 janv. 2025 à 14:52, Laurent BESSON
> >> <lau...@ea...> a écrit :
> >>>
> >>> I did not run a full regression test but by modifying 2 lines inside
> >> modulecmd.tcl like this :
> >>>
> >>>
> >>>
> >>> proc charEscaped {str {charlist " \\\\\t{}\[\]|<>!;#^\$&*?\"'`()"}} {
> >>>
> >>> return [regsub -all "\(\[$charlist\]\)" $str {\\\1}]
> >>>
> >>> }
> >>>
> >>>
> >>>
> >>> proc charUnescaped {str {charlist " \\\\\t{}\[\]|<>!;#^\$&*?\"'`()"}} {
> >>>
> >>> return [regsub -all "\\\\\(\[$charlist\]\)" $str {\1}]
> >>>
> >>> }
> >>>
> >>>
> >>>
> >>> I’m able to define the alias properly.
> >>>
> >>>
> >>>
> >>> However, I’ve seen another issue as the $osrel variable was not replaced
> >> by its value. Maybe this is intended ? I’ll let Xavier comment on this.
> >>>
> >>>
> >>>
> >>> Best regards,
> >>>
> >>> Laurent.
> >>>
> >>>
> >>>
> >>> De : Laurent BESSON <lau...@ea...>
> >>> Envoyé : mercredi 29 janvier 2025 11:21
> >>> À : Environment Modules usage and discussion. <
> >> mod...@li...>
> >>> Objet : Re: [Modules] aliases with square brackets in tcsh and modules
> >> 4.8.0
> >>>
> >>>
> >>>
> >>> Hello,
> >>>
> >>>
> >>>
> >>> Good news : I did reproduce your issue
> >>>
> >>> Bad news : I see the same behaviour (not saying bug yet !) with version
> >> 5.5.0
> >>>
> >>>
> >>>
> >>> If you just launch :
> >>>
> >>>
> >>>
> >>> /usr/bin/tclsh ‘<path to your module version>/libexec/modulecmd.tcl'
> >> tcsh load <your module>
> >>>
> >>>
> >>>
> >>> You will see what actually real alias command is computed by module.
> >>>
> >>>
> >>>
> >>> With this line in the module :
> >>>
> >>>
> >>>
> >>> set-alias mycommand {bsub -R "select\[type==X64LIN \&\& osrel==$osrel]"
> >> myapp}
> >>>
> >>>
> >>>
> >>> I get this alias :
> >>>
> >>>
> >>>
> >>> alias mycommand bsub\ -R\ \"select\\[type==X64LIN\ \\\&\\\&\
> >> osrel==\$osrel]\"\ myapp;
> >>>
> >>>
> >>>
> >>> It seems Module sees the « \ » and escape it adding another « \ ». But
> >> it does not do it for the square bracket itself.
> >>>
> >>>
> >>>
> >>> At the end, I would say it is a bug inside Module.
> >>>
> >>>
> >>>
> >>> Dear community, what do you think ?
> >>>
> >>>
> >>>
> >>> BR,
> >>>
> >>> Laurent.
> >>>
> >>>
> >>>
> >>> De : Andreas Frank <af...@me...>
> >>> Envoyé : mercredi 29 janvier 2025 10:49
> >>> À : mod...@li...
> >>> Objet : [Modules] aliases with square brackets in tcsh and modules 4.8.0
> >>>
> >>>
> >>>
> >>> Hello,
> >>>
> >>>
> >>>
> >>> we are currently trying to migrate from Modules 3.2.12 to 4.8.0.
> >>>
> >>> Environment is RedHat 8 & 9, shell is tcsh.
> >>>
> >>> We do not have the option to switch to anything else currently.
> >>>
> >>>
> >>>
> >>> I need to have something like
> >>>
> >>>
> >>>
> >>>> set osrel 80
> >>>
> >>>> set-alias mycommand "bsub -R \"select[type==X64LIN && osrel==$osrel]\"
> >> myapp"
> >>>
> >>>
> >>>
> >>> However, no matter what kind of escaping and quoting I apply (or none at
> >> all), I always end up with tcsh complaining:
> >>>
> >>>
> >>>
> >>> alias: No match.
> >>>
> >>>
> >>>
> >>> It seems the square brackets end up unescaped and unquoted in the tcsh
> >> alias command, no matter what I try. Resulting in a failing shell pattern
> >> match which is not what I want of course.
> >>>
> >>>
> >>>
> >>> I tried:
> >>>
> >>> [...]
> >>>
> >>> \[...\]
> >>>
> >>> {[...]}
> >>>
> >>> {\[...\]}
> >>>
> >>> {\\[...\\]}
> >>>
> >>> {\\\[...\\\]}
> >>>
> >>> "[...]"
> >>> "\[...\]"
> >>> "\\[...\\]"
> >>> "\\\[...\\\]"
> >>>
> >>> and probably some more, all without success.
> >>>
> >>>
> >>>
> >>> Is there a way to get this working in 4.8.0? Is it a bug that's maybe
> >> fixed in newer versions (which I currently cannot test unfortunately)?
> >>>
> >>>
> >>>
> >>> Any help would be greatly appreciated.
> >>>
> >>>
> >>>
> >>> Andreas
> >>>
> >>> _______________________________________________
> >>> Modules-interest mailing list
> >>> Mod...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/modules-interest
> >>
> >>
> >> _______________________________________________
> >> Modules-interest mailing list
> >> Mod...@li...
> >> https://lists.sourceforge.net/lists/listinfo/modules-interest
> >>
> >
> >
> >
> > _______________________________________________
> > 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/
> --------------------------------------------------------
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
|
