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
    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