Bash – Why doesn’t source work when I call bash -c

bashquotingshell

I want to run a command that sources a script to take on some env. variables before executing, without sourcing them in my current shell.

test.env

export test=1

None of these commands echo the env. variable:

a) Shouldn't this work? Aren't I just executing these commands in a new shell and returning the output?

$ bash -c "source test.env && echo $test"

b) Here I execute test.env and try to run echo $test in the same process using exec.

$ bash -c "./test.env && exec echo $test"

c) Lastly I just tried this since it was a possible permutation. But it executes test.env and the echo command as separate processes.

$ bash -c "./test.env && echo $test"

And how can I get this to work where the env. variables are sourced before the 2nd command is executed?

Best Answer

You must escape dollar sign $ in your first command, otherwise bash will expand it before your command executed:

$ bash -c "source test.env && echo \$test"

Or you should use single quote instead of double quote:

$ bash -c 'source test.env && echo $test'

Related Solutions

Bash – Why Using yes in Pipelines Doesn’t Cause Infinite Loops

When true exits, the read side of the pipe is closed, but yes continues trying to write to the write side. This condition is called a "broken pipe", and it causes the kernel to send a SIGPIPE signal to yes. Since yes does nothing special about this signal, it will be killed. If it ignored the signal, its write call would fail with error code EPIPE. Programs that do that have to be prepared to notice EPIPE and stop writing, or they will go into an infinite loop.

If you do strace yes | true¹ you can see the kernel preparing for both possibilities:

write(1, "y\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\n"..., 4096) = -1 EPIPE (Broken pipe)
--- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=17556, si_uid=1000} ---
+++ killed by SIGPIPE +++

strace is watching events via the debugger API, which first tells it about the system call returning with an error, and then about the signal. From yes's perspective, though, the signal happens first. (Technically, the signal is delivered after the kernel returns control to user space, but before any more machine instructions are executed, so the write "wrapper" function in the C library does not get a chance to set errno and return to the application.)

¹ Sadly, strace is Linux-specific. Most modern Unixes have some command that does something similar, but it often has a different name, it probably doesn't decode syscall arguments as thoroughly, and sometimes it only works for root.

Bash – a *.sorted command and why doesn’t it work in the bash

They're not expressions, they're filenames for files produced as follows:

 printenv | sort > printenv.sorted
 set | sort > set.sorted

That's not clear from the documentation so your confusion is understandable!

Note that you may need to help diff and grep by forcing them to treat their inputs as text (with -a); environment variables can contain values which will cause them to treat their input as binary, which won't produce anything useful:

diff -a set.sorted printenv.sorted | grep -a "<" | awk '{ print $2 }'

Better still, use comm to compare the two files:

comm -23 set.sorted printenv.sorted

You can replace the files with process substitutions:

comm -23 <(set|sort) <(printenv|sort)

to avoid creating files.

Best Answer

Related Solutions

Bash – Why Using yes in Pipelines Doesn’t Cause Infinite Loops

Bash – a *.sorted command and why doesn’t it work in the bash

Related Question