Closed paddy-hack closed 5 years ago
As for the last question, @micdahl, do you remember?
I only can vaguely remember that there were some issues with the correct interpreting of the command when invoking rspec via docker when leaving out the bash -c
. But I am not sure about the details any more. I think it was, that additional parameters like specific files or line numbers were not recognized correctly without it. sh -c
should do the work all the same IMHO.
Hi, I just ran into a use case for /bin/sh -c
while hacking up a completely unrelated script to backup data for a service I run at the office. A bin/sh -c 'your-command-here'
, note the single quotes!, can be used to specify environment variables set inside the container. Not tested but I think you could also use it to do command-line expansion inside the container, i.e. use backticks or $(...)
constructs. Just for illustration purposes, assume RUBY_VERSION
is not set in the environment that emacs
sees. Then using a command
set to echo $RUBY_VERSION
would show what is set inside the container.
FWIW, I haven't tested this using rspec-mode but it works like that for my backup script :smile:
OK, let's use sh!
First of, thanks!
Second, I like to use
alpine
based Docker images which typically come withoutbash
. The currentdocker
ordocker-compose
invocations usebash -c
. That breaks my use case. Usingsh -c
or/bin/sh -c
fixes this. It is extremely unlikely to break those images that havebash
.However, I'm also curious why the
bash -c
is there to begin with. Wouldn't simply leaving it out be good enough?