Yakog's questions

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?