Isso não é realmente um problema, apenas uma peculiaridade que gostaria de entender.
Se eu obtiver um shell root sudo bash -l
e depois executar, less somefilename
recebo menos apenas mostrando:
Esta conta não está disponível no momento.
(Isso não é mostrado como um erro , é mostrado dentro de less como se fosse o conteúdo do arquivo.)
No entanto, se eu usar o mesmo shell raiz sudo bash -l
e executar cat somefilename | less
, verei o conteúdo real do arquivo.
Além disso, se eu obtiver um shell de root sudo bash
e pular -l
e executá-lo, less somefilename
ele mostrará o conteúdo do arquivo.
O login do Root está desabilitado; a /etc/passwd
linha é root:x:0:0:root:/root:/sbin/nologin
tão sudo su -
não funciona.
Mas, por que a nologin
entrada deveria fazer alguma diferença na execução less
de um arquivo? E por que só faz diferença se less
for executado diretamente no arquivo, em vez de também aplicar menos execução em seu stdin? E por que isso só acontece com um bash -l
shell?
(Isso está em um sistema CentOS 7.)
Isso acontece devido ao
less
método de invocar comandos especificados emLESSOPEN
ouLESSCLOSE
. Se aSHELL
variável de ambiente estiver definida, ela usará seu valor como o shell a ser usado para executá-los.Assim, no seu cenário, since
LESSOPEN
está definido (graças ao uso delesspipe
),less
executa o equivalente a"$SHELL" -c …
e mostra o resultado disso como o conteúdo do arquivo (já que esse é o comportamento esperado com umLESSOPEN
canal). ComoSHELL
isnologin
, você vê a saída desse comando.Com uma
lesspipe
configuração padrão, o canal não é usado seless
estiver recebendo sua entrada de um canal, o que explica esse comportamento.SHELL
é definido apenas por shells de login. Se você executarbash
sem-l
,SHELL
mantém o valor que tinha anteriormente.(Na verdade, como
less
usapopen
, o comando run ésh -c "$SHELL" -c …
)