Por que o parâmetro $ 0 me fornece apenas o nome da base ao invés do caminho completo depois de converter x-shellscript em x-executable?

Question

Meu problema aqui é que o parâmetro $0 dá o mesmo resultado que ${0##*/} , e isso acontece depois de converter o x-shellscript em x-executable usando o programa SHC!

OS: Debiab-8.2-jessie Versão SHC: 3.8.7 cmd usado: shc -f script.bash

O script.x compilado reside em um caminho bin extra (não conhecido pelo sudo). Nota Eu criei um programa hello world para imprimir o parametro $ 0, e ele sempre me dá o nome de base!

Meu scriptFile contém:

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

Quando eu executo, eu entendo isso:

sudo: scriptName: command not found

Após o check-out, descobri que o parâmetro $0 é o mesmo que ${0##*/} ou $(basename $0) dentro de um x-executável!

Como faço para lidar com isso sem colocar um caminho absoluto dentro do script? Ou há algo que eu deveria saber quando estou compilando shell para x-executable usando SHC?

    

Answer 1

Por que SHC?

Primeiro de tudo, por que você está usando o SHC, dadas as suas motivações "amadores"? Aqui está um trecho de sua própria descrição:

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.

• Minha opinião (vou mantê-lo um pouco breve): Mesmo que sua motivação seja o "propósito principal" de impedir modificações, uma pessoa levemente determinada pode ainda recuperar (e, portanto, modificar) a roteiro original! O SHC essencialmente fornece segurança pela obscuridade , que é uma estratégia frequentemente ridicularizada quando usada como um primário meios de segurança. Se isso não soa útil, eu recomendo abandonar o SHC e simplesmente usar shell scripts como a maioria dos outros faz. Se você precisa de segurança real para seus scripts de shell, sugiro fazer uma pergunta específica sobre isso, sem SHC ou "compiladores".

O problema específico do $ 0

Eu baixei o SHC 3.8.9 de esta página só para tentar isso.

Eu não consegui reproduzir o problema no Ubuntu 14.04 LTS.

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

Execução de teste

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

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

Então, claramente, nossos sistemas são diferentes. Eu posso tentar atualizar esta resposta se você postar mais detalhes sobre o seu sistema operacional, versão do SHC, e específico script shell e shc linha de comando que você usou para "compilar".

Por que você precisa do caminho?

Por que seu script precisa conhecer seu caminho? Você está armazenando arquivos com o script? É "padrão" operar no diretório em que foi executado se o usuário não especificar? Se essas coisas são boas ou não, é uma questão de opinião, mas conhecer suas motivações pode ser útil para restringir essa resposta.

Como buscar o diretório atual

O comando pwd busca o diretório atual. Em muitos casos, você pode montar o caminho completo do seu script (assumindo que ele foi executado com um caminho relativo explícito) com algo como:

realname="'pwd'/$0"

... o que resultaria em um valor como:

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

O ./ extra significa apenas "diretório atual", portanto, embora possa ser cosmeticamente desafortunado, isso não afetará negativamente o resultado.

Se o script estiver simplesmente em $PATH , você precisará usar which em vez de pwd , mas já estamos indo além do escopo da pergunta original, aqui, então concluirei com uma simples menção de que determinar nomes de caminho pode ser um processo complicado, especialmente se você precisar fazer isso de maneira segura, de modo que seria melhor deixar para outra pergunta com uma declaração de problema específica ao longo destas linhas.

    

Answer 2

parece que bash (e / ou ld.so) não coloca o nome completo do executável em argv [0] quando ele localiza um binário por busca de caminho. se você especificar o diretório ao executá-lo (em vez de depender do caminho), ele obtém o nome correto.