mbigras's questions

Considere meu humilde hello.htmlarquivo, editado com poderoso ed:

$ ed hello.html 
28
,p
<title>Hello world!</title>

Qual é a sua abordagem geral para editar dentro da tag HTML do título (bônus se você puder editar dentro de qualquer tag HTML)?

Tentei uma expressão regular que corresponda dentro da tag:

s/>.*/>My new title/p
<title>My new title
u
.
<title>Hello world!</title>

Mas, infelizmente, você pode ver que eu cortei minha tag (e seria muito trabalhoso digitar esse </title>pedaço toda vez!).

Para obter mais informações, naveguei pela página Ferramentas de software em Pascal até 174 - consulte https://archive.org/details/softwaretoolsinp00kern/page/174/mode/1up?view=theater página - e descobri o &caractere especial que chega de forma útil ao meio da frase:

s/world/& again/p
<title>Hello world again!</title>

Mas isso não está certo, já que quero substituir o meio, e não apenas chegar ao meio.

Estou totalmente confuso por que não consigo imprimir esse intervalo com ed quando há dois intervalos —veja o arquivo file2.tf— ; mas posso imprimir quando há apenas um intervalo - consulte o arquivo file1.tf - e posso imprimir com o comando gsed (GNU sed no macOS); mas não consigo imprimir com ed. Por favor, considere minha sessão de shell e esclareça meus equívocos:

$ ed -s file1.tf <<<',n'
1   # some comment
2   module "hello_world" {
3     source = "./mydir"
4   }
5   # another comment
$ ed -s file1.tf <<<'/module.*world/,/}/p'
module "hello_world" {
  source = "./mydir"
}
$ ed -s file2.tf <<<',n'
1   # some comment
2   module "hello_world" {
3     source = "./mydir"
4   }
5   # another comment
6   # some comment
7   module "hello_again" {
8     source = "./anotherdir"
9   }
10  # another comment
$ ed -s file2.tf <<<'/module.*again/,/}/p'
?
$ gsed -n '/module.*again/,/}/p' file2.tf
module "hello_again" {
  source = "./anotherdir"
}

Atualização: A direção reversa funciona; mas não sei por que:

$ ed -s file2.tf <<<'?module.*again?,?}?p'
module "hello_again" {
  source = "./anotherdir"
}

Atualização 2: A ??abordagem realmente não funciona como pretendido (se houver três seções, como no exemplo do arquivo file3.tf ) e veja a resposta para obter uma explicação.

$ ed -s file3.tf <<<,n
1   # some comment
2   module "hello_world" {
3     source = "./mydir"
4   }
5   # another comment
6   # some comment
7   module "hello_again" {
8     source = "./anotherdir"
9   }
10  # another comment
11  # some comment
12  module "hello_yet_again" {
13    source = "./yetanotherdir"
14  }
15  # another comment
$ ed -s file3.tf <<<'?module.*hello_again?,?}?p'
module "hello_again" {
  source = "./anotherdir"
}
# another comment
# some comment
module "hello_yet_again" {
  source = "./yetanotherdir"
}

Não tenho certeza se algo mudou no meu sistema, mas acho que filtrar as páginas de manual do Unix por meio do meu grepcomando não está funcionando. Você sabe o que há de errado?

Por exemplo, considere a página de manual jq compilada a partir do código a seguir.

.
.IP "\(bu" 4
\fB\-\-slurp\fR/\fB\-s\fR:
.
.IP
Instead of running the filter for each JSON object in the input, read the entire input stream into a large array and run the filter just once\.
.

Se eu quiser procurar rapidamente o --slurpswitch, geralmente filtro a jqpágina de manual, grepcomo mostra a sessão de terminal a seguir.

$ man jq | grep -- --slurp
$

Observe como nada é retornado. Isso é estranho, o resultado esperado é algo como o seguinte.

$ man jq | grep -- --slurp
       •   --slurp/-s:

Isso é esperado porque, se eu realmente executar man jqo comando e usar o /pressionamento de tecla de pesquisa, procure por --slurp, isso funcionará.

# ...
       •   --slurp/-s:

           Instead of running the filter for each JSON object in the input, read the entire input stream into a large array and run the filter just once.

Acho que há um problema com caracteres especiais, mas não tenho certeza. Tentei colocar a página de manual por meio catdo comando, mas também não funcionou. Também tentei remover todos os caracteres especiais - consulte Como remover todos os caracteres especiais no texto do Linux - mas também não funcionou.

$ man jq | cat | grep -- --slurp
$
$ man jq | sed $'s/[^[:print:]\t]//g' | grep -- --slurp
$

Caso isso seja relevante, consulte os seguintes detalhes sobre o meu sistema.

$ neofetch --off
OS: macOS 13.0.1 22A400 x86_64
Host: MacBookPro16,1
Kernel: 22.1.0
Uptime: 6 days, 1 hour, 3 mins
Packages: 145 (brew)
Shell: bash 3.2.57
Resolution: 1792x1120@2x
DE: Aqua
WM: Quartz Compositor
WM Theme: Blue (Light)
Terminal: iTerm2
Terminal Font: Monaco 12
CPU: Intel i7-9750H (12) @ 2.60GHz
GPU: Intel UHD Graphics 630, AMD Radeon Pro 5300M
Memory: 10425MiB / 16384MiB

Dado que o podman está instalado em um sistema linux e uma unidade systemd chamada baz.service:

# /etc/systemd/system/baz.service
[Service]
ExecStart=/usr/bin/podman run --rm --tty --name baz alpine sh -c 'while true; do date; sleep 1; done'
ExecStop=/usr/bin/podman stop baz

E o baz.service começou:

# systemctl daemon-reload
# systemctl start baz.service

Então, quando eu verifico o status da unidade, não vejo o shou sleepprocesso no cgroup /system.slice/baz.service

# systemctl status baz
● baz.service
   Loaded: loaded (/etc/systemd/system/baz.service; static; vendor preset: enabl
   Active: active (running) since Sat 2019-08-10 05:50:18 UTC; 14s ago
 Main PID: 16910 (podman)
    Tasks: 9
   Memory: 7.3M
      CPU: 68ms
   CGroup: /system.slice/baz.service
           └─16910 /usr/bin/podman run --rm --tty --name baz alpine sh -c while
# ...

Eu esperava ver o shand sleepchildren no meu status baz.service porque ouvi pessoas da redhat dizerem que o podman usa um modelo tradicional de fork-exec.

Se podman fizesse fork e exec, então my she sleepprocess não seriam filhos de podman e estariam no mesmo cgroup que o processo podman original?

Eu esperava poder usar o systemd e o podman para poder gerenciar meus contêineres sem que os filhos fossem para um pai diferente e escapassem da minha unidade ssystemd baz.service.

Olhando para a saída de pseu posso ver isso she sleepna verdade são filhos de um processo diferente chamado conmon. Não tenho certeza de onde veio o conmon ou como foi iniciado, mas o systemd não o capturou.

# ps -Heo user,pid,ppid,comm
# ...
root     17254     1   podman
root     17331     1   conmon
root     17345 17331     sh
root     17380 17345       sleep

A partir da saída, fica claro que minha unidade baz.service não está gerenciando a cadeia conmon -> sh -> sleep.

• Como o podman é diferente do modelo de servidor cliente do docker?
• Como o conmon do podman é diferente do containerd do docker?

Talvez ambos sejam tempos de execução de contêiner e o dockerddaemon seja o que as pessoas querem se livrar.

Então, talvez o docker seja como:

• daemon dockerd
• docker cli
• tempo de execução do contêiner containerd

E o podman é como:

• podman cli
• tempo de execução do contêiner comum

Então, talvez o podman use um modelo tradicional de fork exec, mas não é o podman cli que é bifurcação e exec, é o processo comum.

Eu me sinto confuso.

Estou em um servidor Ubuntu e quero verificar um resumo do uso do disco dos diretórios internos /var/lib/dockerEstou confuso porque não consigo verificar o uso do disco de todos os diretórios internos /var/lib/dockerusando um glob *.

O diretório /var/lib/dockerexiste claramente e possui diretórios dentro dele:

$ sudo du -s /var/lib/* | grep docker
865644  /var/lib/docker
8   /var/lib/docker-engine
$ sudo du -s /var/lib/docker/*
du: cannot access '/var/lib/docker/*': No such file or directory
$ sudo file /var/lib/docker
/var/lib/docker: directory
$ sudo ls /var/lib/docker | head -n 1
builder
$ sudo du -s /var/lib/docker/builder
20  /var/lib/docker/builder

Por que estou recebendo um erro de du?

du: cannot access '/var/lib/docker/*': No such file or directory

Meu erro parece relacionado a ser um usuário não root porque, se eu mudar para o usuário root, posso emitir o ducomando:

# du -s /var/lib/docker/* | sort -n
4   /var/lib/docker/runtimes
4   /var/lib/docker/swarm
4   /var/lib/docker/tmp
4   /var/lib/docker/trust
20  /var/lib/docker/builder
20  /var/lib/docker/plugins
36  /var/lib/docker/volumes
60  /var/lib/docker/network
72  /var/lib/docker/buildkit
208 /var/lib/docker/containers
1880    /var/lib/docker/image
863328  /var/lib/docker/overlay2

Quando eu começo systemd-cgtopentão eu pressiono a ?tecla, então eu quero ler o menu de ajuda, mas ele desaparece após alguns segundos. Como evitar que o menu de ajuda desapareça?

Se eu digitar man tmux, /join-panevou direto para o subcomando que estou procurando:

Mas se eu grep a página do manual, não recebo nada:

$ man tmux | grep join-pane
$ echo $?
1

Se eu tentar algo diferente, então funciona:

$ man tmux | grep 'terminal multiplexer'
     tmux -- terminal multiplexer
     tmux is a terminal multiplexer: it enables a number of terminals to be

• O que está acontecendo aqui?
• Por que não consigo grep a página de manual do tmux para o painel de junção?

Alguns detalhes sobre meu sistema operacional e os comandos que estou usando:

$ uname -a
Darwin home.local 17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64
$ grep --version
grep (BSD grep) 2.5.1-FreeBSD
$ man --version
man, version 1.6c
$ tmux -V
tmux 2.7

De acordo com um comentário sobre isso ser um problema de terminal, tentei mais alguns padrões que não funcionaram:

$ man tmux | grep join\-pane
$ man tmux | grep "join-pane"
$ man tmux | grep 'join-pane'
$ man tmux | grep 'join\-pane'
$ man tmux | grep "join\-pane"
$ man tmux | grep -e join-pane

Da descrição de setna bash manpágina:

-v   Print shell input lines as they are read.

Assim, o seguinte script de exemplo:

#!/usr/bin/env bash
# setv.sh
set -v
foo=bar
echo $foo

Gera saída:

foo=bar
echo $foo
bar

Existe uma maneira de acrescentar alguma string, diga "+" a cada linha, para indicar claramente qual linha é uma linha do script e qual linha é a saída de uma linha do script. Usando o exemplo acima, a saída desejada seria:

+ foo=bar
+ echo $foo
bar

Estou curioso sobre a teoria por trás de como os heredocs podem ser passados ​​como um arquivo para um utilitário de linha de comando.

Recentemente, descobri que posso passar um arquivo como heredoc.

Por exemplo:

awk '{ split($0, arr, " "); print arr[2] }' <<EOF
foo bar baz
EOF
bar

Isso é vantajoso para mim por vários motivos:

• Heredocs melhoram a legibilidade para entradas de várias linhas.
• Não preciso memorizar cada sinalizador de utilitários para passar o conteúdo do arquivo da linha de comando.
• Posso usar aspas simples e duplas nos arquivos fornecidos.
• Eu posso controlar a expansão do shell.

Por exemplo:

ruby <<EOF
puts "'hello $HOME'"
EOF
'hello /Users/mbigras'

ruby <<'EOF'
puts "'hello $HOME'"
EOF
'hello $HOME'

Não estou claro o que está acontecendo. Parece que o shell pensa que o heredoc é um arquivo com conteúdo igual ao valor do heredoc. Eu usei essa técnica com gato, mas ainda não tenho certeza do que estava acontecendo:

cat <<EOL
hello world
EOL
hello world

Eu sei que catimprime o conteúdo de um arquivo, então presumivelmente este heredoc é um arquivo temporário de algum tipo.

Estou confuso sobre o que exatamente está acontecendo quando "passo um heredoc para um programa de linha de comando".

Aqui está um exemplo usando ansible-playbook . Passo ao utilitário um playbook como heredoc; no entanto, falha, conforme mostrado usando echo $?:

ansible-playbook -i localhost, -c local <<EOF &>/dev/null
---
- hosts: all
  gather_facts: false
  tasks:
    - name: Print something
      debug:
        msg: hello world
EOF
echo $?
5

No entanto, se eu passar o utilitário, o mesmo heredoc, mas o preceder, /dev/stdinserá bem-sucedido

ansible-playbook -i localhost, -c local /dev/stdin <<EOF &>/dev/null
---
- hosts: all
  gather_facts: false
  tasks:
    - name: Print something
      debug:
        msg: hello world
EOF
echo $?
0

• O que exatamente está acontecendo quando alguém "transmite um heredoc como um arquivo"?
• Por que a primeira versão ansible-playbookfalha, mas a segunda versão é bem-sucedida?
• Qual é o significado de passar /dev/stdindiante do heredoc?
• Por que outros utilitários gostam rubyou awknão precisam do /dev/stdinantes do heredoc?