At the moment (both in trunk as well as latest release), modules assumes for the uname command in mfcmd.tcl that domainname is in the state array here.
Then again, in init.tcl in the state array is being initialised with runCommand domainname. This works on most distributions, as Debian, Fedora, etc. package debian-hostname to provide hostname(1), domainname(1) and co. However, ArchLinux does not, and uses GNU Inetutils for this purpose - which only provides hostname(1) and dnsdomainname(1), see the package contents.
As of such, a lot of tests (that make the same assumption) will error and so there will be similar issues around module state and the uname command in modulefiles.
I would suggest this: Since GNU Inetutils and debian-hostname provider hostname(1), it would work with either implementation to replace domainname with hostname -y. This is equivalent for debian-hostname (see this code location) and works for GNU Inetutils, which will call xgetdomainname from Gnulib. Both utilities return the result of getdomainname(2) for hostname -y, but debian-hostname has this domainname(1) alias for it, which inetutils does not.
It is planned to move environment-modules into the official Arch repos soon, and currently this patch is applied to replace the occurrences of domainname with hostname -d. That's not the same, but Arch doesn't support NIS and has no tooling for it, so the DNS domain name seemed more useful to there than effectively hardcoding (none).
Of course, it's also questionable if the information overall is useful, as NIS domains are rare these days when compared to FreeIPA and AD domains. So maybe a more fundamental change would be appropriate.
At the moment (both in trunk as well as latest release), modules assumes for the
unamecommand inmfcmd.tclthatdomainnameis in the state array here.Then again, in
init.tclin the state array is being initialised withrunCommand domainname. This works on most distributions, as Debian, Fedora, etc. packagedebian-hostnameto providehostname(1),domainname(1)and co. However, ArchLinux does not, and uses GNU Inetutils for this purpose - which only provideshostname(1)anddnsdomainname(1), see the package contents.As of such, a lot of tests (that make the same assumption) will error and so there will be similar issues around
module stateand theunamecommand in modulefiles.I would suggest this: Since GNU Inetutils and debian-hostname provider
hostname(1), it would work with either implementation to replacedomainnamewithhostname -y. This is equivalent for debian-hostname (see this code location) and works for GNU Inetutils, which will callxgetdomainnamefrom Gnulib. Both utilities return the result ofgetdomainname(2)forhostname -y, but debian-hostname has thisdomainname(1)alias for it, which inetutils does not.It is planned to move
environment-modulesinto the official Arch repos soon, and currently this patch is applied to replace the occurrences ofdomainnamewithhostname -d. That's not the same, but Arch doesn't support NIS and has no tooling for it, so the DNS domain name seemed more useful to there than effectively hardcoding(none).Of course, it's also questionable if the information overall is useful, as NIS domains are rare these days when compared to FreeIPA and AD domains. So maybe a more fundamental change would be appropriate.