5 ms·

For me, the hard part is remembering if .bashrc is supposed to source .bash_profile or vice versa.

by donarb 6y ago

goblin89 6y ago
My rule of thumb: shell-independent commands go to .profile, those ran at boot time go to .bash_profile (or shell-appropriate) which then sources .profile, those ran each time you open a new shell go to .bashrc (or shell-appropriate).
- AareyBaba 6y ago
  OSX is an exception. OSX runs a login shell for each new terminal window and executes .bash_profile. # http://www.joshstaiger.org/archives/2005/07/bash_profile_vs.html http://www.joshstaiger.org/archives/2005/07/bash_profile_vs....
  - boring_twenties 6y ago
    You can do that in most (all?) Unix terminal emulators. It's the -ls option to xterm and rxvt, or a checkbox in {gnome,mate}-terminal.
- rurban 6y ago
  Nope. Shell specifics go into the name or extension. like .bash_profile over .profile. or /etc/.../bla{.csh,.bash,.sh} .profile is only for login sessions, .shrc is sourced on every shell fork, about 1000x more than .profile.
earthboundkid 6y ago
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 6y 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 6y 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 6y 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 6y ago
      I’ve really enjoyed that. About the only thing I have to finish doing is breaking years of habit around !$ and using $()
- JdeBP 6y 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.
marcosdumay 6y ago
I just symlink one into the other.
westurner 6y ago
info bash -n "Bash Startup Files" https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html https://www.gnu.org/software/bash/manual/html_node/Bash-Star...
throwaway2048 6y ago
I just symlink the two, the distinction is mostly useless and annoying, because random things will invoke login shells (or not) and even if behavior was consistent, its really not that useful to begin with.

For me, the hard part is remembering if .bashrc is supposed to source .bash_profile or vice versa.

by donarb 6y ago

For me, the hard part is remembering if .bashrc is supposed to source .bash_profile or vice versa.

My rule of thumb: shell-independent commands go to .profile, those ran at boot time go to .bash_profile (or shell-appropriate) which then sources .profile, those ran each time you open a new shell go to .bashrc (or shell-appropriate).

AareyBaba 6y ago
OSX is an exception. OSX runs a login shell for each new terminal window and executes .bash_profile. # http://www.joshstaiger.org/archives/2005/07/bash_profile_vs.html http://www.joshstaiger.org/archives/2005/07/bash_profile_vs....
- boring_twenties 6y ago
  You can do that in most (all?) Unix terminal emulators. It's the -ls option to xterm and rxvt, or a checkbox in {gnome,mate}-terminal.
rurban 6y ago
Nope. Shell specifics go into the name or extension. like .bash_profile over .profile. or /etc/.../bla{.csh,.bash,.sh} .profile is only for login sessions, .shrc is sourced on every shell fork, about 1000x more than .profile.

earthboundkid 6y ago

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 6y 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 6y 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 6y 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 6y ago
    I’ve really enjoyed that. About the only thing I have to finish doing is breaking years of habit around !$ and using $()
JdeBP 6y 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.

marcosdumay 6y ago

I just symlink one into the other.

westurner 6y ago

info bash -n "Bash Startup Files" https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html https://www.gnu.org/software/bash/manual/html_node/Bash-Star...

throwaway2048 6y ago

I just symlink the two, the distinction is mostly useless and annoying, because random things will invoke login shells (or not) and even if behavior was consistent, its really not that useful to begin with.