Asdf: Support for sh/dash

[axelson]

Is there an official list of what shells asdf supports? Is there any chance for dash/sh to be supported, or is it only bash and korn shells?

https://github.com/asdf-vm/asdf/blob/e79016add33720fbb039ec4e98c5959624704bbb/asdf.sh#L1-L4

Seems to be a partial list of support, but fish is also supported since there's an asdf.fish file.

Currently when run under sh you get an error like:
/home/my_home/.asdf/asdf.sh: 8: /home/my_home/.asdf/asdf.sh: Bad substitution

My use case is that I help maintain the Elixir Language Server which uses a sh script to launch the server, but since many users use asdf to manage their elixir installations we recently started sourcing asdf inside that script, but this doesn't always work because /bin/sh might be actual sh (or dash) instead of bash.

Of course the effort involved in changing asdf to be sh-compatible may be large which might make it not worth the effort. So my goal with this issue is to definitively find out if sh/dash is meant to be supported, and if not to have an official list of shells (even if it's not exhaustive) that are supported.

[jthegedus]

Is there an official list of what shells asdf supports

There is not, though I would like to add this to the documentation.
At this stage I would say we explicitly support:

• bash
• fish
• zsh

Though it may be fully compatible with others, we aren't running e2e tests for all shells.

Feel free to correct my understanding, but with this shell history:

❓ sh (bourne) -> ✔️ bash (bourne again) -> ✔️ zsh
               -> ❓ ash                  -> ❓ dash (current /bin/sh on debian-based unix)
               -> ❓ ksh
✔️fish
❌powershell   -> ❓ powershell core

the different base of dash from bash makes me think it is not supported at this time.

@asdf-vm/core

• Could we create a definitive list of the current supported shells with GH Action e2e test cases?
• Are there longer-term plans to be compatible with other shells? Powershell Core has also been requested in #576
• Should we rename the *.sh files to *.bash to better communicate which shells each script is meant to support?
• If we desire to support more shells, can we have a discussion about this project's codebase and how we would support this? (currently we switch case depending on the shell)
  
  
  
  • how would plugins work as most are built with bash as the executing shell?
  
  

[Stratus3D]

• Could we create a definitive list of the current supported shells with GH Action e2e test cases?

I don't know if that is feasible or not, but if it is we definitely should. The other day I was reading about the different Bash versions and realized there are significant features that not all versions support. We should know which versions of Bash we support.

• Are there longer-term plans to be compatible with other shells? Powershell Core has also been requested in #576

I guess to me this depends on how much work it is. If it isn't too terrible to support and we can verify everything we need in our builds I'm all for it.

• Should we rename the *.sh files to *.bash to better communicate which shells each script is meant to support?

I was actually thinking about adding back the .sh extension to the files that lack them. Some of our source files now contain magic comments instead of a file extension, and I'd like to avoid magic comments if possible or at least have both the extension and the magic comments. I keep magic comments turned off in Vim because of past security issues.

• If we desire to support more shells, can we have a discussion about this project's codebase and how we would support this? (currently we switch case depending on the shell) how would plugins work as most are built with bash as the executing shell?

Good questions. I don't know. I like to be able to write once and run everywhere as much as possible, and I don't see any issues doing that with the current state of the codebase. Looking at our docs, they only say the custom command* files must be bash. All the other scripts only need to be executable files, so it's possible for them to be anything.

[jthegedus]

So work we can do to get to a better known state:

• Add .sh extensions back to all source files that lack them and remove magic comments.
• Be explicit in documentation about specific shells we support. At this time Bash, Fish, ZSH.
• Determine the specific versions of each shell we are compatible with (certainly more work than the above, but still should be a goal of ours).

@Stratus3D should we open issues to track that we want to make these changes?

@axelson I'm sorry we don't have a better answer than "Not at this time". It looks like we have some areas to improve before we are in a state to start looking at adding this support. Will keep this thread open should you have other comments or ideas to help us progress, thanks.

[axelson]

@axelson I'm sorry we don't have a better answer than "Not at this time". It looks like we have some areas to improve before we are in a state to start looking at adding this support. Will keep this thread open should you have other comments or ideas to help us progress, thanks.

Thanks for looking into it! Just understanding the state of things is good enough for me right now. I really appreciate all the hard work put into asdf, it is an invaluable tool for me :)

[Stratus3D]

@jthegedus so for the file extension, should we go with .sh or .bash? We would have to change a few more files if we go with the .bash extension, but the added clarity may be worth it.

[jthegedus]

It depends on what the intent is.

For each file, are we saying .bash because the script requires Bash features to execute? .sh is nondescript given the confusion with bourne vs dash as the OP pointed out, so I'm not sure that would be useful either. I guess if we went with .sh we would require users to know which shell their system uses with /bin/sh, which isn't unreasonable.

In the case raised with the OP, should our goal here be to remove all bash specific features to serve a larger number of shells?

I think these are our options:

1. Support more shells (ash/dash/other) use .sh, remove Bash specific features from the codebase and require users to know their /bin/sh shell.
2. Require Bash shell on the system and rename all files to .bash
3. Rename files that require Bash to .bash and the rest to .sh. Then re-assess the other two options.

[Stratus3D]

So, as far as I know, we do require Bash to be present. The asdf executable in bin/asdf has a shebang line that is specifying bash - #!/usr/bin/env bash. So right now bash itself is a hard requirement, regardless of what shell the user actually uses at the terminal. I think it's good we don't use bin/sh as it is often aliased to other shells as @axelson mentioned.

I'm fairly certain the asdf code would not run properly under Zshell or Dash, but I haven't tried to run it.

I think it's hard enough to write shell programs that work consistently across operating systems in Bash. Making the code work across multiple shells sounds like it would make the code extremely difficult to get right, but I may be wrong.

Since all of the files sourced by bin/asdf are executed by Bash, I think it would be best to give them all the extension .bash for now to make it clear they've been written with the assumption that they will be run by Bash.

For other shells, supporting them could be as simple as adding another asdf.* to the repository. We already have asdf.sh (Bash) and asdf.fish (Fish). It all depends on what is meant by "support". While users may want to use another shell like Zsh, Fish, or Dash (and have nice autocomplete available), having Bash installed shouldn't be too much of a hurdle for most users. OSX ships with Bash and Zsh, and I'm not aware of any Linux distros that lack Bash.

[Stratus3D]

I think you made the right choice to use #!/usr/bin/env bash in ElixirLS @axelson https://github.com/elixir-lsp/elixir-ls/pull/118

[axelson]

I think you made the right choice to use #!/usr/bin/env bash in ElixirLS @axelson elixir-lsp/elixir-ls#118

Thanks!

[jthegedus]

@Stratus3D I agree 100% with your assessment.