"sh -c" não expande parâmetros posicionais, se eu executá-lo de "sudo --login". Existe uma maneira de contornar isso?

Pela mesma razão

sudo --login echo '$HOME'

Não gera $HOME, mas o conteúdo da $HOMEvariável (do usuário de destino, conforme definido por sudo).

No seu caso, não é porque sh -c não expande os parâmetros posicionais , mas porque os $0, $1, $2já foram expandidos (pelo shell de login) no momento em que shfoi iniciado.

O que é mais surpreendente aqui é por que você vê all=1 2. E é a mesma razão pela qual você $@vê sudo --login echo '$@'.

Ambos -s/ --shelle -i/ --loginexecutam um shell para executar o comando. Mas sudofaz isso de uma maneira muito estranha.

Eu esperaria sudo -s 'some shell code'executar um shell para interpretar some shell code, mas não é isso que ele faz. Com -s, ele ainda espera executar um único comando simples e tenta citar (com \) alguns caracteres na esperança de fazer isso acontecer por meio desse shell.

Você não está destinado a fazer sudo -s 'echo test', mas sudo -s echo test. No primeiro caso, sudo realmente passa echo\ testcomo código shell. Em shells do tipo Bourne, isso tenta executar um comando chamado 'echo test'. Com um rcshell, isso executaria um comando chamado echo\como testargumento.

Além do SPC, existem alguns caracteres que sudoescapam. Isso inclui backtick, ;, |, (, ), *, &, =, \mas estranhamente, não $(ou talvez essa seja a única razão de ser dessas -s/ --loginopções: ter um shell expandir variáveis).

Ele inclui @embora. Se você observar o código , ele escapará de todos os bytes, exceto os alnums ASCII _, -e $.

 if (!isalnum((unsigned char)*src) && *src != '_' && *src != '-' && *src != '$')
   *dst++ = '\\';

Então:

sudo -s echo '$@'

sudorealmente é executado "$SHELL" -c 'echo $\@'e isso explica por que, no seu exemplo, $@não é expandido pelo shell iniciado, sudo --login mas por aquele que você diz para ele ser executado.

Na tua

sudo sh -c 'echo "p0=$0" && echo "p1=$1" && echo "p2=$2" && echo "all=$@"' sh 1 2

sudoexecuta rooto shell de login do '( bashno seu caso) e diz para ele interpretar:

sh -c echo\ \"p0\=$0\"\ \&\&\ echo\ \"p1\=$1\"\ \&\&\ echo\ \"p2\=$2\"\ \&\&\ echo\ \"all\=$\@\" sh 1 2

Os argumentos foram unidos com espaços e todos os caracteres SPC, ", =, &, @mas não $foram escapados. Como aqueles $não foram escapados, o shell de login do bash expandirá $0, $1, $2mas não $\@por causa dessa barra invertida.

Você pode ver com:

$ SHELL=echo sudo -s sh -c 'echo "p0=$0" && echo "p1=$1" && echo "p2=$2" && echo "all=$@"' sh 1 2
-c sh -c echo\ \"p0\=$0\"\ \&\&\ echo\ \"p1\=$1\"\ \&\&\ echo\ \"p2\=$2\"\ \&\&\ echo\ \"all\=$\@\" sh 1 2

Para que o shell de login bashacabe sendo executado shcom -co primeiro argumento,

echo "p0=-bash" && echo "p1=" && echo "p2=" && echo "all=$@"

como segundo argumento e sh, 1, 2como 3º, 4º e 5º.

Para contornar isso, você pode usar ${0}em vez de $0, porque sudoo transforma para $\{0\}impedir que o shell de login o expanda para o conteúdo de seu $0 :

$ sudo --login sh -c 'echo "p0=${0}" && echo "p1=${1}" && echo "p2=${2}" && echo "all=${@}"' sh 1 2
p0=sh
p1=1
p2=2
all=1 2

Edit: a história traz luz à razão por trás disso

mais descobertas ao olhar para o código. A não fuga de $foi aparentemente introduzida em 2013 por esta mudança . Que se refere ao bug#564 que se refere ao bug#413 .

Parece que antes que o bug#413 fosse "corrigido" , sudose comportou como eu esperava.

Aquilo é:

sudo -i 'some shell code'

O shell de login interpretou esse código de shell (e sudo -s 'some shell code'interpretou $SHELLesse código de shell). Mas a resolução do bug#413 quebrou, porque a pessoa que relatou o bug não entendeu que funcionava dessa maneira. E o bug#564 quebrou ainda mais (em uma tentativa de reverter apenas parte da quebra introduzida pela resolução do bug#413).

Cheguei a compilar sudo1.7.1 de 2009 e as opções -s/ -iestavam funcionando como eu esperava na época. 1.7.3(com resolução do bug # 413) funcionou como você aparentemente esperava:

$ sudo-1.7.1 -i 'echo "$SHELL"'
/bin/bash
$ sudo-1.7.3 -i 'echo "$SHELL"'
-bash: echo "$SHELL": command not found
$ sudo-1.8.21p2 -i 'echo "$SHELL"'
-bash: echo "/bin/bash": No such file or directory

$ sudo-1.7.3 -i sh -c 'echo "p0=$0" && echo "p1=$1" && echo "p2=$2" && echo "all=$@"' sh 1 2
p0=sh
p1=1
p2=2
all=1 2

Esse escape introduzido na correção para esse bug#413 é facilmente enganado porque bater a \na frente de todos os bytes (não caractere) não funciona para todos.

Além do caso óbvio de rconde \nem é um operador de citação, na maioria dos shells, a nova linha não pode ser citada com \:

$ SHELL=sh sudo -s echo $'a\nb'
ab
$ SHELL=csh  sudo -s echo $'a\nb'
a b

Isso também significa que argumentos vazios são descartados:

$ sudo printf '<%s>\n' a '' b
<a>
<>
<b>
$ sudo -s printf '<%s>\n' a '' b
<a>
<b>

Além disso, ao inserir um \antes de cada byte , está transformando caracteres em outros em charsets onde o byte 0x5c (a codificação de \) é encontrado em outros caracteres:

$ SHELL=bash LC_ALL=zh_HK.big5hkscs sudo -s echo $'\xa3``uname`\xa3`'
bash: line 2: Linuxα: command not found
α

0xa3 0x60 é grego Epsilon nessa localidade. E sudo muda o 0x60s para 0x5c 0x60 e 0xa3 0x5c é o alfabeto grego, o que explica por que o unamecomando foi executado. sudomudou o

ε`uname`ε

para

\α`\`uname\`\α`

E é claro que o comportamento acaba sendo surpreendente, pois os parâmetros posicionais $-, , e (onde é um nome de variável POSIX válido) são expandidos, mas não os outros parâmetros (como aqui, mas também , , , ) ou ou ( / / ) ou ( // ...).$$$varnamevarname$@$!$?$*$#${varname}$var[1]cshtcshzsh$var(1)rces