[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bash source code block: problem after ssh commands
From: |
Max Nikulin |
Subject: |
Re: bash source code block: problem after ssh commands |
Date: |
Sat, 28 Oct 2023 12:22:39 +0700 |
User-agent: |
Mozilla Thunderbird |
On 28/10/2023 01:26, Alain.Cochard@unistra.fr wrote:
bash -c "bash /path/to/file-containing-the-source-code.sh"
Without the quotes, the 1st line is not executed either. NB: I get
the same behavior with simply
Without quotes it means: execute shell script (just "bash" this case)
with "$0" set to "/path/to/file-containing-the-source-code.sh".
"/path/..." is ignored because shell script does not contain "$0". It is
a way to safely pass arguments to shell, however "$0" is confusing:
sh -c 'echo "arg0: $0"; echo args: "$@"' arg0 arg1 arg2
arg0: arg0
args: arg1 arg2
In this example "arg0: $0"; echo args: "$@"' has the same role as
"bash" in the cited command.
If you need to pass another variable into "sh -c" the use
var="/bin/sh"
sh -c 'ls -l "$1"' argv0-for-sh "$var"
Unsafe variant ("var" contain quotes): sh -c "ls -l '$var'". The same
warning is applicable to "emacs --eval "(func \"$var\")".
or, after making the script executable with 'chmod +x':
/path/to/file-containing-the-source-code.sh
Always add a shebang ("#!/bin/sh", "#!/bin/bash", etc.) to executable
scripts. A chance to face a bug is a shell is higher when it is left up
to the shell and the kernel what to do with files without shebangs.
Sorry, I have not tried to debug the original issue.
Re: bash source code block: problem after ssh commands, Russell Adams, 2023/10/26