Considere os seguintes comandos:
$ awk 'BEGIN { system("ed") }'
q
$ echo hello | awk 'BEGIN { system("ed") }'
?
$
No primeiro caso, consegui executar ed e então permanecer no editor e sair manualmente com o comando q; mas no segundo, ed saiu automaticamente. Por que a sessão interativa ed não funciona no segundo comando? Existe alguma maneira de executar a função do sistema AWK para chamar um comando interativo enquanto estiver em um pipeline?
Nos meus sistemas macOS e Linux, eu executo ed com alias ed='rlwrap ed'. No macOS com rlwrap 0.46.1 (2022) eu posso criar arquivos livremente com abas como:
$ ed
a
foo<TAB>bar
mas em meus sistemas Linux com rlwrap 0.43 (2016) não consigo usar tabulações a menos que eu escape assim:
$ ed
a
foo<ESCAPE><TAB>bar
Sei que devo atualizar meus servidores Linux; mas o rlwrap está atualmente no máximo de acordo com o apt. Existe alguma opção do rlwrap que me devolverá minhas abas? Tentei pesquisar na página de manual do rlwrap por "tab"; mas não encontrei nada.
Dado o seguinte arquivo:
foo bar baz
this and that
então posso facilmente "desdobrar" essas linhas com substituição global com ed(1):
g/ /s//\
/g
que dá:
foo
bar
baz
this
and
that
Mas o que é uma maneira suave de "dobrar linhas"?
Não consigo usar o padrão \nor \<newline>em um g/re/sidioma. Atualmente, estou usando a seguinte abordagem:
1
+,++s/^/ /
--,.jp
++,+++s/^/ /
--,.jp
,p
para voltar:
foo bar baz
this and that
mas é bem desajeitado e eu me pergunto se existe uma maneira melhor!
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.
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:
E o podman é como:
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
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:
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
ansible-playbookfalha, mas a segunda versão é bem-sucedida?/dev/stdindiante do heredoc?rubyou awknão precisam do /dev/stdinantes do heredoc?