You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
This project's hostname value for Windows has changed from being formatted to all uppercase, to all lowercase, back to all uppercase over the last couple of years, but I think the behavior is still incorrect.
In 2022, it was all uppercase, which was marked as an issue: (#39)
In 2023, it had been coerced into all lowercase, which was again marked as an issue: (#82)
After that, whoami was changed to use the NetBIOS formatted hostname, so back to being all uppercase, which I believe is still incorrect.
Consider this example:
On MacOS:
system: hostname: soDIum
whoami: hostname: soDIum devicename: My MacBook Air
On Windows:
system: hostname: soDIum
whoami: hostname: SODIUM devicename: soDIum
To Reproduce
Steps to reproduce the behavior:
Use the latest release of whoami on Windows.
Check the output of hostname and devicename functions.
Expected behavior
I think that whoami's hostname result should try to identically match what the OS system CLI tool hostname reports.. which itself preserves casing.
Yes DNS itself is case insensitive, but people do often use mixed case styling in their hostnames, so reflecting that in whoami's output accurately does makes sense.
Currently whoami's behavior matches this expectation for Linux and MacOS, but not Windows.
I believe a good fix would be to reverse the use of ComputerNameFormat::NetBIOS and ComputerNameFormat::DnsHostname in the hostname and devicename functions in whoami/src/os/windows.rs
NetBIOS (and also the COMPUTERNAME env var) will always be uppercase, and seems to me to be more of a 'fancy' naming, or at least aligns better with being a 'device' name than a 'host' name.
Also, not sure the order of precedence for ComputerNameFormat::PhysicalNetBIOS and ComputerNameFormat::PhysicalDnsHostname over the respective non-physical versions, but one level could be incorporated as a fallback over the other too, if desired.
Thank you!
The text was updated successfully, but these errors were encountered:
Describe the bug
This project's hostname value for Windows has changed from being formatted to all uppercase, to all lowercase, back to all uppercase over the last couple of years, but I think the behavior is still incorrect.
In 2022, it was all uppercase, which was marked as an issue: (#39)
In 2023, it had been coerced into all lowercase, which was again marked as an issue: (#82)
After that, whoami was changed to use the NetBIOS formatted hostname, so back to being all uppercase, which I believe is still incorrect.
Consider this example:
On MacOS:
system:
hostname: soDIum
whoami:
hostname: soDIum
devicename: My MacBook Air
On Windows:
system:
hostname: soDIum
whoami:
hostname: SODIUM
devicename: soDIum
To Reproduce
Steps to reproduce the behavior:
Use the latest release of whoami on Windows.
Check the output of hostname and devicename functions.
Expected behavior
I think that whoami's hostname result should try to identically match what the OS system CLI tool
hostname
reports.. which itself preserves casing.Yes DNS itself is case insensitive, but people do often use mixed case styling in their hostnames, so reflecting that in whoami's output accurately does makes sense.
Currently whoami's behavior matches this expectation for Linux and MacOS, but not Windows.
I believe a good fix would be to reverse the use of ComputerNameFormat::NetBIOS and ComputerNameFormat::DnsHostname in the hostname and devicename functions in whoami/src/os/windows.rs
NetBIOS (and also the COMPUTERNAME env var) will always be uppercase, and seems to me to be more of a 'fancy' naming, or at least aligns better with being a 'device' name than a 'host' name.
Also, not sure the order of precedence for ComputerNameFormat::PhysicalNetBIOS and ComputerNameFormat::PhysicalDnsHostname over the respective non-physical versions, but one level could be incorporated as a fallback over the other too, if desired.
Thank you!
The text was updated successfully, but these errors were encountered: