Why does the parameter $0 give me only the basename instead of full path after converting x-shellscript to x-executable?

Question

My problem here is that the parameter $0 gives the same result as ${0##*/}, and that happens after converting the x-shellscript to x-executable using the SHC program!

OS: Debiab-8.2-jessie SHC version: 3.8.7 cmd used: shc -f script.bash

The compiled script.x resides in a extra bin path (not known by sudo). Note I've created a hello world program to print the parametr $0, and it always gives me the basename!

My scriptFile contains:

#!/bin/bash
((!EUID)) || exec sudo "$0"
# shellcode ...

When I execute it, I get this:

sudo: scriptName: command not found

After checking out I found that the parameter $0 is the same as ${0##*/} or $(basename $0) inside an x-executable!

How do I deal with that without putting an absolute path inside the script? Or is there something I should know when I'm compiling shell to x-executable using SHC?

Answer 1

Why SHC?

First of all, why are you using SHC, given your "hobbyist" motivations? Here is an excerpt from their own description:

Upon execution, the compiled binary will decrypt and execute the code with the shell -c option. Unfortunatelly, it will not give you any speed improvement as a real C program would.

The compiled binary will still be dependent on the shell specified in the first line of the shell code (i.e. #!/bin/sh), thus shc does not create completely independent binaries.

SHC's main purpose is to protect your shell scripts from modification or inspection.

• My opinion (I'll keep it sort of brief): Even if your motivation is the stated "main purpose" of preventing modifications, a mildly determined person can still recover (and, hence, modify) the original script! SHC essentially provides security by obscurity, which is an oft-derided strategy when used as a primary means of security. If this doesn't sound helpful, then I'd recommend ditching SHC and simply using shell scripts as the vast majority of others do. If you need real security for your shell scripts, I'd suggest asking a specific question about that, without SHC or "compilers".

The specific $0 problem

I downloaded SHC 3.8.9 from this page just to try this out.

I was not able to reproduce the problem, on Ubuntu 14.04 LTS.

#!/bin/bash
echo "Hello, world. My name is \`$0'"

Test run

$ ./shc -f my_test.bash
$ ~/path/to/my_test.bash.x

Hello, world. My name is `~/path/to/my_test.bash.x'

So, clearly, our systems differ. I can try to update this answer if you post more details about your operating system, version of SHC, and specific shell script and shc commandline you used to "compile" it.

Why do you need the path?

Why does your script need to know its path? Are you storing files with the script? Does it "default" to operate on the directory it was run in if the user doesn't specify? Whether these things are good ideas or not is a matter of opinion, but knowing your motivations might be helpful in narrowing down this answer.

How to fetch the current directory

The pwd command fetches the current directory. In many cases, you can assemble the full path of your script (assuming it was run with an explicit relative path) with something like:

realname="`pwd`/$0"

... which would result in a value like:

/path/to/script/./yourscript.bash.x

The extra ./ just means "current directory", so while it might be cosmetically unfortunate, it will not negatively affect the result.

If the script is simply in your $PATH, then you would need to use which instead of pwd, but we're already getting beyond the scope of the original question, here, so I'll conclude with a simple mention that determining pathnames can be a tricky process, especially if you need to do so in a secure manner, so that would best be left for another question with a specific problem statement along these lines.

Answer 2

it seems to be because bash (and/or ld.so) doesn't put the full name of the executable in argv[0] when it locates a binary by path search. if you specify the directory when you run it (instead of relying on path) it gets the right name.