1

As a follow-up question to the answer proposed in Completely restart Bash -- I'm wondering if this works from within a shell script?

This is for a setup script for new machines. What I'm doing is replacing a few standard commands with my own variants (e.g. a 'service' variant that provides proper feedback on CentOS 7 instead of a redirect message with no further output) and I'm doing that from a setup.sh script in bash. These replacements are copied to /usr/local/sbin/ but won't take effect until the shell is restarted. I'm planning to do that with: exec bash -l as suggested, but does this work from within a shell script?

Mark Straver
  • 11
  • 1
  • 1
    It won't replace the parent shell, if that's what you're asking. – muru Jun 27 '19 at 08:21
  • 2
    `hash -r` will cause the current shell to forget about any cached paths to commands and try to find them again in `$PATH`. If you want to let an unrelated shell do that, you will need its collaboration (eg. have it do a `trap 'hash -r' USR1` and kill it with `kill -USR1`). –  Jun 27 '19 at 08:38
  • Maybe I wasn't clear enough. the shell script copies several command files into `/usr/local/sbin` but the existing shell won't pick that up unless the connection is cycled/the shell is restarted. interactively, `exec bash -l` replaces the current bash with a new one, but can that be done as part of a script without interrupting the execution of that script? – Mark Straver Jun 27 '19 at 10:03
  • 1
    The shell *will* pick that up if you do a `hash -r`. No need for `exec bash -l` (I don't see why you should do that, ever, you can also simply `. ~/profile` if you have updated it). And you cannot force a shell to do an `exec ...` more than you can force it to do a `hash -r` (that are ways, like attaching to it with a debugger, or faking it input with `ioctl(TIOCSTI)`, but they're very slippery and frankly, not worth it). Notice that I'm not telling anything about breaking users' expectations -- most users will NOT appreciate having their shell restarted and all its state wiped off. –  Jun 27 '19 at 13:47
  • @Mark `exec bash -l` replaces the current bash with a new one, sure, but the current bash is the one started to executed the script, *not the one that you executed the script from* – muru Jun 28 '19 at 12:03

1 Answers1

-1

Answering my own question thanks to @mosvy: The solution is to use hash -r instead of restarting the shell to pick up changed system commands.

Mark Straver
  • 11
  • 1