Should "${VARIABLE}" and "$(COMMAND)" be considered for inclusion as part of the fish language to be more friendly to bash/zsh users?
Should "${VARIABLE}" and "$(COMMAND)" be considered for inclusion as part of the fish language to be more friendly to bash/zsh users?
I think advantages are
- compatibility (muscle memory)
- ${VARIABLE} is way less ugly than {$VARIABLE}
Disadvantages might be
- two different ways to do the same thing[^*]
- we might want to make ${} mean something else. But that's unlikely.
[^*]: historically, fish has been more orthogonal and simple than other shells. In particular, the fact that these are equivalent:
echo {$HOME}
echo $HOME
is a logical consequence of a simple, nonmagic implementation of brace expansion.
However I think this was changed at some point, so now
echo HEAD@{1}
needs no quoting, and echoes stuff verbatim.
So fish has already special-cases braces without comma. Given that "{...}" without comma almost always expands literally now, the tables have turned and "{$HOME}" is the oddball, which is additional evidence that we should support "${HOME}".
It's useful as a pretty way to clearly delineate variable names in expansions.
In future, we can also implement "${HOME#/}" and other convenient expansions. At least from the POSIX subset.
Overall, I think that adding stuff that improves the interactive experience for people who already know bash/zsh is great.
Even for people who've never really used either interactively, they likely still use bash for scripting (because fish mainly shines at interactive use), and that builds muscle memory.
That's why I think we should also support if/then/fi, but that discussion isn't finished, so details are not worked out yet.
Supporting $(...) would be a huge improvement. Every time I see (or add!) $(...) in documentation, I wince. It's painful to remove the $ before I run it in my favorite friendly shell.
$(...) is a continuation of gradual targeted bash compatibilities like A=1 B=2 some-command, && and ||. Fish did not support them, but it does now. I found that it lowered copy-paste pain for me.
Supporting
$(...)would be a huge improvement. Every time I see (or add!)$(...)in documentation, I wince. It's painful to remove the$before I run it in my favorite friendly shell.