7 ms·

Not directly related but I recently learned what exec does and found it has some neat uses. When I see tutorials that tell me to run `. ~/.bashrc` after adding

Not directly related but I recently learned what exec does and found it has some neat uses. When I see tutorials that tell me to run `. ~/.bashrc` after adding something to my bashrc, I run `exec bash` instead. Less finger gymnastics, and cleaner. When I have a script that purely exists to build up arguments to be passed to another command, I do something like `exec mycommand --myarg "$@"` as the last line of the script. No unnecessary bash process lingering around.

eatonphil 5y ago
If saving keystrokes is your goal, couldn't you just run bash without exec to get the same thing with even less typing? The only difference is you'll have to exit bash twice when you're done.
- miduil 5y ago
  Because you'll end up exiting bash n-times once you're done which gets annoying and confusing quickly
- mikepurvis 5y ago
  Non-FHS systems like Nix require a lot of per-executable environment setup. This basically means that every executable gets wrapped in some kind of shell script to perform that setup, and some things can end up wrapped multiple times. It's critical that those wrappers be able to `exec` from one to the next or your system would quickly be awash in bash processes just idling waiting for other things to exit.
  - labawi 5y ago
    True, but doesn't seem relevant for updating an interactive shell.
amarshall 5y ago
Sourcing bashrc and exec-ing are not quite equivalent, but most of the time it doesn't matter. E.g. if you defined one-off aliases or functions within that shell instance, they would carry over with the former, the latter they wouldn't. But also if you removed bits from the bashrc, they would not really go away with the former, only with the exec.
- nerdponx 5y ago
  Most notably you will likely end up with duplicated elements in PATH unless you take specific steps to prevent double-adding. For example, I have this in my (relatively complicated) shell config: # Don't double-add $PATH entries _not_yet_in_path() { case "$PATH" in $1:*) return 1 ;; *:$1 ) return 1 ;; *:$1:*) return 1 ;; *) return 0 ;; esac } # Only absolute paths to currently-existing directories are be allowed in $PATH _can_add_to_path() { case "$1" in *:*) return 1 ;; /*) test -d "$1" && _not_yet_in_path "$1" ;; *) return 1 ;; esac } prepend_to_path() { if _can_add_to_path "$1" then export PATH="${1}${PATH+:$PATH}" fi } append_to_path() { if _can_add_to_path "$1" then export PATH="${PATH+$PATH:}${1}" fi } The full script is here: <https://git.sr.ht/~wintershadows/dotfiles/tree/master/item/.config/envrc.sh https://git.sr.ht/~wintershadows/dotfiles/tree/master/item/....>. Feedback is always welcome on how I can make this better! The Zsh version of this is a lot nicer.
  - dylan604 5y ago
    That's a lot of work for avoiding double PATHing. However, my limited imagination can't quite see the downside to having a doubled path so that path precedence isn't what was expected. Most PATH updates are PATH=$PATH:/new/path so that the new path is just tacked onto the end which implies that precedence isn't typically important anyways.
    - nerdponx 5y ago
      The problem with "double PATHing" is that some things get doubled and some things don't. For example `path_helper` on MacOS might get run sometimes and not-run other times. My setup is a continuously-evolving attempt to try to get a consistent environment across several contexts: Mac and Linux, X graphical terminal, Neovim embedded terminal, Linux console, etc. Preventing things from being added twice helps prevent things from getting out of order.
      - 5y ago
caymanjim 5y ago
> When I see tutorials that tell me to run `. ~/.bashrc` after adding something to my bashrc, I run `exec bash` instead. This is a bad idea. If there are any errors in your .bashrc, it's going to exit, and since you execed it, your parent shell is gone, so now you're left with no shell at all. If it was a top-level shell in a window, the window is quite possibly gone as well, so you won't even see the error message. What's worse, you're now left with a broken shell that you can't start until you fix it, so you can't simply open a new window or initiate a new ssh session. There are solutions to get a new shell without reading the defective .bashrc, but most people have no idea how to do that and would be locked out.
kccqzy 5y ago
Just `exec bash` doesn't get you a proper login shell so plenty of things will break. It's likely that you don't care about login shells or not, but some will. But at least do `exec bash -l` instead.

eatonphil 5y ago

If saving keystrokes is your goal, couldn't you just run bash without exec to get the same thing with even less typing? The only difference is you'll have to exit bash twice when you're done.

miduil 5y ago
Because you'll end up exiting bash n-times once you're done which gets annoying and confusing quickly
mikepurvis 5y ago
Non-FHS systems like Nix require a lot of per-executable environment setup. This basically means that every executable gets wrapped in some kind of shell script to perform that setup, and some things can end up wrapped multiple times. It's critical that those wrappers be able to `exec` from one to the next or your system would quickly be awash in bash processes just idling waiting for other things to exit.
- labawi 5y ago
  True, but doesn't seem relevant for updating an interactive shell.

amarshall 5y ago

Sourcing bashrc and exec-ing are not quite equivalent, but most of the time it doesn't matter. E.g. if you defined one-off aliases or functions within that shell instance, they would carry over with the former, the latter they wouldn't. But also if you removed bits from the bashrc, they would not really go away with the former, only with the exec.

nerdponx 5y ago
Most notably you will likely end up with duplicated elements in PATH unless you take specific steps to prevent double-adding. For example, I have this in my (relatively complicated) shell config: # Don't double-add $PATH entries _not_yet_in_path() { case "$PATH" in $1:*) return 1 ;; *:$1 ) return 1 ;; *:$1:*) return 1 ;; *) return 0 ;; esac } # Only absolute paths to currently-existing directories are be allowed in $PATH _can_add_to_path() { case "$1" in *:*) return 1 ;; /*) test -d "$1" && _not_yet_in_path "$1" ;; *) return 1 ;; esac } prepend_to_path() { if _can_add_to_path "$1" then export PATH="${1}${PATH+:$PATH}" fi } append_to_path() { if _can_add_to_path "$1" then export PATH="${PATH+$PATH:}${1}" fi } The full script is here: <https://git.sr.ht/~wintershadows/dotfiles/tree/master/item/.config/envrc.sh https://git.sr.ht/~wintershadows/dotfiles/tree/master/item/....>. Feedback is always welcome on how I can make this better! The Zsh version of this is a lot nicer.
- dylan604 5y ago
  That's a lot of work for avoiding double PATHing. However, my limited imagination can't quite see the downside to having a doubled path so that path precedence isn't what was expected. Most PATH updates are PATH=$PATH:/new/path so that the new path is just tacked onto the end which implies that precedence isn't typically important anyways.
  - nerdponx 5y ago
    The problem with "double PATHing" is that some things get doubled and some things don't. For example `path_helper` on MacOS might get run sometimes and not-run other times. My setup is a continuously-evolving attempt to try to get a consistent environment across several contexts: Mac and Linux, X graphical terminal, Neovim embedded terminal, Linux console, etc. Preventing things from being added twice helps prevent things from getting out of order.
    - 5y ago

caymanjim 5y ago

> When I see tutorials that tell me to run `. ~/.bashrc` after adding something to my bashrc, I run `exec bash` instead. This is a bad idea. If there are any errors in your .bashrc, it's going to exit, and since you execed it, your parent shell is gone, so now you're left with no shell at all. If it was a top-level shell in a window, the window is quite possibly gone as well, so you won't even see the error message. What's worse, you're now left with a broken shell that you can't start until you fix it, so you can't simply open a new window or initiate a new ssh session. There are solutions to get a new shell without reading the defective .bashrc, but most people have no idea how to do that and would be locked out.

kccqzy 5y ago

Just `exec bash` doesn't get you a proper login shell so plenty of things will break. It's likely that you don't care about login shells or not, but some will. But at least do `exec bash -l` instead.