Yakog's questions

Estou usando Ubuntu 22.04.5 LTSo sistema operacional e a seguinte versão do bash:

GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)

Encontrei o seguinte em "man bash" na seção INVOCATION:

Quando o bash é invocado como um shell de login interativo, ou como um shell não interativo com a opção --login , ele primeiro lê e executa comandos do arquivo /etc/profile, se esse arquivo existir. Depois de ler esse arquivo, ele procura por ~/.bash_profile, ~/.bash_login e ~/.profile, nessa ordem, e lê e executa comandos do primeiro que existe e é legível.

Eu sei que o bash pode ser "login" de duas maneiras:

1. o argumento zero tem um traço antes do nome ( -bash)
2. O bash é iniciado com o --loginsinalizador/opção.

Em "man bash" eles claramente marcaram apenas o segundo caso (se quisessem marcar os dois casos, eles colocariam "non-interactive login shell"; Stephen Kitt também disse em sua resposta que isso se aplica apenas ao segundo caso). Isso significa que se eu iniciar o login bash não interativo da primeira maneira, os comandos do ~/.profilearquivo não devem ser executados. No entanto, esse não é o caso. Adicionei echo HIao arquivo fornecido e executei o seguinte comando no emulador de terminal GNOME ( /dev/pts/0) para iniciar o login bash não interativo:

exec -l bash -c 'echo $-;echo $0;shopt;sleep 10s'

O texto ("HI") é exibido no terminal, embora não devesse, de acordo com o manual.

Por que isso está acontecendo?

Encontrei uma resposta potencial para minha pergunta aqui . Parece que no meu caso essa opção de tempo de compilação não está comentada, então o bash lê o arquivo "~/.profile". Alguém sabe como verificar se essa opção realmente não está comentada?

Encontrei o seguinte man bashcomo definição de shell interativo:

Um shell interativo é aquele iniciado sem argumentos não opcionais (a menos que -s seja especificado) e sem a opção -c cuja entrada padrão e erro são ambos conectados a terminais (conforme determinado por isatty(3)), ou um iniciado com a opção -i. PS1 é definido e $- inclui i se o bash for interativo, permitindo que um script de shell ou um arquivo de inicialização teste esse estado.

Então, shell interativo é aquele que:

1. não tem argumentos não opcionais (a menos -sque seja especificado), não tem -copção e cuja entrada padrão e erro estão conectados ao terminal; ou
2. tem -iopção

Eu escrevi o seguinte exemplo:

bash << EOF
echo '$-'
EOF

e fornece a seguinte saída:

himBHs

Então, parece que é um shell interativo (ele tem i). No entanto, não está claro para mim como ele pode ser interativo quando a entrada padrão não é um terminal neste caso... O seguinte está escrito na documentação para este tipo de redirecionamento ( here documents):

Este tipo de redirecionamento instrui o shell a ler a entrada da fonte atual até que uma linha contendo apenas delimitador (sem espaços em branco à direita) seja vista. Todas as linhas lidas até esse ponto são então usadas como a entrada padrão (ou descritor de arquivo n se n for especificado) para um comando.

Ele diz que a entrada padrão são todas as linhas lidas até o delimitador (eu assumo que elas são então passadas para o comando redirecionando a entrada padrão do comando para um pipe ou algo assim). Portanto, a entrada padrão não é (conectada a) um terminal.

Por que isso está acontecendo? Por que o bash é interativo nesse caso?

Estou usando Linux e a seguinte versão do bash:

GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)

Quando eu digito:

echo file{[1,2],3}.txt

Espero que a expansão do suporte seja feita primeiro, então:

echo file[1,2].txt file3.txt

Depois disso, espero que pare por aí, já que [1,2] não é um globbing válido. No entanto, ele fornece o seguinte como saída:

file[1.txt file2].txt file3.txt

Por que?

Lista de arquivos no diretório atual (resultado do lscomando):

go.mod  hello.sh  hi  main.go

Estou usando o bash, versão:

GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)

Fiz o seguinte script:

#!/usr/bin/bash

a=11
b=4
c=7+b

if [[ a -eq c ]]
then
    echo "ok"
else 
    echo "not ok"
fi

Ele imprime "ok". Quando eu mudo apara 10, ele imprime "não ok". Então eu tenho uma pergunta simples, do [[ ]]e (( ))makes "avaliação transitiva" (no meu exemplo, isso significaria cprimeiro avalia para 7+be então bavalia para 4e finalmente ele se torna 11)?

Pergunto porque tenho uma "briga" séria com IAs (chatGPT, gemini, claude), onde dizem que esse tipo de avaliação não acontece, mas meus exemplos mostram o contrário (dizem que cé avaliado para 7+b, e como não é um número, o valor 0é tomado)... Obrigado antecipadamente

Estou usando Linux (Ubuntu).

Quando digito man 7 signal(manual 2020-12-21) no meu terminal, encontro o seguinte para o SIGCHLD:

SIGCHLD      P1990      Ign     Child stopped or terminated

Então, ele afirma que o SIGCHLDsinal é gerado somente nesses dois casos. Ele não diz nada sobre quando o processo filho continua.

Entretanto, no POSIX, é afirmado o seguinte:

SIGCHLD Child process terminated, stopped,

[XSI] or continued.

Assim, quando o SO suporta XSI, esse sinal também é gerado quando o filho continua. Eu também escrevo alguns programas filho/pai simples e posso confirmar isso. Já que o Linux suporta XSI, por que o manual não inclui o cenário "continue" para o SIGCHLD também? Qual é o propósito do manual quando ele está incompleto (ou estou perdendo seu propósito?)

Também encontrei as seguintes respostas para SIGCHLD incompletas.

Abaixo está o código. É um código golang simples. O pai inicia o filho por meio do clássico fork/exec. Ele então registra um manipulador para o sinal SIGCHLD e pronto. Tanto o pai quanto o filho imprimem uma mensagem a cada 10 segundos. Depois de construir os dois programas, eu os executo via ./parentcomando. Eu controlo o comportamento ( T<-> R/Sestado) do processo filho por meio de kill -SISTOP child_process_idand kill -SIGCONT child_process_id.

Pai:

package main

import (
    "fmt"
    "os"
    "os/signal"
    "syscall"
    "time"
)

func main() {
    attr := &syscall.ProcAttr{
        Files: []uintptr{0, 1, 2},
    }

    _, err := syscall.ForkExec("./child/child", []string{"child"}, attr)
    if err != nil {
        fmt.Println("Error:", err)
        return
    }

    ch := make(chan os.Signal, 1)
    signal.Notify(ch, syscall.SIGCHLD)

    go func() {
        for {
            select {
            case <-ch:
                fmt.Println("SIGNAL")
            }
        }
    }()

    for {
        fmt.Println("Parent is live")
        time.Sleep(10 * time.Second)
    }
}

Criança:

package main

import (
    "fmt"
    "time"
)

func main() {
    for {
        fmt.Println("hi from child")
        time.Sleep(time.Second * 10)
    }
}

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 .

Estou usando Ubuntu (Linux).

Tenho os dois programas simples a seguir.

Pai:

package main

import (
    "fmt"
    "syscall"
    "time"
)

func main() {
    attr := &syscall.ProcAttr{
        Files: []uintptr{0, 1, 2},
        Sys: &syscall.SysProcAttr{ // child in its own group
            Setpgid: true,
            Pgid:    0,
        },
    }

    _, err := syscall.ForkExec("./child/child", []string{"child"}, attr)
    if err != nil {
        fmt.Println("Error:", err)
        return
    }

    for {
        fmt.Println("Parent is live")
        time.Sleep(10 * time.Second)
    }
}

Criança (criança em seu próprio grupo):

package main

import (
    "fmt"
    "time"
)

func main() {
    for {
        fmt.Println("hi from child")
        time.Sleep(time.Second * 20)
    }
}

Após iniciar o programa pai ( ./parent), o resultado da chamada do comando ps(especificamente, ps -t /dev/pts/0 -o pid,ppid,pgid,stat,comm) é o seguinte:

    PID    PPID    PGID STAT COMMAND
 466922  466896  466922 Ss   bash
 467049  466922  467049 Sl+  parent
 467054  467049  467054 Sl   child

Após terminar o processo pai (com kill -SIGKILL 467049, kill -SIGINT 467049ou CTRL-C), o filho continua a trabalhar (estado S/R). É exatamente isso que eu espero.

    PID    PPID    PGID STAT COMMAND
 466922  466896  466922 Ss+   bash
 467054  467049  467054 Sl   child

O que me confunde é o seguinte cenário. Primeiro, eu inicio o processo pai ( ./parent). O resultado do pscomando é o mesmo do caso anterior. Então eu suspendo o processo filho com kill -SIGTSTP 467054ou kill -SIGSTOP 467054. O resultado do pscomando é o seguinte:

    PID    PPID    PGID STAT COMMAND
 466922  466896  466922 Ss   bash
 467049  466922  467049 Sl+  parent
 467054  467049  467054 Tl   child

Então, eu termino o processo pai (com kill -SIGKILL 467049, kill -SIGINT 467049ou CTRL-C). Por alguma razão, neste caso o filho também é terminado! Resultado do pscomando:

    PID    PPID    PGID STAT COMMAND
 466922  466896  466922 Ss+   bash

Como? Por quê?

Quais são exatamente os passos desde o momento em que inicio o pseudoterminal (CTRL+ALT+T) até o momento em que o shell começa a escutar a entrada do teclado?

Eu sei que isso acontece basicamente da seguinte maneira: o processo do terminal chama dev/pts/ptmx, então o lado escravo é criado (por exemplo /dev/pts/0) e então o processo do terminal se bifurca (eu acho?), configura uma sessão e executa o shell.

No entanto, estou curioso para saber exatamente como isso funciona.

O que mais me confunde nesse procedimento é o seguinte:

1. Achei que meu emulador de terminal (pseudo-terminal) é, xterm-256colorjá que é isso que eu recebo quando digito echo $TERM. Então, xtermchamaria ptmx. No entanto, quando verifico o PPID do shell (bash), na verdade é /usr/libexec/gnome-terminal-server. Então, estou confuso, qual é a diferença entre esses dois? xtermPrimeiro bifurca/exec /usr/libexec/gnome-terminal-servere depois chama ptmxe depois bifurca/exec o shell, ou o quê?
2. Eu pensei que a sessão fosse algo exclusivamente vinculado ao terminal. Ou seja, cada terminal tem apenas uma sessão e pronto. No entanto, quando eu investiguei mais a fundo, descobri que é "coisa do kernel" e que cada processo tem uma sessão, incluindo /usr/libexec/gnome-terminal-server. Por que ele então cria uma nova sessão para o bash e não usa apenas a do bash, /usr/libexec/gnome-terminal-serverjá que isso é, na verdade, um terminal?
3. Como ele /usr/libexec/gnome-terminal-serversabe qual shell iniciar/executar (no meu caso bash)? Ele lê de algum lugar, posso mudar isso?

Estou curioso para saber exatamente como essas etapas funcionam.

Obrigado

Tenho os dois programas simples a seguir.

Pai:

package main

import (
    "fmt"
    "syscall"
)

func main() {
    attr := &syscall.ProcAttr{
        Files: []uintptr{0, 1, 2},
        Sys: &syscall.SysProcAttr{ // child in its own group
            Setpgid: true,
            Pgid:    0,
        },
    }

    _, err := syscall.ForkExec("./child/child", []string{"child"}, attr)
    if err != nil {
        fmt.Println("Error:", err)
        return
    }
}

Criança:

package main

import (
    "fmt"
    "time"
)

func main() {
    for {
        fmt.Println("hi from child")
        time.Sleep(time.Second * 5)
    }
}

Saída do ps:

yakog@yakog-computer:~/goprojects/parent$ ps -o pid,ppid,pgid,uid,wchan,stat,tt,command -t /dev/pts/19
    PID    PPID    PGID   UID WCHAN  STAT TT       COMMAND
1867701 1867320 1867701  1000 do_sel Ss+  pts/19   bash
1870508    2118 1870508  1000 ep_pol Sl   pts/19   child

Quando pressiono CTRL-Zou CTRL-C, não tem efeito algum. É exatamente o que eu esperava, já que o processo 1870508 não faz parte do trabalho de primeiro plano e CTRL-Z/ CTRL-Cinvoca kill -SIGTSTP -1867701/ kill -SIGINT -1867701. Portanto, 1870508 não recebe esses sinais.

Além disso, quando invoco kill -SIGINT 1870508ou kill -SIGSTOP 1870508, o processo é encerrado/suspenso. Ainda consigo entender. Embora 1870508 não faça parte do trabalho em primeiro plano, com killo comando enviamos "diretamente" o sinal para o processo .

No entanto, por que kill -SIGTSTP 1870508não funciona? Após iniciar o ./parentprocesso e chamar kill -SIGTSTP 1870508o comando, literalmente nada acontece (o 1870508 ainda tem status R/ Se continua a imprimir no terminal). Não consigo entender por que ele não suspendeu o processo (o moveu para T). Deve ser o mesmo que com -SIGINTe -SIGSTOP( nós enviamos "diretamente" -SIGTSTP para o processo ), no entanto, não tem efeito neste caso.

O estranho é que se alterarmos o código pai (código abaixo) e fizermos com que ele continue a execução após a criação do filho, ele kill -SIGTSTP 1870508funcionará como deveria (o filho será suspenso).

package main

import (
    "fmt"
    "os/signal"
    "syscall"
    "time"
)

func main() {
    attr := &syscall.ProcAttr{
        Files: []uintptr{0, 1, 2},
        Sys: &syscall.SysProcAttr{ // child in its own group
            Setpgid: true,
            Pgid:    0,
        },
    }

    _, err := syscall.ForkExec("./child/child", []string{"child"}, attr)
    signal.Ignore(syscall.SIGTSTP)
    if err != nil {
        fmt.Println("Error:", err)
        return
    }

    for {
        fmt.Println("hi from parent")
        time.Sleep(time.Second * 7)
    }
}

Além disso, quando eu invoco kill -SIGSTOP 1870508(movo o processo para To estado) e então invoco, kill -SIGINT 1870508o processo não é encerrado... Por quê?

Comecei a aprender sobre tty(s) e sinais do Linux e tive alguns problemas.

Estou lendo e usando o livro The TTY demystified como referência.

Criei dois programas simples de golang.

Pai:

package main

import (
    "fmt"
    "syscall"
    "time"
)

func main() {
    attr := &syscall.ProcAttr{
        Files: []uintptr{0, 1, 2},
    }

    _, err := syscall.ForkExec("./child/child", []string{"child"}, attr)
    if err != nil {
        fmt.Println("Error:", err)
        return
    }

    for {
        fmt.Println("hi from parent")
        time.Sleep(time.Second * 10)
    }
}

Criança:

package main

import (
    "fmt"
    "os/signal"
    "syscall"
    "time"
)

func main() {
    signal.Ignore(syscall.SIGTSTP) // golang's way to handle (ignore) signal

    for {
        fmt.Println("hi from child")
        time.Sleep(time.Second * 5)
    }
}

Eles são bem simples. Ambos apenas imprimem uma mensagem para tty a cada 5/10 segundos. A única diferença é que o filho ignora o sinal SIGTSTP (ctrl-z). Então, quando eu pressiono ctrl-z, ele suspende o pai, mas não o filho. É exatamente o que eu esperava. No entanto, o que eu não esperava é que todo o grupo fosse movido do primeiro plano para o grupo de segundo plano. Isso contrasta com The TTY demystified . Especificamente:

Quando todos os processos no trabalho em primeiro plano foram suspensos , o líder da sessão lê a configuração atual do dispositivo TTY e a armazena para recuperação posterior. O líder da sessão continua a se instalar como o grupo de processos em primeiro plano atual para o TTY usando uma chamada ioctl. Então, ele imprime algo como "[1]+ Stopped" para informar ao usuário que um trabalho foi suspenso.

Ele diz que somente quando todos os processos no trabalho em primeiro plano forem suspensos , o líder da sessão (shell/bash) moverá o grupo para o trabalho em segundo plano...

Resultado de ps l -t /dev/pts/0antes e depois de ctrl-z:

yakog@yakog-computer:~/goprojects/parent$ ps l -t /dev/pts/0
F   UID     PID    PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
0  1000 1747467 1747441  20   0  14288  5632 do_wai Ss   pts/0      0:00 bash
0  1000 1747496 1747467  20   0 1225432 1792 ep_pol Sl+  pts/0      0:00 ./parent
0  1000 1747501 1747496  20   0 1225424 1664 ep_pol Sl+  pts/0      0:00 child
yakog@yakog-computer:~/goprojects/parent$ ps l -t /dev/pts/0
F   UID     PID    PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
0  1000 1747467 1747441  20   0  14288  5632 do_sel Ss+  pts/0      0:00 bash
0  1000 1747496 1747467  20   0 1225432 1792 do_sig Tl   pts/0      0:00 ./parent
0  1000 1747501 1747496  20   0 1225680 1792 ep_pol Sl   pts/0      0:00 child

Se eu mover o ignore ( signal.Ignore(syscall.SIGTSTP)) do filho para o pai, então tudo funciona como deveria (do meu ponto de vista). O filho suspende (T), o pai retoma normalmente (R/S), mas o grupo ainda é o trabalho de primeiro plano.

yakog@yakog-computer:~/goprojects/parent$ ps l -t /dev/pts/0
F   UID     PID    PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
0  1000 1749437 1749410  20   0  14420  5632 do_wai Ss   pts/0      0:00 bash
0  1000 1749957 1749437  20   0 1225448 1920 ep_pol Sl+  pts/0      0:00 ./parent
0  1000 1749962 1749957  20   0 1225412 1664 ep_pol Sl+  pts/0      0:00 child
yakog@yakog-computer:~/goprojects/parent$ ps l -t /dev/pts/0
F   UID     PID    PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
0  1000 1749437 1749410  20   0  14420  5632 do_wai Ss   pts/0      0:00 bash
0  1000 1749957 1749437  20   0 1225448 1920 ep_pol Sl+  pts/0      0:00 ./parent
0  1000 1749962 1749957  20   0 1225668 1792 do_sig Tl+  pts/0      0:00 child

Por que isso está acontecendo? O que estou perdendo?

Recentemente comecei a aprender sobre sistemas operacionais e o kernel do Linux. Eu estava interessado em terminais, então comecei por lá, no entanto, rapidamente me deparei com um problema. Escrevi uma pergunta um pouco mais longa, porque queria que você visse exatamente onde o problema potencialmente surgiu no meu entendimento e soubesse exatamente o que não está claro para mim. Obrigado antecipadamente :)

Li os seguintes artigos e perguntas/respostas:

1. O TTY desmistificado
2. Um guia para o terminal, console e shell
3. Resposta de Stéphane Chazelas

No entanto, estou tendo dificuldades para entender exatamente onde a disciplina da linha terminal (tty) está localizada logicamente porque encontrei uma inconsistência (como eu ingenuamente entendi) entre o 1º artigo e a resposta de Stéphane Chazelas.

O TTY desmistificado usa primeiro a seguinte imagem:

Ele diz que o driver TTY é representado por tty_io.c, enquanto a disciplina de linha padrão é representada por n_tty.c. Processos (como bash) se comunicam com o driver TTY ( tty_io.c). Na verdade, na prática, com um arquivo que representa o dispositivo inteiro (driver UART + disciplina de linha + driver TTY). O driver UART é uma classe "serial" de driver que se comunica com a linha física (e terminal adicional) de um lado e a disciplina de linha do outro.

A próxima imagem do The TTY demystified é:

Tudo é o mesmo, exceto que agora temos um emulador e um terminal virtual. A única diferença é que o driver UART não será usado, mas o driver "console".

A última imagem mostra a situação pseudo-terminal. Nesse caso, temos um lado mestre e um lado escravo. O emulador de terminal é "empurrado" para o espaço do usuário. Além disso, temos dois arquivos onde o emulador interage com o arquivo mestre ( /dev/ptmx), enquanto os processos (shell) interagem com o arquivo escravo ( /dev/pts/..). Nesse caso, o driver pty é usado e eu diria que logicamente, como nos casos anteriores, está no lugar onde "PTY master side" está escrito na imagem.

Tudo estava funcionando para mim (ou pelo menos acho que estava), e então me deparei com uma resposta de Stéphane Chazelas :

Muita inteligência está na disciplina de linha tty. A disciplina de linha é um módulo de software (residindo no driver, no kernel) empurrado para cima de um dispositivo serial/pty que fica entre esse dispositivo e a linha/fio (o lado mestre para um pty).

De acordo com as imagens, temos um "dispositivo" serial/console/pty representado através do driver no kernel (driver UART na primeira, emulador na segunda e "lado mestre" na terceira imagem) e então disciplina de linha depois (como parte do driver, em cima dele). Entretanto, o próximo componente nas imagens é o driver TTY ( tty_io.c), não linha/fio como Stéphane Chazelas escreveu... Talvez Stéphane pense no driver TTY quando ele diz "dispositivo serial/pty", mas isso não faz sentido para mim, já que então teríamos, por exemplo, UART (serial) driver <-> line discipline <-> TTY driver/UART (serial) driver. Adicionalmente, nas imagens, o driver TTY não faz diferença entre eles, é apenastty_io.c

Estou muito confuso. O que estou esquecendo? Onde a disciplina da linha tty está exatamente "logicamente" localizada?