Perguntas[bash](unix)

Tenho um pipeline usando array jobs e preciso alterar o número de entradas para algumas etapas. Pensei em testar, uniqjá que a única parte que muda nas minhas pastas são os últimos quatro caracteres (a parte hap no exemplo). Então, todos os meus caminhos parecem algo como:

/mnt/nvme/user/something1/hap1
/mnt/nvme/user/something1/hap2
/mnt/nvme/user/something2/hap1
/mnt/nvme/user/something2/hap2

e o que estou fazendo é o seguinte:

DIR=( "/mnt/nvme/ungaro/something1/hap1" "/mnt/nvme/ungaro/something1/hap2" "/mnt/nvme/ungaro/something2/hap1" "/mnt/nvme/ungaro/something2/hap2" )

for dir in "${DIR[@]}"; do echo $dir | sed 's#/hap[0-9]##' | uniq; done

Mas a saída resultante sempre exibe todos os elementos na variável sem recolher as linhas duplicadas após remover a parte hap de cada uma delas.

Provavelmente estou esquecendo de algo, poderia ser que as forforças imprimam todas as linhas de qualquer maneira. Se sim, há uma maneira de atingir o resultado desejado em um comando de linha única?

O manual do bash diz "O ambiente para qualquer comando ou função simples pode ser aumentado temporariamente prefixando-o com atribuições de parâmetros". Eu também entendo que variáveis ​​exportadas são passadas por padrão para subprocessos que o bash cria. Estou testando alguns comportamentos com variáveis ​​não exportadas, e o que eu não entendo é como isso funciona quando as atribuições são seguidas pelo operador ';', e então alguns outros comandos são executados.

Meu caso é o seguinte:

VAR=hello; echo $VARimprime "olá".

VAR=hello :; echo $VARimprime uma nova linha.

VAR=hello; echo $VAR; bash -c 'echo $VAR'imprime "olá" e uma nova linha.

A questão é, no primeiro e terceiro comando, por que VAR está sendo expandido? Eles são comandos diferentes, com (aparentemente) nenhuma atribuição de parâmetro prefixada.

PS: Tentei no bash 4.4.20 e 5.1.16 e o ​​comportamento foi o mesmo em ambos.

Eu mantenho uma extensão para o ambiente Bash chamada Basta . Basta fornece uma linha de status protegida por rolagem na parte inferior do seu terminal ANSI/VT100.

Quando o Basta se configura, o número efetivo de linhas, como conhecido pelo material termios no kernel e a LINESvariável shell diminui em 1. O redimensionamento do terminal é tratado bem. Quase. Há trapum SIGWINCHsinal para chamar a rotina de atualização, que também é chamada após cada comando, antes de retornar ao prompt.

No entanto, de vez em quando, vejo uma situação em que a região de rolagem é perdida. O prompt está sendo pintado sobre a linha inferior, onde o usuário está editando comandos e onde a saída do comando aparece, resultando em uma bagunça.

Tenho uma hipótese sobre como isso pode ocorrer, que tem etapas de reprodução confiáveis.

1. Executamos um programa que aguarda entrada, enquanto o Bash está em segundo plano, como cat.

2. Enquanto o programa estiver em execução, redimensionamos a janela para reduzi-la em uma linha.

3. Encerrar o catprograma.

Se o terminal for redimensionado enquanto catestiver em execução, o Bash não obtém o SIGWINCH(porque, eu acho, SIGWINCHé enviado apenas para os processos no grupo de processos em primeiro plano das sessões do terminal, e o Bash está em segundo plano naquele momento). Nosso trapnão executa.

A função de atualização do Basta também depende da comparação do tamanho do terminal anterior com o atual para detectar uma alteração de tamanho.

Aqui está o problema: nesta situação em que um terminal com um status protegido contra rolagem como encolheu em uma linha, o número de linhas parece não ter mudado .

Por exemplo, tela de 40 linhas com região de rolagem de 39 linhas: LINES=39. Redimensione o terminal para ter 39 linhas de comprimento. A região de rolagem desapareceu. LINES=39de novo. Para o software, parece o mesmo tamanho, então ele conclui que não houve um redimensionamento. A linha de status agora está sendo pintada sobre a linha inferior, sobre a entrada do usuário, porque Basta quer colocá-la na linha 40, que não existe mais, então o cursor se fixa em 39.

Se Basta souber que uma mudança de tamanho de janela ocorreu, ele não fará a comparação de tamanho; nessa situação, ele pega o caminho lento, pelo qual ele consulta o próprio terminal para determinar o tamanho. (Seria indesejável fazer isso para cada atualização, porque enviar consultas para o terminal é duvidoso. Se o usuário estiver digitando rapidamente, a resposta do terminal pode se misturar com suas teclas, e pode haver um atraso perceptível em obter uma resposta do terminal em conexões remotas lentas.)

Existe alguma maneira inteligente de saber se o terminal mudou (ou pelo menos suspeitar disso com uma taxa de falsos positivos razoavelmente baixa), na ausência de ter recebido a WINCHarmadilha, devido a ter estado em segundo plano, sem falar com o terminal?

A 'here string' ( <<<) é uma construção útil e pode ser usada em vez de echoem muitas situações. No entanto, ao calcular um hash (como um exemplo), a adição de um caractere de nova linha altera o valor do hash.

Procurei um método compacto para evitar que a quebra de linha fosse adicionada pela 'here string', mas não consegui encontrar nada. Esta pergunta foi feita e respondida no SO , mas estranhamente a resposta aceita (ou qualquer uma das respostas) não responde realmente à pergunta AFAICT.

Alguns podem considerar responder a essa pergunta com uma sugestão de simplesmente usar echo -n <string> | md5sumor printf ... | md5sumem vez disso. Mas minha pergunta diz respeito especificamente à 'string here'.

Reconheço que há perguntas superficialmente semelhantes feitas aqui antes, mas todas as que vi são mais simples do que o que estou tentando alcançar. Soluções somente Bash são preferidas.

Tenho uma variável contendo uma string que parece uma comparação de algum tipo, e gostaria de dividi-la em um array. A seguir estão alguns exemplos, incluindo como gostaria que fossem divididos:

var='name="value"'                # arr=([0]=name [1]='=' [2]=value)
var="name != '!value='"           # arr=([0]=name [1]='!=' [2]='!value=')
var='"na=me" = value'             # arr=([0]=na=me [1]='=' [2]=value)
var='name >= value'               # arr=([0]=name [1]='>=' [2]=value)
var='name'                        # arr=([0]=name)
var='name = "escaped \"quotes\""' # arr=([0]=name [1]='=' [2]=escaped\ \"quotes\")
var="name = \"nested 'quotes'\""  # arr=([0]=name [1]='=' [2]=nested\ \'quotes\')
var="name = 'nested \"quotes\"'"  # arr=([0]=name [1]='=' [2]=nested\ \"quotes\")

Você entendeu. Qualquer um dos lados (ou nenhum) pode ser citado, com aspas simples ou duplas. Pode haver aspas de escape ou aninhadas. O operador entre elas pode ser qualquer um de um conjunto predefinido, mas também pode ser incluído dentro das strings citadas. Pode haver ou não espaços. Pode não haver operador algum.

Tenho que analisar muitas linhas e, portanto, prefiro não bifurcar um novo processo a cada vez, e é por isso que soluções somente Bash são preferidas. Esta é uma adição a um script Bash existente que não precisa ser portátil para outros shells e está sendo executado no Bash 5.2, então tenho acesso a recursos Bash modernos que podem ser úteis.

IFS=\" read -a arr <<<"$var"é legal porque entende como lidar com aspas de escape, e se eu tivesse que lidar apenas com aspas simples ou duplas e não ambas , eu poderia fazer isso funcionar. Do jeito que está, só espero não ter que escrever um algoritmo tokenizador inteiro em script de shell, e que haja alguma combinação de recursos que eu não tenha considerado que possa analisar isso de forma confiável.

Estou tentando descompactar um arquivo em um script bash, mas recebo o erro "Falha de segmentação (core dumped)" após uma mensagem de saída repetida "Descompactar arquivos do agente".

Unzip agent files.
Unzip agent files.
Unzip agent files.
Unzip agent files.
Unzip agent files.
Unzip agent files.
Unzip agent files.
Unzip agent files.
Unzip agent files.
Unzip agent files.
Unzip agent files.
Unzip agent files.
Unzip agent files.
Segmentation fault (core dumped)

Veja o script abaixo:

cat /usr/local/bin/release-agent.sh
#! /bin/bash -e

source functions.sh

arg1=$1

check_arg (){
        if [[ -z ${arg1} ]]; then
                output "ERROR! Usage: Agent-unzip.sh [local zip file]..." red
                exit 0
        else
                arg=${arg1}
                if [[ ! -f ${arg} ]]; then
                        output "No local file found!" blue
                        exit 0
                else
                        file=${arg}
                        ext=${file##*.}
                        if [[ ${ext} != "zip" ]]; then
                                output "File specified does not appear to be a zip." red
                                confirm "Would you like to proceed."  #yes no question

                                if [[ $? == "1" ]]; then  #if no
                                        exit 0
                                fi
                        else
                                output "Local file, ${file} found." blue
                        fi
                fi
                zip="${file##*/}"
        fi
}


select_version (){
        prompt="Enter agent version number: "
        read -p "${prompt}" version

        while [ -z ${version} ]; do
                output "No input entered" red
                read -p "${prompt}" version
        done

        output "You entered: ${version}" blue
}

create_dir (){
        path="Agent/agent-${version}"
        output "Creating working directory ${path}" blue
        mkdir -p "${path}"
}

unzip (){
        output "Unzip agent files." blue
        unzip -uq "$zip" -d "${path}"
}

conf_details (){
        output "See details entered below:" blue
        output "VERSION = ${version}" green
        output "FILE PATH = ${zip}" green
        confirm "Would you like to proceed? press 'Y' to initiate the release of the agent image, press 'N' to edit any details:"  #yes no question
        if [[ $? != "0" ]]; then  #if anything but yes is returned
                $0 ${arg}
                exit 0
        fi
}

check_arg
select_version
conf_details
create_dir
unzip

## If script has't crashed out ##
output "Success! All operations completed" green
exit 0

A função de saída é apenas algo que escrevi para facilitar a saída. Veja abaixo como referência:

output() {
#
# Useage output "string" [colour] {flash}
#

if [[ $3 == "flash" ]]; then
        _blink=";5"
else
        _blink=""
fi

case $2 in
        grey)
                echo -e "\e[30;1${_blink}m${1}\e[0m"
                ;;
        red)
                echo -e "\e[31;1${_blink}m${1}\e[0m"
                ;;
        green)
                echo -e "\e[32;1${_blink}m$1\e[0m"
                ;;
        yellow)
                echo -e "\e[33;1${_blink}m$1\e[0m"
                ;;
        blue)
                echo -e "\e[34;1${_blink}m$1\e[0m"
                ;;
        magenta)
                echo -e "\e[35;1${_blink}m$1\e[0m"
                ;;
        lightblue)
                echo -e "\e[36;1${_blink}m$1\e[0m"
                ;;
        white)
                echo -e "\e[37;1${_blink}m$1\e[0m"
                ;;
        *)
                echo -e "\e[0mNo formatting option!"
                ;;
esac
}

...ou seja, há um meio pelo qual eu possa ler o comando completo que está sendo avaliado À MEDIDA que está acontecendo? Aqui está um exemplo artificial, mas que eu sinto que deixa a questão clara:

function showOwnEvaluation {
    local evaluatingCommand=????
    [[ "$evaluatingCommand" =~ ^showOwnEvaluation ]] && echo "Original Function"
}

alias sOE='showOwnEvaluation'

$ showOwnEvaluation 123
# Output: Original Function

$ sOE 123
# Output: 

Basicamente a habilidade de correr echo "$(!-1)"para o comando atual, ativo? Um echo "$(!0)", se preferir?

O que eu gostaria de fazer aqui é isto: se eu estiver atribuindo o resultado de uma expansão a uma variável:

someVar=$(myFunc)

...Eu gostaria de poder alterar a resposta com myFunc base no nome da variável para a qual ela está sendo definida . Eu simplesmente não consigo descobrir como obter a someVar=parte da expressão, se é que é possível FAZER tal coisa (sem aplicar uma emulação completa no terminal e monitorar todas as E/S, é claro).

Sei que isso pode parecer um desejo sem sentido, aqui, mas eu realmente tenho um caso de uso válido. Só não tenho certeza se é mesmo viável.

Estou usando Linux (Ubuntu) e Bash.

Eu fiz um programa simples em Go. Um for-loop literalmente infinito que imprime texto a cada 20 segundos.

package main

import (
    "fmt"
    "time"
)

func main() {
    for {
        fmt.Println("Hi from program 1")
        time.Sleep(time.Second * 20)
    }
}

Primeiro, registro uma armadilha para o SIGCHLDsinal usando o comando:

trap 'echo "hi you"' SIGCHLD

Em seguida, inicio um programa de forma assíncrona (em segundo plano) com:

./program &

Eu comecei como um trabalho de segundo plano para que o bash possa usar o terminal. Quando eu executo o comando:

kill -SIGSTOP process_id

a armadilha é acionada, e a mensagem "hi you" é exibida como esperado. No entanto, quando eu executo:

kill -SIGCONT process_id

para retomar o processo, o processo continua em execução (imprimindo "Hi from program 1"), mas a mensagem de trap ("hi you") não é exibida. Eu invoco esses killcomandos de outro terminal.

Encontrei na documentação do bash o seguinte:

Qualquer armadilha em SIGCHLD é executada para cada processo filho que sai.

Eu poderia entender como exclusivo. Em outras palavras, que a SIGCHLDarmadilha é ativada somente quando o processo filho sai. Se for assim, ficaria claro para mim por que meu exemplo não funciona. No entanto, a SIGCHLDarmadilha também é ativada quando o processo filho é suspenso.

Por que isso está acontecendo? Retomar o processo também gera um SIGCHLDsinal, então por que a armadilha não dispara nesse caso?

Pergunta relacionada .

Normalmente, podemos canalizar stdout para stdin da seguinte maneira:

echo "This is going to stdout" | grep -o going

Suponha que, em vez disso, grepeu escrevesse um script que lê tanto de stdin quanto de fd3 e, então, emite uma linha de stdin seguida de uma linha de fd3.

Existe alguma sintaxe que me permita configurar três processos A, B, C satisfazendo as seguintes condições?

• O stdout do Processo A foi para o stdin do Processo C.
• O stdout do Processo B foi para o FD 3 do Processo C.

No manual da rplopção -shabilite o modo dry-run, ou seja, ele simula as substituições sem alterar os arquivos reais.

Se eu tentar, obtenho a seguinte saída:

$ rpl --dry-run 'JLCPCB Part #' 'LCSC Part #' * 

rpl: Simulating replacement of "JLCPCB Part #" with "LCSC Part #" (case sensitive; partial words matched)

rpl: The files listed below would be modified in a replace operation
  /home/mark/Kicad/library/fmt_adc.kicad_sym
  /home/mark/Kicad/library/fmt_connectors.kicad_sym
  /home/mark/Kicad/library/fmt_device.kicad_sym
  /home/mark/Kicad/library/fmt_diodes.kicad_sym
  /home/mark/Kicad/library/fmt_interface.kicad_sym
  /home/mark/Kicad/library/fmt_modules.kicad_sym
  /home/mark/Kicad/library/fmt_power.kicad_sym
  /home/mark/Kicad/library/fmt_switches.kicad_sym
  /home/mark/Kicad/library/fmt_transistor.kicad_sym

rpl: 24 matches found in 9 out of 21 files

mas isso é bem inútil, já que não consigo ver as mudanças reais que ele vai fazer. Mesmo adicionando o sinalizador verbose não mostra as mudanças.

É uma maneira de habilitar um teste real? Minha saída esperada seria algo como:

old-text: ./fmt_adc.kicad_sym:70:       (property "JLCPCB Part #" "C84284"
new-text: ./fmt_adc.kicad_sym:70:       (property "LCSC Part #" "C84284"

e assim por diante.