ChennyStar's questions

Até agora, eu costumava fazer backup dos meus dados usando taruma das opções de compactação LZMA ( --lzma, --xzou --lzip)

Recentemente notei que o 7-Zip foi portado para Linux em 2021 ( https://www.xda-developers.com/7-zip-linux-official-release/ ). Não estou falando do antigo P7Zip ( https://p7zip.sourceforge.net/ ), que parece não ter mais manutenção, mas do 7-Zip oficial.

Então, eu testei e fiquei muito surpreso ao descobrir que ele é MUITO mais rápido que todas as outras implementações Linux LZMA, para a mesma taxa de compressão.

Abaixo meus testes (Debian 11). Por favor, não que eu esvaziei o cache RAM entre cada teste ( sync && echo 3 > /proc/sys/vm/drop_caches)

Estou trabalhando em uma pasta de 163M, contendo vários tipos de arquivos, PDF, texto, open office, e assim por diante...

$ du -hs TEST/
163M    TEST/

Com o 7-Zip, ele é compactado em um arquivo de 127 MB em 15 segundos:

$ time tar c -hp TEST/ | 7zz a -si test.tar.7z
real    0m14,565s
(...)

$ ll test.tar.7z
(...) 127M (...) test.tar.7z

Considerando que com todas as outras implementações do LZMA, leva quase 5 vezes mais tempo (cerca de 1'13"), para o mesmo tamanho de arquivo!

$ time tar -chp --lzma -f test.tar.lzma TEST/
real    1m13,159s

$ time tar -chp --xz -f test.tar.xz TEST/
real    1m12,889s

$ time tar -chp --lzip -f test.tar.lz TEST/
real    1m12,525s

$ ll test.tar.{7z,lz*,xz}
(...) 127M (...) test.tar.7z
(...) 127M (...) test.tar.lz
(...) 127M (...) test.tar.lzma
(...) 127M (...) test.tar.xz

Só para ter certeza de que não há nada de errado com tar, fiz os mesmos testes, mas canalizei tara saída de lzma|xz|lzip, em vez de usar as opções --lzma, --xze . --lzipMesmos resultados.

Então, basicamente, a versão Linux do 7-Zip faz com que todas as outras implementações do LZMA pareçam bastante sombrias. Acho que o 7-Zip não oferece suporte a proprietários e permissões de Linux, mas isso é irrelevante ao compactar um .tararquivo.

Então, alguém sabe por que a versão Linux do 7-Zip é muito mais rápida que outras implementações LZMA?

Tome o seguinte comando (exemplo real):

~$ gpg --edit-key [email protected] showpref quit
(...)
[ultimate] (1). Foo Bar <[email protected]>
     Cipher: AES256, AES192, AES, CAST5, 3DES
     AEAD: 
     Digest: SHA256, SHA1, SHA384, SHA512, SHA224
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, AEAD, Keyserver no-modify
     Preferred keyserver: ldap://keyserver.pgp.com
~$

Canalizar a saída para a | grepnão funciona:

~$ gpg --edit-key [email protected] showpref quit | grep Compression
(...)
[ultimate] (1). Foo Bar <[email protected]>
     Cipher: AES256, AES192, AES, CAST5, 3DES
     AEAD: 
     Digest: SHA256, SHA1, SHA384, SHA512, SHA224
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, AEAD, Keyserver no-modify
     Preferred keyserver: ldap://keyserver.pgp.com
~$

Existe uma maneira de fazer isso funcionar? Por exemplo, o resultado que gostaria de obter é:

~$ gpg --edit-key [email protected] showpref quit | grep Compression
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
~$

[EDITAR: o que tentei até agora]:

@steeldriver, @RomeoNinov: Não acho que o redirecionamento stderrvá resolver o problema. Não parece que gpga saída de vai para stderr.

Basicamente, gpgé um comando interativo, mas o lançamento gpg ... cmd1 cmd2o torna não interativo (por exemplo, gpg ... showpref quité o mesmo que fazer interativamente showprefseguido pelo shell quitin ).gpg

@steeldriver:

~$ gpg --edit-key [email protected] showpref quit 2> >(grep Compression)
(...)
[ultimate] (1). Foo Bar <[email protected]>
     Cipher: AES256, AES192, AES, CAST5, 3DES
     AEAD: 
     Digest: SHA256, SHA1, SHA384, SHA512, SHA224
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, AEAD, Keyserver no-modify
     Preferred keyserver: ldap://keyserver.pgp.com
~$

@RomeoNinov:

~$ gpg --edit-key [email protected] showpref quit 2>&1| grep Compression
(...)
[ultimate] (1). Foo Bar <[email protected]>
     Cipher: AES256, AES192, AES, CAST5, 3DES
     AEAD: 
     Digest: SHA256, SHA1, SHA384, SHA512, SHA224
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, AEAD, Keyserver no-modify
     Preferred keyserver: ldap://keyserver.pgp.com
~$

Na atualização de status do projeto do GRUB, no FOSDEM 2022 , eles falaram sobre a adição de suporte a cabeçalhos desanexados no GRUB 2.12 (para descriptografia):

Adicionar cabeçalhos desanexados de criptodiscos e suporte a arquivos-chave, Denis 'GNUtoo' Carikli, Glenn Washburn, Patrick Steinhardt

GRUB 2.12 foi lançado em dezembro de 2023, mas não consegui encontrar nenhuma menção a esse recurso em seu NEWSarquivo .

Alguém sabe se o 2.12 agora suporta cabeçalhos desanexados, conforme planejado inicialmente?

TLDR; Se /tmp estiver montado como tmpfs, na presença de swap, existe algum tipo de prioridade na troca? O tmpfs começa a trocar antes dos aplicativos?

HISTÓRIA COMPLETA

Eu tenho um laptop com 32G de RAM (Debian) e 32G de swap. Pretendo montar /tmp com tmpfs.

Mas estou preocupado com o comportamento caso o sistema precise trocar: o que será trocado primeiro? Eu acho (e espero) que os aplicativos tenham prioridade para uso de RAM sobre o tmpfs (por exemplo, acho que o tmpfs será trocado primeiro). Mas não consegui encontrar nenhuma confirmação para isso.

De forma mais ampla, existem cenários em que a montagem /tmp como tmpfs pode tornar o sistema lento?

Gostaria de formatar um HDD de 12 TB (não SSD) com EXT4 , para armazenar arquivos de vídeo grandes (cada arquivo tendo pelo menos 1 GiB de tamanho).

Estou trabalhando com um processador x86-64 (também conhecido como x64 ou amd64).

É claro que existe a -T largefile4opção mkfs.ext4, mas existem outras otimizações que podem ser feitas?

Em particular, pergunto-me:

• Devo aumentar o tamanho do bloco ao máximo (64K, -b 65536)?
• OU devo usar clusters de blocos e definir o tamanho do cluster para o máximo (256M, -C 268 435 456)
• OU devo fazer as duas coisas?

Quais seriam os melhores parâmetros em termos de espaço em disco e otimização de desempenho?

Acabei de ler sobre o recurso "dados inline" em EXT4 e, mais especificamente, sobre a resposta sobre como ativá-lo.

Quais são os motivos pelos quais esse recurso não está habilitado por padrão em EXT4? Acho que é para manter o FS compatível com kernels mais antigos, que ainda não suportavam esse recurso. Existem outras razões?

Se eu sei que nunca usarei um kernel mais antigo, há algum motivo para NÃO ativar sempre esse recurso ao formatar uma partição com EXT4?

Primeiro, estou ciente de que uma pergunta semelhante já foi respondida . A resposta foi SIM, mas gostaria de uma segunda opinião, porque:

• A pergunta não especificou se era LUKS1 ou LUKS2
• Algo que li na Wikipédia me deixou com dúvidas.

Então, a questão é: tecnicamente , um cabeçalho desanexado LUKS2 pode ser usado para várias unidades? Sei que não é recomendado do ponto de vista de segurança (veja a resposta ao post mencionado anteriormente), mas aqui estou interessado apenas no lado técnico da questão.

O que me causa dúvidas é a afirmação da Wikipedia de que um cabeçalho LUKS2 contém, em sua área JSON, segmentos que descrevem áreas criptografadas no disco. O que significaria que um cabeçalho LUKS2 está vinculado a uma unidade específica e, portanto, não pode ser reutilizado para outras unidades:

Logo após o cabeçalho binário vem a área JSON, contendo a configuração dos objetos (configuração), keylots, resumos, segmentos (descreve áreas criptografadas no disco) e tokens contendo metadados extras.

Então, o que você acha ? Um mesmo cabeçalho desanexado LUKS2 pode ser usado para várias unidades? Existe talvez uma diferença entre várias unidades idênticas e várias unidades radicalmente diferentes (por exemplo, um HDD e um pendrive)?

Todos os HDDs modernos são de " Formato Avançado ", por exemplo, por padrão, eles relatam um tamanho de setor lógico/físico de 512/4096.

Por padrão, a maioria das ferramentas de formatação do Linux usam um tamanho de bloco de 4096 bytes (pelo menos esse é o padrão no Debian/EXT4).

Até hoje, pensei que isso estava meio otimizado: Linux/EXT4 envia pedaços de dados 4K para o HDD, que pode lidar com eles de maneira ideal, mesmo que o tamanho do setor lógico seja 512K.

Mas hoje li este post bastante recente (2021) . O cara fez alguns benchmarks de HDD, para verificar se mudar o tamanho do setor lógico de seu HDD de 512e para 4Kn proporcionaria melhores desempenhos. Sua conclusão:

Lembre-se: minha teoria era que o sistema de arquivos usa blocos de 4k e tudo está devidamente alinhado, portanto não deve haver uma diferença significativa.

Isso se sustenta? Bem não. De jeito nenhum. (...) Usando blocos de 4kb… há uma diferença muito grande aqui. Este é um benchmarking de thread único, mas há consistentemente uma grande vantagem indo para o setor de 4k aqui em transferências de blocos de 4kb. (...)

Conclusões: Use Setores 4k!
No que me diz respeito, as conclusões aqui são bastante claras. Se você possui um sistema operacional moderno que pode lidar com setores de 4k e suas unidades suportam a operação como setores de 512 bytes ou 4k, converta suas unidades em setores nativos de 4k antes de fazer qualquer outra coisa. Então siga seu caminho e deixe o sistema operacional cuidar disso.

Basicamente, sua conclusão foi que houve uma grande melhoria de desempenho ao mudar o tamanho do setor lógico do HDD para 4Kn, em comparação com o 512e pronto para uso:

Agora, uma coisa importante a ser observada: esse benchmark específico era de thread único. Ele também fez um benchmark de 4 threads, que não mostrou diferenças significativas entre 512e e 4Kn.

Assim, minhas perguntas:

• Sua conclusão é válida apenas se você tiver processos de thread único que leem/gravam na unidade. O Linux possui esses processos de thread único?
• E assim, você recomendaria definir o tamanho do setor lógico de um HDD para 4Kn?

TLDR;

Na terminologia EXT4, "grupos de blocos" e "extensões" são a mesma coisa?

[EDITAR] A sugestão O que o recurso "extensões" faz no sistema de arquivos ext4 no Linux? a discussão não responde a essa pergunta. Embora explique claramente o que são "extensões", não fala sobre "grupos de blocos" e se é a mesma coisa ou não (não é: veja a resposta abaixo ).

DETALHES

Neste post eles discutem a estrutura de um grupo de blocos:

Segundo a Wikipedia , uma extensão é um intervalo de blocos.

Esses dois conceitos são a mesma coisa, apenas usando nomes diferentes?

Li algumas coisas sobre a diferença entre ID de usuário real e efetivo. Achei que entendi, mas tenho uma dúvida: pelo meu entendimento, no exemplo abaixo o comando $ id -undeveria retornar rootcomo usuário efetivo e não jack:

$ sudo cp /usr/bin/bash /usr/bin/bashroot
$ sudo chmod u+s /usr/bin/bashroot
$ ls -l /usr/bin/bashroot 
-rwsr-xr-x 1 root root 1234376 oct.  25 15:42 /usr/bin/bashroot

$ bashroot

$ id -un
jack

$ id -unr
jack

bashroottem setuid e pertence a root, então de acordo com minha compreensão eu esperava $ id -unretornar root, não jack.

Do que sinto falta?

[EDITAR] Mais especificamente, por que não /usr/bin/bashrootse comporta como /usr/bin/passwd, visto que ambos possuem setuid ?

$ ls -l /usr/bin/passwd 
-rwsr-xr-x 1 root root 63960 févr.  7  2020 /usr/bin/passwd

$ ls -l /usr/bin/bashroot 
-rwsr-xr-x 1 root root 1234376 oct.  25 15:42 /usr/bin/bashroot

$ passwd
Changing password for jack.
Current password: 

Então, em outro terminal:

$ bashroot

$ ps -a | grep passwd
1682362 pts/3    00:00:00 passwd
$ ps -eo pid,ruid,euid | grep 1682362
1682362  1000     0

$ ps -a | grep bashroot
1682405 pts/4    00:00:00 bashroot
$ ps -eo pid,ruid,euid | grep 1682405
1682405  1000  1000

O UID efetivo passwdé root(0), o que é esperado. Por que o UID efetivo é bashroot1000 ( jack) e não root?

[EDIT2: SO]

$ cat /etc/debian_version 
11.6
$ uname -a
Linux d11work 5.10.0-20-amd64 #1 SMP Debian 5.10.158-2 (2022-12-13) x86_64 GNU/Linux
$ bash --version
GNU bash, version 5.1.4(1)-release (x86_64-pc-linux-gnu)

[EDIT3] Veja a resposta de Stephen Kitt :

$ bashroot -p

# id -un
root

# id -unr
jack 

TLDR;

O HDD parecia danificado. Não é possível formatar a partição ( mkfs.ext4erros de E/S), mesmo com uma tabela GPT recém-criada. O teste SMART mostra alguns erros. Eu estava prestes a jogar o disco fora. Antes disso, por curiosidade, fiz um badblocksteste completo. Grande surpresa: não detectou nenhum bloco defeituoso! Voltei ao GParted, criei uma tabela GPT + algumas partições. Tudo funciona bem agora! O que você badblocksfez?

A história completa

Estou tentando entender o que aconteceu: eu estava prestes a jogar fora um disco rígido porque não consegui criar partições nele e o SMART mostrou alguns erros. Antes de jogar fora o disco eu só queria brincar um pouco com ele badblocks, e... grande surpresa: badblocksparecia ter consertado meu disco! Eu nem sabia que poderia fazer isso! Estou feliz agora, posso realmente usar meu disco, ele funciona bem, mas ainda estou tentando descobrir o que aconteceu!

É um HDD Seagate de 4 TB que eu não usava há alguns anos. Conectei-o em um adaptador SATA ↔ USB (o adaptador funciona bem, eu uso com vários outros HDDs). Wirh GParted Criei uma nova tabela de partição GPT e, em seguida, uma partição. Não foi possível prosseguir até o final, ocorreu um mkfs.ext4erro de E/S:

(...)
Allocating group tables: done
Writing inode tables: done
Creating journal (131072 blocks): done
Writing superblocks and filesystem accounting information: 0/895
mke2fs 1.46.2 (28-Feb-2021)
mkfs.ext4: Input/output error while writing out and closing file system

Tentei várias vezes, com diferentes adaptadores USB, diferentes cabos USB, diferentes portas USB. Nunca funcionou.

Em seguida, fiz um pequeno teste SMART:

# smartctl -t short -C /dev/sde
(...)

# smartctl -a /dev/sde
(...)
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short captive       Completed: read failure       90%       528         191105024
(...)

Obviamente o HDD parece estar com defeito, certo? Então eu estava prestes a jogar fora, mas fiz um badblocksteste antes:

# badblocks -wvs -t random -b 4096 /dev/sde
Checking for bad blocks in read-write mode
From block 0 to 976754645
Testing with random pattern: done                                                 
Reading and comparing: done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)

O teste durou cerca de 19 horas (disco de 4 TB), não apresentou erros. Fiquei muito surpreso!

De volta ao GParted, criei uma nova tabela GPT, algumas partições, tudo correu bem.

Acabei fazendo alguns testes de cópia que costumo fazer, para verificar o desempenho do disco, e tudo parece normal (155MB/s R/W ao copiar arquivos grandes).

Também fiz outro pequeno teste SMART, completed without errordesta vez:

# smartctl -t short -C /dev/sde
(...)

# smartctl -a /dev/sde
(...)
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short captive       Completed without error       00%       549         -
# 2  Short captive       Completed: read failure       90%       528         191105024
(...)

Alguém pode entender isso? É como se a execução badblocksde alguma forma reparasse meu disco rígido. Como isso é possível ? É badblocksmesmo suposto fazer isso?

Observação: mais informações estão disponíveis, se necessário (saída SMART completa e resultados completos do GParted)

Acabei de ler esta discussão entre Linus Torvalds e (entre outros) Milan Broz , um dos mantenedores do dm-crypt.

Estou intrigado com a seguinte parte da discussão:

Linus Torvalds: Achei que as pessoas que usavam coisas ocultas ("negadas") na verdade nunca usavam o sistema de arquivos externo, exatamente para que pudessem colocar a coisa criptografada real lá e não se preocupar com isso.

Milan Broz: Bem, eles deveriam "usar" o exterior de vez em quando para que os dados pareçam "recentes" e para todo o "sistema operacional oculto" eles deveriam ser capazes de inicializar o sistema operacional chamariz externo mediante solicitação, apenas para mostrar que algo trabalhando está lá.

Em teoria, concordo com a afirmação de Milan, usar os dados do chamariz é uma boa coisa a se fazer para aumentar a credibilidade. Mas como conseguir isso na prática? Por exemplo, como você pode escrever no volume externo sem correr o risco de sobrescrever o volume interno?

Eu uso volumes LUKS ocultos há anos, combinando cabeçalhos destacáveis ​​e deslocamento de dados. Normalmente começo criando um pequeno volume externo criptografado com LUKS (digamos 20 GB), formato-o com EXT4, preencho-o com dados chamarizes, depois aumento o tamanho desse volume externo (para, por exemplo, 500 GB) e crio o volume interno com um deslocamento de 25 GB, por exemplo.

E depois disso faço o que Linus disse, evito religiosamente tocar nos dados chamariz do volume externo, com medo de danificar os dados do volume interno.

Existe uma maneira de atualizar os dados do volume externo, sem correr o risco de danificar os dados do volume interno? Por exemplo, existe uma ferramenta para escrever especificamente nos 20 primeiros shows do volume externo, certificando-se de não mexer nos 480 shows seguintes?

Estou usando HDDs e SSDs, então a questão se aplica a ambos.

VERSÃO CURTA (TL;DR)

Eu tenho 2 pequenos arquivos de uma linha, aparentemente idênticos:

$ cat f1 f2
./cconv.sh 100 EUR USD
./cconv.sh 100 EUR USD

Mas eles não são, há uma diferença de 1 byte no tamanho:

$ ls -l f1 f2
(...) 24 oct.  30 16:19 f1
(...) 23 oct.  30 16:19 f2

$ diff f1 f2
1c1
< ./cconv.sh 100 EUR USD
---
> ./cconv.sh 100 EUR USD

Eu costumava dhexdescobrir a diferença hexadecimal. Parece que :

• f1termina comc2 a0 55 53 44 0a
• f2termina com 20 55 53 44 0a

Alguém tem ideia do que está acontecendo aqui? Qual é a diferença e, mais importante, de onde poderia vir? Aqui está um link para um arquivo zip contendo os 2 arquivos e uma captura de tela do dhexresultado.

VERSÃO LONGA (EXPLICAÇÕES ADICIONAIS)

Os 2 arquivos são trechos do meu arquivo ~/.bash_history file.

Percebi um comportamento muito estranho das minhas conchas. Pegue o seguinte script muito básico:

#!/bin/sh
echo $#
echo "$1"
echo "$2"
echo "$3"
exit 0

Sob certas circunstâncias (mas quais ???), ele não usa o espaço como separador de argumentos:

$ ./cconv.sh 100 EUR USD
2
100
EUR USD

Mas às vezes funciona exatamente como deveria:

$ ./cconv.sh 100 EUR USD
3
100
EUR
USD

Isso me deixa louco! Passei várias horas tentando descobrir o que estava acontecendo. Aqui estão alguns testes que fiz para tentar reduzi-lo:

• Eu trabalho em um laptop com Debian 11, Gnome 3.38. Mas acontece que também tenho uma máquina virtual com exatamente o mesmo sistema operacional (D11, G3.38), e na VM tudo funciona bem. Então, obviamente, devo ter feito algo no meu laptop bare metal para que ele se comportasse mal. Mas o que ???
• Percebi que o problema ocorre apenas em uma sessão gráfica. Se eu abrir um tty (Ctrl+Alt+F n ), funciona bem
• Suspeitei do meu emulador de terminal. Mas o comportamento é o mesmo em emuladores diferentes (tentei Gnome Terminal, Terminator e Konsole, mesmo resultado)
• Suspeitei da concha. Mas o comportamento é o mesmo com Bash ou Dash
• Desativei todas as personalizações que pude pensar:
  • Eu removi temporariamente /etc/bashrc, /etc/profilee/etc/inputrc/etc/rc.local
  • Eu removi temporariamente ~/.bashrce~/.profile~/.inputrc
  • Desativei todas as extensões do Gnome Shell
• Eu até suspeitei do teclado e conectei um teclado USB. Mesmo resultado.

Estou realmente confuso, e não tenho a menor idéia do que está acontecendo. Eu finalmente notei essa pequena diferença entre os 2 comandos em ~/.bash_history: um vem da minha sessão do Gnome, o outro vem da minha sessão tty. Obviamente, há uma diferença, mas o que é exatamente e qual poderia ser a causa?

$ ps -ef | head -n 1 && ps -ef | grep calc
UID          PID    PPID  C STIME TTY          TIME CMD
user1     524014    5382  0 10:21 ?        00:00:01 gnome-calculator
user1     532125  510665  0 10:36 pts/4    00:00:00 grep calc

Eu pensei que apenas os daemons teriam ?como TTY, mas obviamente o Gnome Calculator não é um daemon. Eu sei que está rodando no TTY2, que é o TTY usado pela minha sessão do Gnome. Então, por que o psresultado é exibido ?na coluna TTY?

[EDITAR]

Eu tenho a ideia de que o Gnome Calculator não está diretamente ligado a um TTY, porque foi lançado através de um shell gráfico (Gnome Shell). Eu pensei que, subindo a árvore de processos, eu obteria um processo anexado ao TTY2, mas esse nunca é o caso:

$ ps -f | head -n 1 && ps -ef | grep calc
UID          PID    PPID  C STIME TTY          TIME CMD
user1     524014    5382  0 10:21 ?        00:00:01 gnome-calculator
user1     578611  552619  0 11:58 pts/5    00:00:00 grep calc

$ ps -f -p 5382
UID          PID    PPID  C STIME TTY          TIME CMD
user1       5382    5131  4 juin10 ?       00:42:26 /usr/bin/gnome-shell

$ ps -f -p 5131
UID          PID    PPID  C STIME TTY          TIME CMD
user1       5131       1  0 juin10 ?       00:00:00 /lib/systemd/systemd --user

$ echo $DISPLAY 
:1

Nenhum processo na cadeia está anexado ao TTY2. Mas obviamente o Gnome Calculator é exibido atualmente no TTY2. Existe um comando para descobrir em qual TTY um determinado processo é exibido no momento? (ou talvez em qual $DISPLAY)?

Qual é a maneira mais rápida de copiar/colar entre um console não gráfico (<Ctrl><Alt><F...>) e uma sessão X?

Agora mesmo :

• Eu seleciono o texto com o mouse no console (instalei o gpm)
• Então eu colo o texto dentro de um arquivo temporário
• E finalmente eu mudo para a sessão x, abro o arquivo temporário e copio/cole seu conteúdo

Há uma maneira mais fácil de fazer isso ? As seleções primárias do console não-X e da sessão X podem ser mescladas? Idealmente, eu gostaria de selecionar o texto no console, alternar para a sessão X e colá-lo (clique com o botão do meio). Isso pode ser feito?

No Bash, para fazer um globbing de arquivo negativo, tenho as 2 opções a seguir. Existe uma diferença entre eles? Ambos retornam o mesmo resultado:

$ ls
f1.txt  f2.txt  f3.txt  f4.txt

$ ls f[!24]*
f1.txt  f3.txt

$ ls f[^24]*
f1.txt  f3.txt

Tenho os seguintes arquivos JPEG:

$ ls -l
-rw-r--r-- 1 user group 384065 janv. 21 12:10 CamScanner 01-10-2022 14.54.jpg
-rw-r--r-- 1 user group 200892 janv. 10 14:55 CamScanner 01-10-2022 14.55.jpg
-rw-r--r-- 1 user group 283821 janv. 21 12:10 CamScanner 01-10-2022 14.56.jpg

Eu uso $ img2pdfpara transformar cada imagem em um arquivo PDF. Fazer isso :

$ find . -type f -name "*.jpg" -exec img2pdf "{}" --output $(basename {} .jpg).pdf \;

Resultado:

$ ls -l *.pdf
-rw-r--r-- 1 user group 385060 janv. 21 13:06 CamScanner 01-10-2022 14.54.jpg.pdf
-rw-r--r-- 1 user group 201887 janv. 21 13:06 CamScanner 01-10-2022 14.55.jpg.pdf
-rw-r--r-- 1 user group 284816 janv. 21 13:06 CamScanner 01-10-2022 14.56.jpg.pdf

Como posso remover a .jpgparte dos nomes de arquivos PDF? Ou seja, eu quero CamScanner 01-10-2022 14.54.pdfe não CamScanner 01-10-2022 14.54.jpg.pdf.

Usado sozinho, $ basename filename .extensionimprime o nome do arquivo sem a extensão, por exemplo:

$ basename CamScanner\ 01-10-2022\ 14.54.jpg .jpg
CamScanner 01-10-2022 14.54

Mas parece que a sintaxe não funciona no meu $ findcomando. Alguma ideia do porquê?

Obs: se substituir $ img2pdfpor $ echoé igual, $ basenamenão se desfaz da .jpgpeça:

$ find . -type f -name "*.jpg" -exec echo $(basename {} .jpg).pdf \;
./CamScanner 01-10-2022 14.56.jpg.pdf
./CamScanner 01-10-2022 14.55.jpg.pdf
./CamScanner 01-10-2022 14.54.jpg.pdf

Estou tentando entender como o NordVPN funciona, do lado do IP.

Depois de estabelecer um túnel VPN, meu endereço IP público se torna:

$ dig +short myip.opendns.com @resolver1.opendns.com
138.199.16.59

E as seguintes novas rotas são criadas:

0.0.0.0/1 via 10.8.3.7 dev tun0 
128.0.0.0/1 via 10.8.3.7 dev tun0
10.8.3.0/24 dev tun0 proto kernel scope link src 10.8.3.7
138.199.16.57 via 192.168.1.1 dev wlp2s0

Entendo todos menos o último ( 138.199.16.57 via 192.168.1.1 dev wlp2s0). Parece que o NordVPN precisa alcançar diretamente (por exemplo, sem passar pelo túnel) um endereço IP público ( 138.199.16.57) do mesmo intervalo que o IP público que recebi ( 138.199.16.59)

Qual o objetivo desta rota?

Pegue o seguinte arquivo:

aaa
bbb
XXX
ccc
ddd
eee
XXX
fff
ggg

Eu gostaria de imprimir, compcregrep , todas as linhas até a primeira contendo XXX:

aaa
bbb
XXX

É possível (com pcregrepou pcre2grep)?

Eu consegui isso:

$ pcre2grep -nM '(.|\n)*?XXX' file
1:aaa
bbb
XXX
4:ccc
ddd
eee
XXX

Existe uma maneira de sair após a primeira partida? Parece que pcre2grepnão tem uma --max-countopção como greptem.

Nota : Estou ciente de que existem ferramentas melhores para obter o resultado desejado ( sed, entre outras), mas não procuro soluções alternativas aqui. Minha dúvida é sobre pcregrepou pcre2grep, gostaria de saber se existe uma forma de emular grepa --max-countopção do .

Pegue o seguinte arquivo:

$ cat f1
stu vwx yza
uvw xyz abc
abc def ghi
def ghi jkl
ghi jkl mno
jkl mno pqr
mno pqr stu
pqr stu vwx
stu vwx yza

Para imprimir todas as linhas desde a primeira que contém abcaté a primeira que contém mnocom GNU sed:

$ sed -n '/abc/,/mno/p' f1
uvw xyz abc
abc def ghi
def ghi jkl
ghi jkl mno

Como eu poderia imprimir todas as linhas até a última contendo mno, por exemplo, como eu poderia obter o seguinte resultado:

uvw xyz abc
abc def ghi
def ghi jkl
ghi jkl mno
jkl mno pqr
mno pqr stu

Em outras palavras, existe uma maneira de tornar seda seleção de intervalo do GNU gananciosa?

Atualizar

Na minha configuração:

• Se mnoestiver faltando, deve imprimir tudo até o final do arquivo.
• mnonão pode ocorrer antes do primeiro abc.
• Sempre há pelo menos um abce nunca estão abcna mnomesma linha

EDIT Acabei de adicionar uma stu vwx yzalinha fictícia no início, para que o arquivo não comece com uma linha incluindo abc(para evitar soluções que começam na primeira linha - elas devem começar na primeira linha abc)