3 ms·

The state machines for what calls what when is so insane and stupid. Just have one file and set env vars for “is a TTY” “is SSH” etc. It’s crazy that they kept

The state machines for what calls what when is so insane and stupid. Just have one file and set env vars for “is a TTY” “is SSH” etc. It’s crazy that they kept making the calling conventions so complicated instead of thinking about the existence of “if statements”.

acdha 7y ago
After using bash since ~1993 I switched cold-turkey to fish around a year ago. In retrospect, one of the most enjoyable aspects has been how little I need to customize since it does the right thing out of the box and I can just free up all of the brain capacity I used to spend on the intricacies of the best way to configure bash.
- kstrauser 7y ago
  That was exactly my experience. The defaults are so ergonomic, and the configuration scripting so utterly sane, that I have no desire to go back to bash. For example, do you want to make an autoloaded function named "foo" that comes into existence the first time you call it? Write a file named ~/.config/fish/functions/foo.fish, and inside it define a function named "foo". There - done. Follow this pattern to make a function named "fish_greeting", and it will run every time you launch a new fish shell. Want to make a custom prompt? Write a function named "fish_prompt". Decide you want one of those fancy prompts where the timestamp is displayed on the right side of your terminal window? Make a "fish_right_prompt.fish" file and put in it: function fish_right_prompt --description 'Write out the right prompt' set_color 666666 date +'%Y-%m-%d %H:%M:%S' set_color normal end After years of customizing bash (and later zsh), this is a breath of fresh air.
- earthboundkid 7y ago
  Catalina finally pushed me over the hump of switching to Fish last month. It’s great! I was dreading porting my Bash config, but it turned out almost nothing needed to be ported because Fish does so much for you.
  - acdha 7y ago
    I’ve really enjoyed that. About the only thing I have to finish doing is breaking years of habit around !$ and using $()
JdeBP 7y ago
Actually, they are fairly simple. A case in point is the basic Korn shell behaviour. * There are two scripts run by a login shell, $HOME/.profile and /etc/profile . * These scripts set up environment variables and other things (e.g. umask) to be inherited by the whole login session. * They, specifically, optionally set an ENV variable whose value names a third script that is run by every interactive shell, including the interactive login shell. That's exactly three scripts: one for the system administrator and another one for the user to set up login-session-wide stuff, and one for the user to set up this-interactive-shell stuff (such as the shell variables for fancy prompts, completion settings, command-line editing stuff, useful interactive shell aliases, and whatnot). They are always in the same order. And they are simply based upon two things: whether the shell is a login shell, and whether the shell is an interactive shell. The C shell mechanism is similarly simple, on its own. The complexity mainly comes from the fact that the Bourne Again shell and the Z shell, amongst others, have multiple mechanisms mixed together and extensions. They look for scripts that are specifically in their own shell languages rather than potentially shared with other shells; .zprofile and .bash_profile instead/ahead of .profile , for example. They have extra scripts that mirror the C shell way of doing things; .zlogin, .zlogout, .bash_login, .bash_logout, .bashrc, and .zshrc, for example. They have idiosyncratic and non-strictly-standard ways of deciding what constitutes an interactive shell. They have mechanisms for disabling the extensions, and ways to come up in alternative not-strictly-conformant sh-compatible modes.
- earthboundkid 7y ago
  https://shreevatsa.files.wordpress.com/2008/03/bashstartupfiles1.png https://shreevatsa.files.wordpress.com/2008/03/bashstartupfi... is not fairly simple.

acdha 7y ago

After using bash since ~1993 I switched cold-turkey to fish around a year ago. In retrospect, one of the most enjoyable aspects has been how little I need to customize since it does the right thing out of the box and I can just free up all of the brain capacity I used to spend on the intricacies of the best way to configure bash.

kstrauser 7y ago
That was exactly my experience. The defaults are so ergonomic, and the configuration scripting so utterly sane, that I have no desire to go back to bash. For example, do you want to make an autoloaded function named "foo" that comes into existence the first time you call it? Write a file named ~/.config/fish/functions/foo.fish, and inside it define a function named "foo". There - done. Follow this pattern to make a function named "fish_greeting", and it will run every time you launch a new fish shell. Want to make a custom prompt? Write a function named "fish_prompt". Decide you want one of those fancy prompts where the timestamp is displayed on the right side of your terminal window? Make a "fish_right_prompt.fish" file and put in it: function fish_right_prompt --description 'Write out the right prompt' set_color 666666 date +'%Y-%m-%d %H:%M:%S' set_color normal end After years of customizing bash (and later zsh), this is a breath of fresh air.
earthboundkid 7y ago
Catalina finally pushed me over the hump of switching to Fish last month. It’s great! I was dreading porting my Bash config, but it turned out almost nothing needed to be ported because Fish does so much for you.
- acdha 7y ago
  I’ve really enjoyed that. About the only thing I have to finish doing is breaking years of habit around !$ and using $()

JdeBP 7y ago

Actually, they are fairly simple. A case in point is the basic Korn shell behaviour. * There are two scripts run by a login shell, $HOME/.profile and /etc/profile . * These scripts set up environment variables and other things (e.g. umask) to be inherited by the whole login session. * They, specifically, optionally set an ENV variable whose value names a third script that is run by every interactive shell, including the interactive login shell. That's exactly three scripts: one for the system administrator and another one for the user to set up login-session-wide stuff, and one for the user to set up this-interactive-shell stuff (such as the shell variables for fancy prompts, completion settings, command-line editing stuff, useful interactive shell aliases, and whatnot). They are always in the same order. And they are simply based upon two things: whether the shell is a login shell, and whether the shell is an interactive shell. The C shell mechanism is similarly simple, on its own. The complexity mainly comes from the fact that the Bourne Again shell and the Z shell, amongst others, have multiple mechanisms mixed together and extensions. They look for scripts that are specifically in their own shell languages rather than potentially shared with other shells; .zprofile and .bash_profile instead/ahead of .profile , for example. They have extra scripts that mirror the C shell way of doing things; .zlogin, .zlogout, .bash_login, .bash_logout, .bashrc, and .zshrc, for example. They have idiosyncratic and non-strictly-standard ways of deciding what constitutes an interactive shell. They have mechanisms for disabling the extensions, and ways to come up in alternative not-strictly-conformant sh-compatible modes.

earthboundkid 7y ago
https://shreevatsa.files.wordpress.com/2008/03/bashstartupfiles1.png https://shreevatsa.files.wordpress.com/2008/03/bashstartupfi... is not fairly simple.