Weijun Zhou's questions

Achei algo surpreendente quando estou escrevendo para algum script bash hoje. Eu o fixei neste exemplo mínimo.

[[ a>b ]]; echo $?

Com base no meu entendimento, como não há espaços ao redor do >, isso deve testar se a string a>bnão está vazia e deve retornar um código de erro de 0. No entanto, o comando acima ecoa 1em ambas as versões do bash que testei (detalhes abaixo).

Eu também testei usando o antigo testcomando "good",

[ a>b ]; echo $?echos 0(testa se a string anão está vazia e cria um arquivo vazio bno meu diretório de trabalho atual, aparentemente >bé tratado como um redirecionamento, o que é compreensível).

Então eu tentei mais algumas outras coisas

• [[ b>a ]]; echo $?ecos 0e nenhum arquivo é criado.
• [[ b<a ]]; echo $?ecos 1e nenhum arquivo é criado.
• [[ a<b ]]; echo $?ecos 0e nenhum arquivo é criado.
• [ b>a ]; echo $?echos 0e cria um arquivo vazio a.
• [ b<a ]; echo $?relata um erro de arquivo ausente ae ecos 1devido a esse erro.
• [ a<b ]; echo $?relata um erro de arquivo ausente be ecos 1devido a esse erro.
• [[ a=b ]]; echo $?echos 0porque está testando se a string a=bnão está vazia como eu esperava.
• [ a=b ]; echo $?ecos 0pelo mesmo motivo.
• [[ a==b ]]; echo $?ecos 0pelo mesmo motivo.
• [ a==b ]; echo $?ecos 0pelo mesmo motivo.
• [[ a!=a ]]; echo $?e [ a!=a ]; echo $?ambos ecoam 0(esperado)

Portanto, parece que apenas os espaços ao redor de <e >podem ser omitidos em uma expressão condicional, mas não =ou ==ou !=se a intenção for fazer comparação de strings. Mas por que ele é projetado dessa maneira? Também pode ser minha omissão, mas isso não parece estar documentado em nenhum lugar do manual do bash.

Meu problema original é tentar usar >sem escape como parte de um padrão em uma expressão condicional ( [[ ... ]]). Originalmente, pensei que, desde que não envolvesse o >com espaços, poderia usá-lo sem escape sem problemas, porque não faz sentido (e acaba sendo impossível após alguns testes) fazer redirecionamentos dentro de um condicional expressão também.

No entanto, verifica-se que não é o caso. É claro que a solução simples é apenas escapar disso >e escrever \>, mas não entendo por que isso é necessário.

Aqui estão as versões do bash que usei para testar,

GNU bash, version 5.2.2(1)-release (aarch64-unknown-linux-android)

e

GNU bash, version 3.2.25(1)-release (x86_64-redhat-linux-gnu)

Meus experimentos são realizados sob env -i bash --norc --noprofile.

Qual é a diferença entre a[bc]de a{b,c}d? Por que as pessoas usam a{b,c}dquando já existe a[bc]d?

eu executei

history > before; (history -d $n); history > after

onde $né o número correspondente ao último comando que digitei na mesma sessão interativa antes de executar esta linha,

O resultado é que a linha marcada $nnão é removida do histórico. Se eu remover os parênteses para que history -dseja executado no shell atual, ele funcionará conforme documentado.

Como entender esse comportamento? É verdade que todos os scripts que manipulam a história precisam ser sourced?

Estou tentando entender alguns problemas de desempenho relacionados a sede awk, e fiz o seguinte experimento,

$ seq 100000 > test
$ yes 'NR==100001{print}' | head -n 5000 > test.awk
$ yes '100001{p;b}' | head -n 5000 > test.sed
$ time sed -nf test.sed test
real    0m3.436s
user    0m3.428s
sys     0m0.004s
$ time awk -F@ -f test.awk test
real    0m11.615s
user    0m11.582s
sys     0m0.007s
$ sed --version
sed (GNU sed) 4.5
$ awk --version
GNU Awk 4.2.1, API: 2.0 (GNU MPFR 3.1.6-p2, GNU MP 6.1.2)

Aqui, como o arquivo de teste contém apenas 100.000 linhas, todos os comandos test.sede test.awksão no-ops. Ambos os programas só precisam combinar o número da linha com o endereço (in sed) ou NR(in awk) para decidir que o comando não precisa ser executado, mas ainda há uma grande diferença no custo de tempo. Por que é o caso? Existe alguém com versões diferentes sede awkinstaladas que dê um resultado diferente neste teste?

Edit : Os resultados para mawk(como sugerido por @mosvy), original-awk(o nome para "one true awk" em sistemas baseados em debian, sugeridos por @GregA.Woods) e perlsão fornecidos abaixo,

$ time mawk -F@ -f test.awk test
real    0m5.934s
user    0m5.919s
sys     0m0.004s
$ time original-awk -F@ -f test.awk test
real    0m8.132s
user    0m8.128s
sys     0m0.004s
$ yes 'print if $.==100001;' | head -n 5000 > test.pl
$ time perl -n test.pl test
real    0m33.245s
user    0m33.110s
sys     0m0.019s
$ mawk -W version
mawk 1.3.4 20171017
$ perl --version
This is perl 5, version 28, subversion 1 (v5.28.1) built for x86_64-linux-thread-multi

A substituição -F@por -F ''não faz alterações observáveis ​​no caso de gawke mawk. original-awknão suporta vazio FS.

Edit 2 O teste de @mosvy dá resultados diferentes, 21s para sede 11s para mawk, veja o comentário abaixo para mais detalhes.

Existem muitos (IMHO, muitos) lugares para configurar o(s) servidor(es) DNS usado e não tenho certeza sobre a relação entre eles. Algumas perguntas são: Quais configurações são consultadas apenas condicionalmente (por exemplo, se entendi corretamente, a configuração do systemd não é consultada se o serviço correspondente não estiver em execução)? Quais configurações substituem quais? Qual é a maneira recomendada de configurar o DNS?

Para citar alguns lugares para configurar o servidor DNS (juntamente com algumas outras informações que conheço sobre eles, que devem ser gentilmente corrigidas se houver algum mal-entendido),

1. Escreva /etc/resolv.confe use chattrpara forçá-lo a permanecer persistente após a reinicialização (acho que este é desencorajado)
2. resolvconf. Configure nos vários arquivos em /etc/resolvconf/resolv.conf.d. Use resolvconf -apara adicionar um DNS e resolvconf -uatualizá-lo
3. systemd-resolve(d), uma unidade de systemd. Configurar em /etc/systemd/resolvd.conf. Ele usa o endereço 127.0.0.53como o solucionador de DNS fictício no /etc/resolv.conf. O real resolv.confé encontrado em /var/run/systemd/resolve/resolv.conf. Nas versões mais recentes (desde qual versão?), systemd-resolve --statuspode ser usado para consultar o status atual do DNS.
4. /etc/network/interfaces. Este está relacionado com/etc/systemd/system/network-online.target.wants/networking.service
5. Network-Manager, um componente que aciona o menu de contexto de configuração de rede na GUI. Se uma interface estiver configurada em /etc/network/interfaces, ela se recusará a gerenciá-la novamente (mostrado como not managedno menu de contexto da GUI).

Estou executando Ubuntu 18.04 LTScom o ambiente de desktop Unity.

Aviso: NÃO tente os comandos listados nesta pergunta sem saber suas implicações.

Desculpe se isso é uma duplicata. Estou surpreso ao saber que um comando tão simples quanto

echo $(yes)

congela meu computador (na verdade, está deixando o computador muito lento, em vez de congelar, mas o atraso é ruim o suficiente para fazer alguém pensar que ele congelou). Digitar CtrlCou CtrlZlogo após digitar este comando não parece me ajudar a recuperar desse comando digitado incorretamente.

Por outro lado

ls /*/../*/../*/../*/../*/

é uma vulnerabilidade bem conhecida que também atrasa muito o computador para o melhor e trava o computador para o pior.

Observe que esses comandos são bem diferentes das conhecidas bombas fork.

Minha pergunta é: Existe uma maneira de interromper esses comandos que acumulam uma grande quantidade de opções de linha de comando do shell imediatamente após eu começar a executá-los no shell?

Meu entendimento é que, como a expansão do shell é feita antes da execução do comando, a maneira usual de interromper um comando não funciona porque o comando nem está em execução quando ocorre o atraso, mas também quero confirmar que meu entendimento está correto e Estou extremamente interessado em aprender alguma maneira de cancelar a expansão do shell antes que ela use muita memória.

Não estou procurando como o kernel funciona com pouca memória. Também não estou procurando SysRqexageros que possam ser úteis quando o sistema já está terrivelmente atrasado. Também não estou procurando abordagens preventivas como impor um ulimitna memória. Estou procurando uma maneira que possa efetivamente cancelar um enorme processo de expansão do shell de dentro do próprio shell antes que ele atrase o sistema. Não sei se é possível. Se for impossível conforme comentado, por favor, deixe também uma resposta indicando isso, de preferência com explicações.

Optei por não incluir nenhuma informação específica do sistema na pergunta original porque quero uma resposta geral, mas caso isso seja importante, aqui estão as informações sobre meu sistema: Ubuntu 16.04.4 LTScom gnome-terminale bash 4.3.48(1), executando um x86_64sistema. Nenhuma máquina virtual envolvida.

estou usando GNU bash 4.3.48. Considere os dois comandos a seguir que diferem apenas por um único cifrão.

Comando 1:

echo "(echo " * ")"

Comando 2:

echo "$(echo " * ")"

A saída deles são, respectivamente

(echo  test.txt ppcg.sh )

e

 * 

Portanto, obviamente, no primeiro caso, o *é globbed, o que significa que a primeira aspa acompanha a segunda para formar um par, e a terceira e a quarta formam outro par.

No segundo caso, o *não é globbed e há exatamente dois espaços extras na saída, um antes do asterisco e outro depois, o que significa que a segunda aspa acompanha a terceira e a primeira acompanha a quarta.

Existem outros casos além da $()construção em que as aspas não correspondem à próxima, mas estão aninhadas? Esse comportamento está bem documentado e, em caso afirmativo, onde posso encontrar o documento correspondente?

Eu notei esta pergunta no ServerFault:

FreeBSD: Diretório chamado ^C (sério!) - como remover?

Eu sabia sobre o ^Vpapel há muito tempo. O que me interessa nessa postagem é que o OP pode ver o ^Ccaractere como ^C(sinal circunflexo seguido por um C) na conclusão da tabulação, mas não em ls. Então, procuro um pouco a página de manual e posso descobrir ls -bquais saídas \003, ls -Nquais não fazem nada de especial para ^Ce ls --show-control-charsquais mostram um caractere Unicode na tela.

Minha primeira pergunta é: existe uma maneira simples lsde gerar o mesmo tipo de saída que a conclusão da guia, ou seja, ^C(sinal circunflexo seguido por um C)? ( cat -vcomportamento).

Minha segunda pergunta é: como $LANGe as $LC_*variáveis ​​ambientais afetam a saída gerada pelo preenchimento da guia (acho que está documentado completee talvez na Seção 8 do Manual do Bash, mas não parece encontrar nada relevante)?

Estou usando basho 4.3, mas soluções para outros shells também são bem-vindas.

Eu estou querendo saber se existe uma maneira simples de operar em certas linhas com números de linha pré-atribuídos.

Digamos que eu queira gerar a 1ª, 7ª, 14ª e 16ª linhas de um arquivo, posso simplesmente fazer

sed -n '1p;7p;14p;16p' input_file

mas isso fica mais complicado quando a operação não é apenas imprimir, e eu não quero escrever o mesmo comando longo 4 vezes (e sim, eu sei que posso construir esse comando sed longo substituindo a mesma variável bash 4 vezes, mas isso não é ideal o suficiente ...), ou seja

sed -n '1{long_command};7{long_command};14{long_command};16{long_command}' input_file

Existe uma maneira de fazer a operação nessas linhas específicas do meu arquivo? Estou esperando algo como,

sed -n '1,7,14,16p'

que certamente não funcionará na forma atual.

Qualquer ajuda será apreciada. "Não, não é possível." com explicações também é uma resposta que aceitarei.

Tenho usado basha maior parte do tempo e acabei de começar a brincar com outras conchas. Comecei dashe tento descobrir o número da versão, mas o método usual gosta -vou $versionnão funciona. Eu posso entender que --versionnão vai funcionar, pois é específico do GNU. Pesquisei na net e encontrei as seguintes respostas, todas recorrendo ao sistema de gestão de pacotes.

Como saber o número da versão do traço? (o usuário está usando o CentOS, então a resposta depende do sistema Redhat Package Management)

e

Como encontrar a versão do shell traço no Ubuntu bin? (Isto é do site AskUbuntu, então a resposta depende da Advanced Package Tool)

Então, existe uma maneira de descobrir a versão dashsem recorrer ao sistema de gerenciamento de pacotes? Ficarei muito surpreso se não houver uma maneira simples, porque sempre acreditei que consultar a versão de um software é uma das funções mais fundamentais. Se esse for realmente o caso, ficaria feliz em ouvir alguma explicação, por exemplo, qual é a filosofia por trás desse design. Ficarei feliz em aceitar uma maneira simples de obter a dashversão sem recorrer ao sistema de gerenciamento de pacotes ou uma explicação convincente (perspectiva histórica também OK) sobre por que não posso fazer isso como a resposta aceita.

Sempre que preciso digitar um comando longo, acho muito útil o ponto de exclamação para se referir ao histórico. Por exemplo, !sshpode ser usado para invocar o último sshcomando que usei. No entanto, não consigo fazê-lo funcionar quando argumentos delimitados por espaço são adicionados à pesquisa.

Ao executar !ssh -i, espero que o último comando começando com a string "ssh -i" seja executado. No entanto, o comando real que é invocado é o último sshcomando com qualquer argumento e, em seguida, "-i" foi anexado ao comando.

Posso usar, !?ssh -i?mas isso serve para fazer algo diferente e acredito que deve haver uma maneira simples de conseguir isso. Também reluto em digitar history|grep ...todas as vezes.

Então, como posso me referir a um comando no histórico que começa com uma string contendo espaço, conforme indicado acima?

Editar Parece que não expliquei a questão com clareza suficiente. Digamos que eu tenha o seguinte histórico

ssh -i identity host1
echo ssh -i
ssh host2

agora, se eu executar !ssh, o terceiro comando, ou seja, ssh host2será executado. Espero digitar !ssh -ipara obter o primeiro comando executado, mas ssh host2 -ié executado em vez disso (o que resulta em um erro). Posso usar !?ssh -i?para executar o primeiro comando somente se o segundo comando não existir .

TL/DR: Acho que a resposta aceita é completa para minha expectativa. Outras respostas que adicionam informações úteis ao tópico ainda são bem-vindas.

Eu usei ambos rpm( dnf) e aptsistemas de gerenciamento de pacotes. Nos rpmsistemas que percebo quando atualizo ou instalo novos pacotes, quase sempre solicita a confirmação do usuário e o padrão é "não" na maioria das vezes. No aptsistema, noto que às vezes ele não solicita a confirmação do usuário e às vezes solicita ao usuário um "sim" padrão.

Portanto, minha pergunta é: quando apt-getou coisas semelhantes solicitam a confirmação do usuário e, se o fazem, quando o padrão é sim?

Acho que devo ser capaz de encontrar a resposta se pesquisar a fonte de apt, mas não consegui, provavelmente porque não usei a ferramenta ou o método certo para processar o código-fonte.

Note que não estou pedindo apt-get -y, apt-get --assume-noou coisas parecidas . Eu conheço essas opções e não estou pedindo que alguém me diga que elas existem. Estou perguntando o comportamento quando nenhum sinalizador de linha de comando adicional é fornecido . Pode depender das opções da linha de comando ao compilar, mas responder ao comportamento do aptenviado no padrão debiane ubuntunos repositórios deve ser suficiente.

Edit : Eu sei que o Apt-get install não pede confirmação no LinuxQuestions.org, mas sempre pensei que há casos em que o prompt de apt-getpadrão é não (ou seja [y/N]), e quero evidências da fonte.

Da resposta aceita, fica claro que

Se o prompt estiver no formato

Do you want to continue? [Y/n]

O padrão é sempre sim.

A partir do comentário na resposta aceita, finalmente encontrei evidências do código-fonte que estava procurando: https://github.com/Debian/apt/search?utf8=%E2%9C%93&q=YnPrompt

Então, acho que encontrei uma resposta completa para minha pergunta.

Editar 2 : Percebi, pouco depois de aceitar a resposta, que realmente vi os sistemas baseados em [y/N].yum

Disseram-me que os espaços são importantes em bashou em outros scripts de shell e não devo alterar a existência de espaços, a menos que saiba o que estou fazendo. Por "alterar a existência" quero dizer inserir um espaço entre dois caracteres não espaciais ou remover um espaço entre dois caracteres não espaciais, por exemplo, mudar var="$val"para var ="$val"ou vice-versa. Eu quero perguntar

Existem casos em que usar um único espaço ou usar vários espaços consecutivos em um script de shell faz diferença? .

(É claro que inserir/excluir um espaço entre aspas faz diferença, como mudar de echo "a b"para echo "a b"ou vice-versa. Estou procurando outros exemplos além deste exemplo trivial.)

Eu me deparei com essa questão, mas essa é sobre adicionar e remover espaços entre dois caracteres não espaciais, para os quais conheço muitos exemplos de que fariam a diferença.

Qualquer ajuda seria apreciada. Inclua mais variedades de conchas, se possível.

Normalmente, os pipelines no Unix são usados ​​para conectar dois comandos e usar a saída do primeiro comando como entrada do segundo comando. No entanto, recentemente tive a ideia (que pode não ser nova, mas não encontrei muito pesquisando no Google) de usar o pipeline para executar vários comandos em paralelo, como este:

command1 | command2

Isso invocará command1e command2em paralelo se command2não ler da entrada padrão e command1não gravar na saída padrão . Um exemplo mínimo para ilustrar isso é (execute-o em um shell interativo)

ls . -R 1>&2|ls . -R

Minha pergunta é: há alguma desvantagem em usar o pipeline para paralelizar a execução de dois comandos dessa maneira? Existe alguma coisa que eu perdi nessa ideia?

Muito obrigado antecipadamente.

Tendo usado o Linux por anos, de repente descobri que não sabia como usar o mancomando corretamente. É bem conhecido que se pode digitar qpara sair de uma página de manual, /para pesquisar e outros. Eu não sei, no entanto, onde eles estão documentados. Eu tentei man man man -a man info mane pesquisei, sem sorte.

Por favor, indique-me a posição certa para procurar esta informação, mesmo que esteja correta man mane eu a tenha esquecido, está perfeitamente bem, apenas me avise.

Esses comandos são diferentes para diferentes sistemas operacionais ou para diferentes distribuições do Linux?

Eu tenho uma saída de um comando que desejo canalizar para algum tipo de comando grep para obter a parte em cada linha que corresponde a um determinado regex e apenas produzir a parte correspondente, sem introduzir novas linhas

Sei que grep -oposso fazer algo bastante semelhante, mas gera uma nova linha para cada correspondência, e a saída do meu comando também contém muitas novas linhas.

Exemplo:

input (saída do meu comando):

banana apple banana
apple bananas banned

expressão regular :

ban[a-z]*

saída porgrep -o :

banana
banana
bananas
banned

saída esperada :

bananabanana
bananasbanned

Uma coisa que posso sugerir é usar trpara substituir o caractere de nova linha por algum caractere que provavelmente não aparecerá na saída do comando, alimentar a saída para grep -oe, em seguida, usar trpara recuperar a nova linha.

mycommand|tr '\n' @|grep -o regex|tr -d '\n'|tr @ '\n'

No entanto, suponho que deve haver algumas soluções melhores. Qualquer ajuda seria apreciada.