fix: asdf info show BASH_VERSION & all asdf envs

[hyperupcall]

These changes make two fixes with the info subcommand:

• Use $BASH_VERSION for info about the current version of Bash because:

  • $SHELL --version is too verbose
  • $SHELL breaks when Bash is installed in a location that contains spaces (ShellCheck misses this because it seems it hard-codes SHELL as an exception)
  • $SHELL breaks when a login shell other than Bash is used

• Change printing of environment variables so that

  • All variables that asdf uses are printed, even if they are not set
  • Remove exec/subshell

Sample Output

$ asdf info
OS:
Linux nullptr 5.15.0-67-generic #74-Ubuntu SMP Wed Feb 22 14:14:39 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

SHELL:
Bash 5.1.16(1)-release

ASDF VERSION:
v0.11.3-f5f391c

ASDF ENVIRONMENT VARIABLES:
ASDF_DEFAULT_TOOL_VERSIONS_FILENAME=(not set)
ASDF_DATA_DIR=/home/edwin/.asdf
ASDF_DIR=/storage/ur/storage_home/Docs/Programming/Repositories/git/asdf
ASDF_CONFIG_FILE=/home/edwin/.config/asdf/asdfrc

ASDF INSTALLED PLUGINS:
elixir                       master 1693b35
nodejs                       master c9e5df4
python                       master 8505457

[jthegedus]

I use a non-Bash shell as a login shell and the existing behaviour works as expected. I understand we might want to know the BASH_VERSION as well, but knowing the login Shell is just as useful a debugging mechanism.

Regarding

$SHELL --version is too verbose

I would argue when people provide this information we want the more verbose output. Bash itself being more verbose than other shells is a Bash-ism.

Perhaps we can better handle failures with $SHELL and then also add $BASH_VERSION separately?

[hyperupcall]

I use a non-Bash shell as a login shell and the existing behaviour works as expected.

Ohh, oops what I said is only true for interactive logins I believe.

I would argue when people provide this information we want the more verbose output. Bash itself being more verbose than other shells is a Bash-ism.

What part of the information is useful? All lines except the first are license boilerplate and the stuff in the target triple is covered by uname -a

Perhaps we can better handle failures with $SHELL and then also add $BASH_VERSION separately?

If you still don't prefer $BASH_VERSION, then I'll just quote "$SHELL" and we can leave it at that. I also opened an issue in Shellcheck koalaman/shellcheck#2724 so hopefully this kind of stuff gets caught in the future

[jthegedus]

Ohh, oops what I said is only true for interactive logins I believe.

Right, well asdf info was created for ease of sharing data for Issues/PRs in the repo. It is expected to be used in an interactive shell. Uses for scripting or non-interactive environments will eventually fall under a particular global flag (tentatively --porcelain) and so is not a goal of the current implementation.

What part of the information is useful? All lines except the first are license boilerplate and the stuff in the target triple is covered by uname -a

In my Nushell setup, $($SHELL --version) gives me just my Nushell version number, nothing else. $BASH_VERSION while also useful information, won't share my current Shell information in asdf info. That information about my Nushell version is lost. This is useful information for us to debug with during Issues which asdf info was created for ease of sharing with.

As I said, $BASH_VERSION is useful as well, so seeing it as an addition to $($SHELL --version) is welcome.

Removal of $($SHELL --version) results in a loss of information.

So adding $BASH_VERSION is welcome 👍

Better error handling of $($SHELL --version) is also welcome, but it is preferred to keep it. The --version verbosity is useful with non-Bash shells, like Nushell. It might be noisy with Bash, but that's an acceptable outcome. If you want to special case Bash, then sure, but non-Bash should use --version

I hope that clarifies things.

[hyperupcall]

I see - using $SHELL is important and the fact that it potentially invokes a different shell didn't register with me. I'll leave it in like you say and add $BASH_VERSION since we don't want to loose information

[jthegedus]

Although not actually set, the default is .tool-versions, so printing that it isn't set might be confusing. I guess this could be raised as a separate issue to actually set ASDF_DEFAULT_TOOL_VERSIONS_FILENAME to the default .tool-versions.

[hyperupcall]

You bring up a good point - these variables are labeled under ENVIRONMENT VARIABLES:, yet they may not be env vars set by the user (only internally by asdf). And, I think like you mention, ASDF_DEFAULT_TOOL_VERSIONS_FILENAME isn't set internally by asdf like the others, causing more confusion.

How does it sound to print INTERNAL VARIABLES: , to make it clear that these variables aren't the same values as the environment variables the user passed in? In a separate issue I can set ASDF_DEFAULT_TOOL_VERSIONS_FILENAME like we do with the other variables

[jthegedus]

That sounds like a good path forward, let's do that, thanks.

[hyperupcall]

I made those changes and also removed the (not set) since it didn't make sense or was useful information in the context of "internal variables". This doesn't change the fact that some internal variables are either unset, or set and empty, and need a "default value". This will be fixed in the follow-up ASDF_DEFAULT_TOOL_VERSIONS_FILENAME PR

[jthegedus]

Thanks