Shell – Is it possible to exec some commands in a subshell without immediately exiting afterwards

execfishshell

I use the fish shell and would like to be able to "source" some shell scripts written with sh-compatible syntax, which fish cannot read. For example lots of software expects you to source some shell scripts to export helpful environment variables:

# customvars.sh
FOOBAR=qwerty
export FOOBAR

If I don't care about preserving local variable and function definitions, one workaround is to use exec to replace the current process with /bin/sh and then go back to fish

# We start out on fish
exec /bin/sh

# Running a POSIX shell now
. customvars.sh
exec /usr/bin/fish

# Back on fish
echo $FOOBAR

Is there a way to boil this pattern down to an one-liner that I can save in a function somewhere? If I try doing

exec /bin/sh -c '. vars.sh; /usr/bin/fish'

my terminal emulator window closes immediately instead of taking me back to an interactive fish prompt.

Best Answer

The problem lies in how you're calling the . special builtin:

exec /bin/sh -c '. vars.sh; /usr/bin/fish'

In sh, if the argument doesn't contain any /, . searches for the file in $PATH. So above, it would look for vars.sh in $PATH instead of the current directory as you intended.

Also, . being a special builtin, its failure causes the shell to exit (when not interactive), so the next command (here fish) is not executed which is why your terminal emulator window goes away without a fish prompt.

That can be prevented by calling . as command . which removes the special attribute of special builtins.

Note that the behaviour of bash (the sh implementation of the GNU project) is different in that regard when not in POSIX mode (when not called as sh, nor with --posix, and when the environment doesn't contain POSIXLY_CORRECT= nor SHELLOPTS=posix):

bash's . doesn't cause the shell to exit upon failure and it searches for slash-less argument in the current directory if it can't find it in $PATH.

In any case, POSIX mode or not, if you want the vars.sh in the current directory, you need the ./vars.sh syntax. So it's

exec sh -c 'command . ./vars.sh; exec fish'

Related Solutions

Linux – exec an entirely new process without an executable file

Yes, via memfd_create and fexecve:

int fd = memfd_create("foo", MFD_CLOEXEC);
// write your image to fd however you want
fexecve(fd, argv, envp);

Shell – Is it possible to perform shell command substitution without using a subshell

The choice of the title of your question is a bit confusing.

pushd/popd, a csh feature copied by bash and zsh, are a way to manage a stack of remembered directories.

pushd /some/dir

pushes the current working directory onto a stack, and then changes the current working directory (and then prints /some/dir followed by the content of that stack (space-separated).

popd

prints the content of the stack (again, space separated) and then changes to the top element of the stack and pops it from the stack.

(also beware that some directories will be represented there with their ~/x or ~user/x notation).

So if the stack currently has /a and /b, the current directory is /here and you're running:

 pushd /tmp/whatever
 popd

pushd will print /tmp/whatever /here /a /b and popd will output /here /a /b, not /tmp/whatever. That's independent of using command substitution or not. popd cannot be used to get the path of the previous directory, and in general its output cannot be post processed (see the $dirstack or $DIRSTACK array of some shells though for accessing the elements of that directory stack)

Maybe you want:

pushd "$(mktemp -d)" &&
popd &&
rmdir "$OLDPWD"

cd "$(mktemp -d)" &&
cd - &&
rmdir "$OLDPWD"

Though, I'd use:

tmpdir=$(mktemp -d) || exit
(
  cd "$tmpdir" || exit # in a subshell 
  # do what you have to do in that tmpdir
)
rmdir "$tmpdir"

In any case, pushd "$(mktemp -d)" doesn't run pushd in a subshell. If it did, it couldn't change the working directory. That's mktemp that runs in a subshell. Since it is a separate command, it has to run in a separate process. It writes its output on a pipe, and the shell process reads it at the other end of the pipe.

ksh93 can avoid the separate process when the command is builtin, but even there, it's still a subshell (a different working environment) which this time is emulated rather than relying on the separate environment normally provided by forking. For example, in ksh93, a=0; echo "$(a=1; echo test)"; echo "$a", no fork is involved, but still echo "$a" outputs 0.

Here, if you want to store the output of mktemp in a variable, at the same time as you pass it to pushd, with zsh, you could do:

pushd ${tmpdir::="$(mktemp -d)"}

With other Bourne-like shells:

unset tmpdir
pushd "${tmpdir=$(mktemp -d)}"

Or to use the output of $(mktemp -d) several times without explicitly storing it in a variable, you could use zsh anonymous functions:

(){pushd ${1?} && cd - && rmdir $1} "$(mktemp -d)"

Best Answer

Related Solutions

Linux – exec an entirely new process without an executable file

Shell – Is it possible to perform shell command substitution without using a subshell

Related Question