Return to Answer

My man page says:

$0 : expands to the name of shell or shell script.

It seems this translates to argv[0] of the current shell - or the first nonoperand commandline argument the currently interpreting shell is fed when invoked. I previously stated that sh ./somescript would path its $0 $ENV variable to sh but this was incorrect because the shell is a new process of it' s invoked with a new $ENV.

In this way sh ./somescript.sh differs from . ./somescript.sh because it runs in the current environment and $0 is already set.

You can check this by comparing $0 to /proc/$$/status.

echo 'script="/proc/$$/status"
    echo $0
    cat "$script"' \
    > ./script.sh
sh ./script.sh ; . ./script.sh

Thanks for the correction, @toxalot. I learned something.

My man page says:

$0 : expands to the name of shell or shell script.

It seems this translates to argv[0] of the current shell - or the first nonoperand commandline argument the currently interpreting shell is fed when invoked. I previously stated that sh ./somescript would path its $0 $ENV variable to sh but this was incorrect because the shell is a new process of its own and invoked with a new $ENV.

In this way sh ./somescript.sh differs from . ./somescript.sh which runs in the current environment and $0 is already set.

You can check this by comparing $0 to /proc/$$/status.

echo 'script="/proc/$$/status"
    echo $0
    cat "$script"' \
    > ./script.sh
sh ./script.sh ; . ./script.sh

Thanks for the correction, @toxalot. I learned something.

In short, to the best of my knowledge, $0 is the path to the current process leader. So if your script is executable (as in chmod +x) its path is $0, but, if it is instead an argument to a shell ( like . ./myscript.sh, $(. ./myscript.sh), or sh ./myscript.sh), then $0 paths the shell process under which it runs.

The above is incorrect - I'm editing now.

My man page says:

$0 : expands to the name of shell or shell script.

It seems this translates to argv[0] of the current shell - or the first nonoperand commandline argument the currently interpreting shell is fed when invoked. I previously stated that sh ./somescript would path its $0 $ENV variable to sh but this was incorrect because the shell is a new process of it' s invoked with a new $ENV.

In this way sh ./somescript.sh differs from . ./somescript.sh because it runs in the current environment and $0 is already set.

You can check this by comparing $0 to /proc/$$/status.

echo 'script="/proc/$$/status"
    echo $0
    cat "$script"' \
    > ./script.sh
sh ./script.sh ; . ./script.sh

Thanks for the correction, @toxalot. I learned something.

In short, to the best of my knowledge, $0 is the path to the current process leader. So if your script is executable (as in chmod +x) its path is $0, but, if it is instead an argument to a shell ( like . ./myscript.sh, $(. ./myscript.sh), or sh ./myscript.sh), then $0 paths the shell process under which it runs.

In short, to the best of my knowledge, $0 is the path to the current process leader. So if your script is executable (as in chmod +x) its path is $0, but, if it is instead an argument to a shell ( like . ./myscript.sh, $(. ./myscript.sh), or sh ./myscript.sh), then $0 paths the shell process under which it runs.

The above is incorrect - I'm editing now.