kjo's questions

Quero obter o número de bytes e o sha1sum da saída de um comando.

Em princípio, sempre se pode fazer algo como:

BYTES="$( somecommand | wc -c )"
DIGEST="$( somecommand | sha1sum | sed 's/ .*//' )"

... mas, para o caso de uso no qual estou interessado, somecommandconsome bastante tempo e produz uma grande quantidade de resultados, então prefiro chamá-lo apenas uma vez.

Uma maneira que vem à mente seria algo como

evil() {
  {
    somecommand | \
      tee >( wc -c | sed 's/^/BYTES=/' ) | \
      sha1sum | \
      sed 's/ .*//; s/^/DIGEST=/'
  } 2>&1
}

eval "$( evil )"

...o que parece funcionar, mas me faz morrer um pouco por dentro.

Gostaria de saber se existe uma maneira melhor (mais robusta, mais geral) de capturar a saída de diferentes segmentos de um pipeline em variáveis ​​separadas.

EDIT: O problema no qual estou trabalhando no momento é em bash, então estou mais interessado em soluções para esse shell, mas também faço muita zshprogramação, então também tenho algum interesse nessas soluções.

EDIT2: Tentei portar a solução de Stéphane Chazelas para bash, mas não funcionou:

#!/bin/bash

cmd() {
    printf -- '%1000s'
}

bytes_and_checksum() {
    local IFS
    cmd | tee >(sha1sum > $1) | wc -c | read bytes || return
    read checksum rest_ignored < $1 || return
}

set -o pipefail
unset bytes checksum
bytes_and_checksum "$(mktemp)"
printf -- 'bytes=%s\n' $bytes
printf -- 'checksum=%s\n' $checksum

Quando executo o script acima, a saída que recebo é

bytes=
checksum=96d89030c1473585f16ec7a52050b410e44dd332

O valor de checksumestá correto. Não consigo entender por que o valor de bytesnão está definido.

EDIT3: OK, graças à dica do @muru, resolvi o problema:

#!/bin/bash

cmd() {
    printf -- '%1000s'
}

bytes_and_checksum() {
    local IFS
    read bytes < <( cmd | tee >(sha1sum > $1) | wc -c ) || return
    read checksum rest_ignored < $1 || return
}

set -o pipefail
unset bytes checksum
bytes_and_checksum "$(mktemp)"
printf -- 'bytes=%s\n' $bytes
printf -- 'checksum=%s\n' $checksum

Agora:

bytes=1000
checksum=96d89030c1473585f16ec7a52050b410e44dd332

INFELIZMENTE ...

... minha bytes_and_checksumfunção para (impasse?) quando cmdproduz muito mais saída do que no meu exemplo de brinquedo acima.

De volta à prancheta...

Muitas vezes me pego escrevendo funções de shell ou scripts de shell que devem ser wrappers em torno de outros comandos.

Também é frequente que eu queira que tal wrapper suporte alguns sinalizadores/opções. A ideia é que o wrapper deve selecionar dos argumentos da linha de comando todos os sinalizadores/opções que ele suporta (junto com seus argumentos, quando aplicável) e passar os argumentos restantes como argumentos para o comando agrupado.

Agora, na maioria das vezes, o comando wrap também oferece suporte a sinalizadores e opções próprias. Isso significa que, de acordo com o esquema descrito acima, o wrapper deve ser capaz de lidar com argumentos de linha de comando que incluam seus próprios sinalizadores/opções, bem como aqueles suportados pelo comando wrapper.

Uma maneira de implementar tal wrapper seria especificar as opções do wrapper e do comando wrapper em uma chamada para GNU getopt, então coletar todas as últimas, juntamente com quaisquer argumentos sem opção, em algum array WRAPPED_COMMAND_ARGUMENTS. Então, em algum momento posterior, o comando agrupado é invocado com "${WRAPPED_COMMAND_ARGUMENTS[@]}"seus argumentos de linha de comando.

Essa abordagem funcionou razoavelmente bem para mim, mas torna-se proibitivamente trabalhosa quando o comando wrap tem muitas opções.

Em vez disso, gostaria de descobrir o que no título deste post me refiro como uma "alternativa permissiva ao GNU getopt". Com isso, quero dizer uma ferramenta que, como getopt, me ajuda a analisar as opções sobre as quais falo explicitamente e trata todos os outros argumentos restantes igualmente, ou seja, não faz distinção com base na presença ou não de hífens à esquerda.

Existe uma coisa dessas?

bashavalia a seguinte expressão sem qualquer objeção:

declare -A SPANISH=( [rojo]=red [verde]=green [azul]=blue )

...mas não gosta nem um pouco disso:

declare -A SPANISH=( $( echo "[rojo]=red [verde]=green [azul]=blue" ) )
bash: SPANISH: $( echo "[rojo]=red [verde]=green [azul]=blue" ): must use subscript when assigning associative array

Eu tentei muitas variações, mas o resultado é sempre uma ou mais instâncias do must use subscript when assigning associative arrayerro mostrado acima.

Este exemplo é bobo, claro. Seu único propósito é ilustrar o problema de inicializar um array associativo bash usando uma substituição de comando .

Isso pode ser feito?

Para ser concreto, e continuar com o exemplo bobo acima, o que seria um comando <COMMAND>tal que

declare -A SPANISH=( $( <COMMAND> ) )

...produz o mesmo resultado final que o produzido por

declare -A SPANISH=( [rojo]=red [verde]=green [azul]=blue )

acima?

Aliás, zshlida com esta situação sem nenhum problema:

$ declare -A SPANISH=( $( echo "rojo red verde green azul blue" ) )
$ echo "${SPANISH[azul]}"
blue

O título do tópico praticamente diz tudo.

Quando pesquisei essa questão no Google, encontrei menções a um programa chamado unticque supostamente faz o que eu quero fazer, mas esse programa não parece estar disponível em nenhum dos pacotes oficiais da minha distro (Debian).

Existe alguma outra maneira de ir de terminfo (compilado) para termcap?

Acabei de comprar uma unidade USB externa de 5 TB.

Isto é o que lsblkmostra para ele:

% lsblk --output=NAME,FSTYPE,LABEL,SIZE /dev/sdd
NAME   FSTYPE LABEL                   SIZE
sdd                                   4.6T
├─sdd1                                128M
└─sdd2 ntfs   Seagate Portable Drive  4.6T

Entendo que a pequena partição de 128M abaixo /dev/sdd1é uma partição "Microsoft Reserved" (MSR) e que não é necessária para um sistema Linux como o meu.

Eu gostaria de ter todo o espaço disponível no disco em uma única partição.

Existe uma maneira simples, na linha de comando do Unix, de consolidar ambas as partições em uma única?

(Se isso exigir reformatação, posso acrescentar que não ligo para ntfs; ext4 seria minha preferência.)

Recentemente me deparei com a seguinte declaração ( fonte ; ênfase adicionada):

Para scripts de shell, o uso de guias não é uma questão de preferência ou estilo; é como a linguagem é definida .

Estou tentando entender essa afirmação. Claro, é um pouco vagamente formulado ¹ , mas eu gostaria de saber se há alguma verdade nisso.

Em particular, gostaria de saber se a documentação oficial para bash ou zsh (os dois shells para os quais escrevo scripts rotineiramente) diz algo que se aproxime de um mandato ou recomendação para usar guias para recuar o código-fonte. (Agradeceria referências explícitas aos parágrafos de apoio nesta documentação.)

(FWIW, deixe-me salientar que estou ciente do fato de que, na prática, tanto o bash quanto o zsh interpretam prontamente scripts que não são indentados exclusivamente com guias. Portanto, não espero que a documentação de qualquer shell vá muito além do que uma recomendação forte, se eles mencionarem o assunto.)

^{1 Por um lado, refere-se simultaneamente a "scripts de shell" e "a linguagem", o que contradiz os fatos de que existem vários shells em uso atual, cada um definindo sua própria linguagem.}

Para o bem desta questão, suponha que o glob /a/b/c/*não produz correspondências.

Isso significa que o teste a seguir deve falhar (em outras palavras, deve produzir um diferente de zero $?):

[[ -n /a/b/c/*(#qN) ]]

Este é de fato o caso se eu executar o teste diretamente na linha de comando (zsh). No entanto, se eu fizer exatamente o mesmo teste em um script, ele será bem-sucedido, o que não é o comportamento pretendido.

Se eu executar o mesmo script com o -xsinalizador, o rastreamento resultante mostra o teste como

[[ -n '/a/b/c/*(#qN)' ]]

Não entendo por que as aspas simples aparecem em torno do argumento de test; no código-fonte do script não há aspas.

Se o zsh inserir automaticamente essas aspas simples, isso explicaria por que o texto foi bem-sucedido.

Perguntas:

1. por que há uma diferença entre as versões de linha de comando e de script dessa expressão?
2. o que preciso fazer para que o teste (corretamente) falhe quando estiver no script?

Eu quero construir uma versão de algum software que seja mais recente do que a que está atualmente disponível como um pacote Debian de lançamento estável.

Para fazer isso, no entanto, além de usar uma versão mais recente do código-fonte, gostaria de seguir, o mais próximo possível, o procedimento de compilação que foi usado para compilar o pacote Debian para este software na versão estável.

No mínimo, gostaria de especificar os mesmos sinalizadores de configuração e os mesmos valores para variáveis ​​de ambiente relevantes durante a compilação, como foi feito para o pacote Debian de versão estável para este software.

P: Como posso encontrar o procedimento de compilação para um pacote Debian específico (versão estável)?

As instruções-chave no trecho abaixo (ou seja, além daquelas para imprimir etiquetas e linhas em branco, para espaçamento) vêm em pares. Em cada par, a primeira e a segunda declarações têm as formas tty...e echo $(tty...), respectivamente.

echo stdin:
tty
echo $(tty)

echo

echo stdout:
tty <&1
echo $(tty <&1)

echo

echo stderr:
tty <&2
echo $(tty <&2)

Se eu originar um arquivo contendo este trecho (em uma sessão zshou bash, por exemplo), recebo a seguinte saída ¹ (adicionei os números de linha posteriormente, para referência):

 1    stdin:
 2    /dev/pts/8
 3    /dev/pts/8
 4    
 5    stdout:
 6    /dev/pts/8
 7    not a tty
 8    
 9    stderr:
10    /dev/pts/8
11    /dev/pts/8

Nesta saída, a linha gerada por echo $(tty <&1)(linha 7) se destaca visivelmente, por dois motivos:

1. é a única entre as echo $(tty ...)linhas -geradas (ou seja, as linhas 3, 7 e 11) que difere de sua tty ...contraparte -gerada, imediatamente anterior (linhas 2, 6 e 10); e
2. ele difere da saída (linha 11) do formalmente análogo echo $(tty <&2).

P: Como essas duas discrepâncias são explicadas?

Para o registro, tentei encontrar a explicação para essas aparentes anomalias na página de manual para tty, mas, até onde posso dizer, esta página não aborda essas questões ² ; certamente não explicitamente ³ .

Esta pergunta foi motivada por alguns do código esta grande resposta a uma pergunta anterior minha.

^{1 Claro, o número real depois /dev/pts/será diferente se eu mudar de terminal e provavelmente será diferente para você se você tentar a mesma coisa.}

^{2 Na verdade, toda a seção DESCRIÇÃO da ttypágina de manual disponível em meu sistema consiste em apenas uma frase: "Imprima o nome do arquivo do terminal conectado à entrada padrão.".}

^{3 Aqui estou deixando em aberto a possibilidade de que alguém com mais conhecimento prévio do que eu possa deduzir da ttypágina concisa do manual do comportamento ilustrado acima.}

Eu gostaria de implementar um zshscript que se comporte de maneira diferente dependendo se foi invocado diretamente na CLI do shell ou não.

A princípio pensei que o script poderia fazer isso procurando ino valor de $-, mas me enganei.

Na verdade, quando executo o script abaixo na linha de comando

#!/bin/zsh
printf -- '%s\n' "$-"

...a saída que recebo não inclui i¹ .

Existe alguma outra maneira para o meu script de shell descobrir essas informações?

NB: Embora eu esteja trabalhando em um zshroteiro no momento, eu também gostaria de saber qual seria a resposta para um bashroteiro. Se a resposta depende do OS, estou interessado principalmente em Linux e Darwin.

^{1 A saída do script é 569X, se alguém quiser saber.}

Até onde eu sei, parte da saída gerada pelo comando /usr/bin/modulecmdnão vai para stdout nem stderr, conforme ilustrado pelo exemplo a seguir:

% /usr/bin/modulecmd bash help null >/dev/null 2>&1
        This module does absolutely nothing.
        It's meant simply as a place holder in your
        dot file initialization.

        Version 3.2.9

Existe alguma maneira de invocar um comando (como /usr/bin/modulecmd) para que toda a sua saída vá para stdout ou stderr? Como alternativa, existe alguma maneira de o código que invoca /usr/bin/modulecmdcapturar toda a saída que normalmente enviaria para o terminal?

É possível limitar os processos de um usuário específico para sempre serem executados com uma gentileza de pelo menos 15, digamos?

Em um cluster compartilhado em que trabalho, as configurações de ambiente para novas contas não incluem uma configuração de prompt, até onde sei. Em particular, PS1não está definido. E, no entanto, quando alguém faz login em uma nova conta, recebe um prompt bastante sofisticado, apresentando o nome de usuário e o nome base do diretório atual.

Eu quero salvar este prompt (por exemplo, em uma variável de ambiente como ORIGINAL_PS1) antes de substituí-lo pelo meu prompt preferido, para que eu possa restaurá-lo mais tarde, se desejado ¹ .

Como posso extrair a definição de prompt do prompt atual?

Estou principalmente interessado na resposta a esta pergunta para bash, mas se houver algo análogo para zsh, informe-me.

^{1 Eu gosto do prompt padrão, mas para uso diário prefiro usar um gitprompt "-aware". Dito isso, embora eu ache o último extremamente útil 99,999% do tempo, ocasionalmente eu vou cdpara um gitrepositório que está tão bagunçado que faz com que a geração do prompt se torne inaceitavelmente lenta. Para essas raras circunstâncias, eu gostaria de poder executar export PS1=$ORIGINAL_PS1.}

A intenção do script de teste ¹ abaixo é iniciar um coprocesso "externo" (executando seq 3), ler desse coprocesso em um while-loop e, para cada linha lida, imprimir uma linha identificando a iteração atual do loop externo, iniciar um " internal" (também executando seq, com novos argumentos), leia esse coprocesso interno em um loop while aninhado e, em seguida, limpe esse coprocesso interno. O laço while aninhado imprime alguma saída para cada linha que lê do coprocesso interno.

#!/bin/bash
# filename: coproctest.sh
PATH=/bin:/usr/bin

coproc OUTER { seq 3; }
SAVED_OUTER_PID="${OUTER_PID}"

exec {OUTER_READER}<&"${OUTER[0]}"
while IFS= read -r -u "${OUTER_READER}" OUTER_INDEX; do

    printf -- '%d\n' "${OUTER_INDEX}"

    START=$(( OUTER_INDEX * 1000000 ))
    FINISH=$(( START + OUTER_INDEX ))

    # (
      coproc INNER { seq "${START}" "${FINISH}"; }
      SAVED_INNER_PID="${INNER_PID}"
      exec {INNER_READER}<&"{INNER[0]}"

      while IFS= read -r -u "${INNER_READER}" INNER_INDEX; do
          printf -- '    %d\n' "${INNER_INDEX}"
      done

      exec {INNER_READER}<&-

      wait "${SAVED_INNER_PID}"
    # )

done
exec {OUTER_READER}<&-
wait "${SAVED_OUTER_PID}"

Quando executo este script, esta é a saída que recebo:

% ./coproctest.sh
1
./coproctest.sh: line 30: warning: execute_coproc: coproc [12523:OUTER] still exists
./coproctest.sh: line 19: INNER_READER: ambiguous redirect
./coproctest.sh: line 21: read: : invalid file descriptor specification
./coproctest.sh: line 25: INNER_READER: ambiguous redirect
2
./coproctest.sh: line 19: INNER_READER: ambiguous redirect
./coproctest.sh: line 21: read: : invalid file descriptor specification
./coproctest.sh: line 25: INNER_READER: ambiguous redirect
3
./coproctest.sh: line 19: INNER_READER: ambiguous redirect
./coproctest.sh: line 21: read: : invalid file descriptor specification
./coproctest.sh: line 25: INNER_READER: ambiguous redirect

Eu recebo praticamente a mesma saída se eu descomentar as duas linhas comentadas.

Q1: É possível ter vários coprocessos em execução ao mesmo tempo?

Q2: Em caso afirmativo, como o script acima deve ser modificado para obter a saída desejada?

^{1 Só recentemente comecei a trabalhar com coprocessos, e ainda tem muita coisa que não entendo. Como resultado, esse script quase certamente contém código incorreto, estranho ou desnecessário. Sinta-se à vontade para comentar e/ou corrigir esses pontos fracos em suas respostas.}

Por exemplo, se eu atribuir

TWO=2

...o seguinte falha (com date: invalid date '2'):

date >> logfile $TWO>&1

Claro, eu sempre posso fazer

eval "date >> logfile $TWO>&1"

Essa é a única maneira de executar expressões que incluem redirecionamentos de fluxo em que pelo menos alguns dos descritores de arquivo aparecem como variáveis?

Com zsheu posso fazer isso para excluir todos os aliases:

% unalias $( alias + )

Estou procurando o equivalente em bash.

A modulefunção do pacote Environment Modules ¹ faz seu trabalho modificando várias variáveis ​​de ambiente do processo shell atual .

Infelizmente, essa função retorna 0 se for bem-sucedida ou não ² , o que torna difícil para um script de cliente responder adequadamente a falhas.

Eu gostaria de implementar um wrapper de função mymoduleque modulepassa todos os seus argumentos diretamente para modulee retorna corretamente um valor diferente de zero se modulefalhar.

A única maneira de mymoduledetectar se modulefalhou é inspecionar a função de saída modulegrava em stderr, se houver.

O problema é que não consigo encontrar uma maneira razoável mymodulede obter essa saída sem anular moduleas ações de . Mais especificamente, quase todas as maneiras em que posso pensar para capturar moduleo stderr de 's em uma variável envolvem a execução moduleem um processo filho, impedindo-o de fazer seu trabalho (o que requer a modificação do shell atual).

A única exceção ao acima seria redirecionar moduleo stderr de 's para um arquivo temporário, mas eu odeio a ideia de criar um arquivo toda vez que a modulefunção for executada.

Existe alguma maneira de mymoduleinvocar moduleno ambiente atual e ao mesmo tempo capturar seu stderr em uma variável?

Estou interessado em respostas para ambos zshe bash.

^{1 Não confundir com o pacote de módulos de ambiente Lmod , que possui uma interface muito semelhante.}

^{2 Pelo menos este é o caso da versão antiga 3.2.9 com a qual devo trabalhar. Eu não tenho controle sobre isso.}

O script abaixo é uma ilustração mínima (embora artificial) do problema.

## demo.sh

exitfn () {
    printf -- 'exitfn PID: %d\n' "$$" >&2
    exit 1
}

printf -- 'script PID: %d\n' "$$" >&2

exitfn | :

printf -- 'SHOULD NEVER SEE THIS (0)\n' >&2

exitfn

printf -- 'SHOULD NEVER SEE THIS (1)\n' >&2

Neste script de exemplo, exitfnrepresenta uma função cujo trabalho envolve encerrar o processo atual ¹ .

Infelizmente, conforme implementado, exitfnnão cumpre essa missão de forma confiável.

Se alguém executar este script, a saída será assim:

% bash ./demo.sh
script PID: 26731
exitfn PID: 26731
SHOULD NEVER SEE THIS (0)
exitfn PID: 26731

(Claro, o valor mostrado para PID será diferente com cada chamada.)

O ponto-chave aqui é que, na primeira invocação da exitfnfunção, o exit 1comando em seu corpo falha ao encerrar a execução do script de inclusão (como evidenciado pela execução do primeiro printfcomando imediatamente a seguir). Em contraste, na segunda invocação de exitfn, esse exit 1comando encerra a execução do script (como evidenciado pelo fato de que o segundo printfcomando não é executado).

A única diferença entre as duas invocações de exitfné que a primeira ocorre como o primeiro componente de um pipeline de dois componentes, enquanto a segunda é uma chamada "independente".

Estou intrigado com isso. Eu esperava que exitisso tivesse o efeito de matar o processo atual (ou seja, aquele com PID fornecido por $$). Obviamente, isso nem sempre é verdade.

Seja como for, existe uma maneira de escrever exitfnpara que ele saia do script ao redor, mesmo quando invocado em um pipeline?

Aliás, o script acima também é um script zsh válido e produz o mesmo resultado:

% zsh ./demo.sh
script PID: 26799
exitfn PID: 26799
SHOULD NEVER SEE THIS (0)
exitfn PID: 26799

Eu estaria interessado na resposta a esta pergunta para zsh também.

Finalmente, devo salientar que implementar exitfnassim não funciona:

exitfn () {
    printf -- 'exitfn PID: %d\n' "$$" >&2
    exit 1
    kill -9 "$$"
}

...porque, em todas as circunstâncias, o exit 1comando é sempre a última linha daquela função que é executada. ( Substituir exit 1 por kill -9 $$não é aceitável: quero controlar o status de saída do script e sua saída para stderr.)

^{1 Na prática, essa função executaria outras tarefas, como log de diagnóstico ou operações de limpeza, antes de encerrar o processo atual.}

Esta questão é sobre a maneira correta de escrever literais de expressão regular em uma expressão de correspondência no bash.

Em zsh, a correspondência abaixo é bem-sucedida, como eu esperava:

% [[ ' 123 ' =~ '^ [0-9]+ $' ]]; echo $?
0

Não é assim no bash:

$ [[ ' 123 ' =~ '^ [0-9]+ $' ]]; echo $?
1

Eu sei que este jogo tem sucesso no bash

$ ( regexp='^ [0-9]+ $'; [[ ' 123 ' =~ $regexp ]]; echo $? )
0

...mas requer atribuir a expressão regular a uma variável intermediária.

Minha pergunta é: Como se escreve um literal de expressão regular arbitrária em uma expressão de correspondência no bash?

A sequência de comandos

mkdir -p BASE/a/b/c && cp -a --target-directory=BASE/a/b/c /a/b/c/d

cria um subdiretório a/b/cem BASEe copia a árvore de diretórios em /a/b/c/dpara BASE/a/b/c.

Um problema é que envolve muita repetição, o que convida a erros.

Posso rolar uma função de shell que encapsula essa operação; por exemplo, aqui está um esboço dele sem nenhuma verificação/manipulação de erros:

copytwig () {
    local source=$1
    local base=$2
    local target=$base/$( dirname $source )

    mkdir -p $target && cp -a --target-directory=$target $source
}

...mas eu queria saber se isso já poderia ser feito com um utilitário Unix "padrão" (onde estou usando "padrão" como abreviação de "provavelmente encontrado em um sistema Unix, ou pelo menos provável de ser encontrado em um sistema Linux").