3 ms·

From the fush documentation: Special variables Some bash variables and their closest fish equivalent: $*, $@, $1 and so on: $argv $?: $status

From the fush documentation: Special variables Some bash variables and their closest fish equivalent: $*, $@, $1 and so on: $argv $?: $status $$: $fish_pid $#: No variable, instead use count $argv $!: $last_pid $0: status filename $-: Mostly status is-interactive and status is-login Replacing «$$» with «$fish_pid»? A contentious choice at the very least – does it also apply to non-interactive fish scripts? «…use count $argv» instead of «$#» – why? Both, $$ and $#, are non-bashism's and go way, way back into the UNIX prehistoric times – hardly bash-ism's. Fish does not appear to have basic conditional variable expansions, matching affix removals and pattern substitutions, either; i.e. ${_var:-substitute}, ${parameter<# / ##>word}, ${parameter<% / %%>word} and ${parameter/pattern/string}. Or, at least their nearest equivalent are not prominently featured in the documentation.

Beltalowda 5y ago
How often do you type these things in an interactive shell though? Also things like $status and $argv are reminiscent of csh, which also goes back a long way!
- inkyoto 5y ago
  With a varying frequency but I do use them in interactive sessions: $ grep -c '\$\?' ~/.history 137 $ grep -c '\$\$' ~/.history 30 $ grep -c '\$!' ~/.history 6 $ grep -c '\$#' ~/.history 13 Less so when it comes to affix removals… I use them liberally in scripts as well as in data transformation pipelines or more complex one-liners, though. I also semi-frequently quit the shell with «kill -9 $$» when I do not want to pollute the shell history with garbage, which is not refelcted in the count above for obvious reasons. It is quick and efficient. > Also things like $status and $argv are reminiscent of csh, which also goes back a long way! Ah, I thought somebody would mention csh as the prior art! Frankly, the C shell syntax have never really clicked with me precisely because of the more verbose syntax, and, as soon as other shells have borrowed history, job control, aliases and a few other features from (t)csh, I was out of the house!
  - Beltalowda 5y ago
    Ah right; I never do that kind of stuff. I wonder if you can set "$$=$pid" in some hook in fish (I don't use fish, or even like it for that matter, albeit for different reasons). Longer names like $status and $pid are actually nicer in scripts IMHO, I typically use those in zsh (which often supports for csh-ish long names and Bourne short names) scripts as it's just a bit clearer. Same with short (-q) vs. long (--quiet) flags: short is great for interactive CLI, long often nicer in scripts. especially with lesser used flags.
    - inkyoto 5y ago
      Yes, zsh – which has been my daily driver for more than two decades – offers the best of both worlds, long and short names for most of the useful variables, but those do not affect the [expected] core shell functionality. I suppose, I should have made my point clearer earlier on. A UNIX shell (along with the terminal) is such a fundamental tool that a substantial departure or a paradigm shift from long standing foundational conventions or from the familiar syntax had better bring at least a tenfold increase in productivity for me – to substantiate the said departure. Then I will happily change my workflow and retrain my muscle memory to adapt. scsh is the only other shell that came close to that at some point in space and time, however, it seems to have perished into the oblivion. A new shell with reasonable and more new user friendly defaults at the expense of missing core shell features does not reach the tipping point for me.

Beltalowda 5y ago

How often do you type these things in an interactive shell though? Also things like $status and $argv are reminiscent of csh, which also goes back a long way!

inkyoto 5y ago
With a varying frequency but I do use them in interactive sessions: $ grep -c '\$\?' ~/.history 137 $ grep -c '\$\$' ~/.history 30 $ grep -c '\$!' ~/.history 6 $ grep -c '\$#' ~/.history 13 Less so when it comes to affix removals… I use them liberally in scripts as well as in data transformation pipelines or more complex one-liners, though. I also semi-frequently quit the shell with «kill -9 $$» when I do not want to pollute the shell history with garbage, which is not refelcted in the count above for obvious reasons. It is quick and efficient. > Also things like $status and $argv are reminiscent of csh, which also goes back a long way! Ah, I thought somebody would mention csh as the prior art! Frankly, the C shell syntax have never really clicked with me precisely because of the more verbose syntax, and, as soon as other shells have borrowed history, job control, aliases and a few other features from (t)csh, I was out of the house!
- Beltalowda 5y ago
  Ah right; I never do that kind of stuff. I wonder if you can set "$$=$pid" in some hook in fish (I don't use fish, or even like it for that matter, albeit for different reasons). Longer names like $status and $pid are actually nicer in scripts IMHO, I typically use those in zsh (which often supports for csh-ish long names and Bourne short names) scripts as it's just a bit clearer. Same with short (-q) vs. long (--quiet) flags: short is great for interactive CLI, long often nicer in scripts. especially with lesser used flags.
  - inkyoto 5y ago
    Yes, zsh – which has been my daily driver for more than two decades – offers the best of both worlds, long and short names for most of the useful variables, but those do not affect the [expected] core shell functionality. I suppose, I should have made my point clearer earlier on. A UNIX shell (along with the terminal) is such a fundamental tool that a substantial departure or a paradigm shift from long standing foundational conventions or from the familiar syntax had better bring at least a tenfold increase in productivity for me – to substantiate the said departure. Then I will happily change my workflow and retrain my muscle memory to adapt. scsh is the only other shell that came close to that at some point in space and time, however, it seems to have perished into the oblivion. A new shell with reasonable and more new user friendly defaults at the expense of missing core shell features does not reach the tipping point for me.