terdon's questions

Ao responder uma pergunta em outro site, me deparei com uma estranha discrepância entre curle wgetao tentar buscar neste URL: https://www.uniprot.org/uniprot/A2Z669.fasta

Por algum motivo, curlo download falha silenciosamente e wgetbusca o arquivo corretamente A2Z669.fasta:

$ ls -la
total 300
drwxr-xr-x   2 terdon terdon 266240 Dec 11 12:22 .
drwxr-xr-x 202 terdon terdon  32768 Dec 10 17:31 ..

$ curl https://www.uniprot.org/uniprot/A2Z669.fasta
$ ls -la
total 300
drwxr-xr-x   2 terdon terdon 266240 Dec 11 12:22 .
drwxr-xr-x 202 terdon terdon  32768 Dec 10 17:31 ..

Definir explicitamente um arquivo de saída não ajuda, apenas cria um arquivo vazio:

$ curl -o file "https://www.uniprot.org/uniprot/A2Z669.fasta"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0

$ ls -la
total 300
drwxr-xr-x   2 terdon terdon 266240 Dec 11 12:25 .
drwxr-xr-x 202 terdon terdon  32768 Dec 10 17:31 ..
-rw-r--r--   1 terdon terdon      0 Dec 11 12:25 file
$ cat file
$ 

E ainda assim, wgetfunciona muito bem:

$ wget https://www.uniprot.org/uniprot/A2Z669.fasta
--2023-12-11 12:24:42--  https://www.uniprot.org/uniprot/A2Z669.fasta
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving www.uniprot.org (www.uniprot.org)... 193.62.193.81
Connecting to www.uniprot.org (www.uniprot.org)|193.62.193.81|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://rest.uniprot.org/uniprot/A2Z669.fasta [following]
--2023-12-11 12:24:42--  https://rest.uniprot.org/uniprot/A2Z669.fasta
Resolving rest.uniprot.org (rest.uniprot.org)... 193.62.193.81
Connecting to rest.uniprot.org (rest.uniprot.org)|193.62.193.81|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://rest.uniprot.org/uniprotkb/A2Z669.fasta [following]
--2023-12-11 12:24:43--  https://rest.uniprot.org/uniprotkb/A2Z669.fasta
Reusing existing connection to rest.uniprot.org:443.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: ‘A2Z669.fasta’

A2Z669.fasta            [ <=>               ]     314  --.-KB/s    in 0s      

2023-12-11 12:24:43 (6.65 MB/s) - ‘A2Z669.fasta’ saved [314]

$ ls -la
total 304
drwxr-xr-x   2 terdon terdon 266240 Dec 11 12:24 .
drwxr-xr-x 202 terdon terdon  32768 Dec 10 17:31 ..
-rw-r--r--   1 terdon terdon    314 Dec 11 12:24 A2Z669.fasta

Também não parece ser específico para esse arquivo específico. Tentei outro URL da mesma API REST ( https://www.uniprot.org/uniprot/P05067.fasta ) e obtive o mesmo comportamento.

Estou executando isso em um sistema Arch com:

$ wget --version | head -n1
GNU Wget 1.21.4 built on linux-gnu.

$ curl --version | head -n1
curl 8.4.0 (x86_64-pc-linux-gnu) libcurl/8.4.0 OpenSSL/3.1.4 zlib/1.3 brotli/1.1.0 zstd/1.5.5 libidn2/2.3.4 libpsl/0.21.2 (+libidn2/2.3.4) libssh2/1.11.0 nghttp2/1.58.0

O que está acontecendo aqui? O que funcionaria wgetquando curlfalhasse?

A sabedoria aceita nas últimas décadas é que nunca é uma boa ideia analisar a saída de ls( [1] , [2] ). Por exemplo, se eu quiser salvar a data de modificação de um arquivo junto com seu nome em uma variável shell, esta não é a maneira correta de fazer isso:

$ ls -l file
-rw-r--r-- 1 terdon terdon 0 Aug 15 19:16 file
$ foo=$(ls -l file | awk '{print $9,$6,$7,$8}')
$ echo "$foo"
file Aug 15 19:16

Assim que o nome do arquivo for ligeiramente diferente, a abordagem falha:

$ ls -l file*
-rw-r--r-- 1 terdon terdon 0 Aug 15 19:16 'file with spaces'
$ foo=$(ls -l file* | awk '{print $9,$6,$7,$8}')
$ echo "$foo"
file Aug 15 19:16

Fica pior se a data de modificação do arquivo não for próxima de hoje, pois isso pode alterar o formato da hora:

$ ls -l
total 0
-rw-r--r-- 1 terdon terdon 0 Aug 15 19:21  file
-rw-r--r-- 1 terdon terdon 0 Aug 15  2018 'file with spaces'

No entanto, as versões mais recentes do GNU coreutils lstêm duas opções que podem ser combinadas para definir um formato de hora específico e produzir uma saída delimitada por NULL:

      --time-style=TIME_STYLE
              time/date format with -l; see TIME_STYLE below
[...]
     --zero end each output line with NUL, not newline
[...]
       The TIME_STYLE argument can be full-iso,  long-iso,  iso,  locale,  or
       +FORMAT.   FORMAT  is  interpreted like in date(1).  If FORMAT is FOR‐
       MAT1<newline>FORMAT2, then FORMAT1 applies  to  non-recent  files  and
       FORMAT2  to recent files.  TIME_STYLE prefixed with 'posix-' takes ef‐
       fect only outside the POSIX locale.  Also the  TIME_STYLE  environment
       variable sets the default style to use.

Aqui estão os arquivos novamente, com essas opções definidas (o zero no final de cada linha de saída é substituído por #e uma nova linha aqui para melhorar a legibilidade):

$ ls -l --zero --time-style=long-iso -- *
-rw-r--r--+ 1 terdon terdon 0 2023-08-16 21:35 a file with a
newline#
-rw-r--r--+ 1 terdon terdon 0 2023-08-15 19:16 file#
-rw-r--r--+ 1 terdon terdon 0 2018-08-15 12:00 file with spaces#

Com essas opções disponíveis, posso fazer muitas das coisas que lstradicionalmente são ruins. Por exemplo:

1. Obtenha o nome do arquivo modificado mais recentemente em uma variável:

   $ touch 'a file with a'$'\n''newline'
   $ last=$(ls -tr --zero | tail -z -n1)
   bash: warning: command substitution: ignored null byte in input
   $ printf -- 'LAST: "%s"\n' "$last"
   LAST: "a file with a 
   newline"
   

2. O exemplo que gerou essa pergunta. Outra pergunta, no Ask Ubuntu, onde o OP queria imprimir o nome do arquivo e a data de modificação. Alguém postou uma resposta usando lse um awktruque inteligente e, se somarmos --zeroa ls, parece ser bem robusto:

   $ output=$(ls -l --zero --time-style=long-iso -- * | 
              awk 'BEGIN{RS="\0"}{ t=index($0,$7); print substr($0,t+6), $6 }')
   $ printf 'Output: "%s"\n' "$output"
   Output: "a file with a
   newline 2023-08-16"
   

Não consigo encontrar um nome que quebre qualquer um desses dois exemplos. Então, minhas perguntas são:

1. Existe um caso que falharia em um dos dois exemplos acima? Talvez alguma esquisitice local?
2. Se não, isso significa que as versões modernas do GNU lspodem realmente ser usadas com segurança com nomes de arquivo arbitrários?

Recentemente, comprei um novo laptop e gostaria de migrar para ele com o mínimo de problemas possível. Não quero fazer uma nova instalação, pois fiz vários ajustes na minha configuração atual para coisas como automontagem de unidades remotas do meu NAS, configuração de rede etc. que eu preferiria não ter que refazer.

Meu pensamento atual é que posso simplesmente despejar o conteúdo do meu disco rígido em um arquivo e, em seguida, catesse arquivo na nova unidade. A ideia geral será:

1. No computador antigo, transforme a unidade em um arquivo em um disco USB externo e (como root):

   # cat /dev/sda > /mnt/externalUsb/sda.img
   

2. Em seguida, inicializo em um sistema ativo no novo computador, conecto a unidade externa e (como root):

   # cat /mnt/externalUsb/sda.img | sudo tee /dev/sda
   

3. Encerre a sessão ao vivo, reinicie a máquina e, espero, encontrar-me em um sistema funcional que é um clone perfeito da minha máquina antiga.

Ou, talvez de forma mais realista, algo como:

1. Crie as partições que quero na nova máquina, certificando-se de que sejam maiores que as equivalentes na minha máquina antiga.

2. No computador antigo, transforme as partições em arquivos em um disco USB externo (como root):

   for i in 5 6; do cat /dev/sda"$i" > /mnt/externalUsb/sda"$i".img; done
   

3. Na nova máquina, depois de verificar se os números são os mesmos ou modificar o comando de acordo:

   for i in 5 6; do cat /mnt/externalUsb/sda"$i".img; > /dev/sda"$i"; done
   

Algumas notas relevantes:

• O hardware das máquinas antigas e novas é relativamente semelhante, pois estarei mudando de um ThinkPad T460P para um ThinkPad P14s Gen 2 .
• A nova máquina tem um disco rígido de 1 TB, mas o antigo tem apenas 512 G.
• Estou usando o Arch, dual boot com um Windows 10. Não estou particularmente preocupado em manter a instalação do Windows.

Configuração de disco da minha máquina atual:

$ sudo parted -l
Model: ATA SAMSUNG MZ7LN512 (scsi)
Disk /dev/sda: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system     Name                          Flags
 1      1049kB  274MB   273MB   fat32           EFI system partition          boot, hidden, esp
 2      274MB   290MB   16.8MB                  Microsoft reserved partition  msftres
 3      290MB   86.4GB  86.1GB  ntfs            Basic data partition          msftdata
 5      86.4GB  136GB   50.0GB  ext4
 6      136GB   437GB   301GB   ext4
 9      437GB   485GB   47.3GB  ntfs                                          msftdata
 8      485GB   495GB   10.5GB  ext4
 7      495GB   511GB   16.1GB  linux-swap(v1)                                swap
 4      511GB   512GB   1049MB  ntfs            Basic data partition          hidden, diag

Estou esperando que o kernel detecte o hardware novo/diferente na primeira vez que inicializar e o resolva para mim automaticamente. Estou perdendo algo óbvio aqui? Algum problema específico que eu possa encontrar? A nova unidade é maior, então isso não deve ser um problema, certo? Eu tenho um diretório criptografado com ecryptfs (dois deles, na verdade), estou certo em assumir que não será um problema? Talvez eu precise fazer algo especial para lidar com a partição do sistema EFI?

Aceitei a resposta útil do MC68020, mas acabei adotando uma abordagem diferente: inicializei um sistema ativo, criei a raiz e as /homepartições e copiei todos os meus arquivos usando rsyncconforme descrito no Arch Wiki .

Consegui inicializar o "novo" sistema, mas ainda precisa de alguns ajustes, principalmente para o driver gráfico. Esta não é uma abordagem a ser tomada se você não conhece o Linux e gosta de mexer. Claro, se você não gostar, é improvável que você esteja usando o Arch.

Recentemente, postei uma pergunta sobre um comportamento estranho que observei no bash, fishe zshshells que não foram exibidos pelo tcsh, csh, kshou dashshells. Acontece que o comportamento foi causado por uma alteração nas configurações padrão da readlinebiblioteca e corrigi-o adicionando set enable-bracketed-paste Offao meu arquivo ~/.inputc.

Isso me fez pensar. Por que isso afetou apenas esse subconjunto específico de shells no meu sistema? Todas as conchas não usam readline? Existe algum tipo de regra geral? Por que bash, zshe fishmudou seu comportamento enquanto as outras conchas não?

Alguns meses atrás, uma atualização do sistema fez com que meu shell não interpretasse mais as novas linhas à direita enterao colar um comando no terminal. Por exemplo, se eu escrever lsno meu prompt e usar o mouse para selecionar lsaté o final da linha, espero poder clicar com o botão do meio em colar em um shell e lsexecutar o comando. Este é o comportamento padrão que tenho usado há anos.

No entanto, meu sistema não faz mais isso. Eu posso colar o ls, e posso ver que a nova linha também foi colada porque meu cursor se move para a próxima linha, mas apesar disso, o comando não é executado até que eu pressione enter(estou colocando isso em um spoiler porque é um gif animado e pode ser uma distração):

Na animação acima, você pode me ver selecionando uma linha lsjá escrita, limpando lse colando com o botão do meio. Observe como o cursor se move para a próxima linha, mas o lscomando não é executado nesse ponto, mas somente depois que eu pressiono minha entertecla.

O realmente estranho, para mim, é que isso não é um problema com meu emulador de terminal ( terminator). O mesmo terminal interpretará a nova linha como esperado se eu fizer o ssh em uma máquina diferente (mas não se eu fizer o ssh no localhost). Então tem que ser algum tipo de configuração no meu shell local.

Além disso, há um contexto em que funciona conforme o esperado: o readbuiltin. Aqui, se eu selecionar uma linha incluindo a nova linha à direita, posso colá-la em um readprompt de espera e a nova linha à direita é tomada como o caractere EOL, readretornando. Então, por que não funciona fora desse contexto específico?

Tudo isso em um sistema Arch Linux, usando o modo GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)in emacs. Para tornar as coisas ainda mais confusas, tenho esse problema ao usar bash, zshou , fishmas não ao usar ksh, ou . Nos últimos quatro shells, tenho meu comportamento desejado e a linha colada é executada imediatamente. Isso pode estar relacionado ?dashtcshcshreadline

Como posso recuperar meu comportamento desejado e fazer com que quaisquer novas linhas coladas no meu shell sejam interpretadas?

Eu tenho uma situação muito estranha ao tentar usar uma ferramenta específica ( efetchdo NCBI E-utilities suite) em um loop while. Este é meu arquivo de entrada, uma lista de strings, uma por linha:

$ cat transcripts.list 
NR_169596.1
NR_169595.1
NR_169594.1

Eu quero executar o efetchcomando usando cada uma dessas strings como um argumento, então eu faço:

$ while read -r line; do echo "Line: $line"; esearch -db nucleotide -query "$line"; done <  transcripts.list 
Line: NR_169596.1
<ENTREZ_DIRECT>
  <Db>nucleotide</Db>
  <WebEnv>MCID_61bb689d20b59b3e2e2d405d</WebEnv>
  <QueryKey>1</QueryKey>
  <Count>1</Count>
  <Step>1</Step>
</ENTREZ_DIRECT>

Este é um resultado único, não três, como você pode ver pelo único echoque é executado. A mesma coisa funciona, no entanto, se eu usar um loop de prática ruim : for

$ for line in $(cat transcripts.list); do echo "Line: $line"; esearch -db nucleotide -query "$line"; done
Line: NR_169596.1
<ENTREZ_DIRECT>
  <Db>nucleotide</Db>
  <WebEnv>MCID_61bb68cabbe98560233344a7</WebEnv>
  <QueryKey>1</QueryKey>
  <Count>1</Count>
  <Step>1</Step>
</ENTREZ_DIRECT>
Line: NR_169595.1
<ENTREZ_DIRECT>
  <Db>nucleotide</Db>
  <WebEnv>MCID_61bb68cad05f5825d75e3ace</WebEnv>
  <QueryKey>1</QueryKey>
  <Count>1</Count>
  <Step>1</Step>
</ENTREZ_DIRECT>
Line: NR_169594.1
<ENTREZ_DIRECT>
  <Db>nucleotide</Db>
  <WebEnv>MCID_61bb68cb6bdec5435b5a41cb</WebEnv>
  <QueryKey>1</QueryKey>
  <Count>1</Count>
  <Step>1</Step>
</ENTREZ_DIRECT>

Pergunta: Como isso é possível? Mesmo que haja algum tipo de bug no esearchprograma específico, isso não deve afetar o loop, então por que o shell está saindo após a primeira iteração? E como pode o fortrabalho e o whilefracasso? O que eles fazem de diferente aqui?

Mais alguns detalhes.

1. Adicionar um echona frente do comando esearch faz com que o loop se comporte como esperado, então isso deve estar relacionado ao esearchcomando específico (mas como isso pode quebrar o loop do shell?):

   $ while read -r line; do echo esearch -db nucleotide -query "$line"; done <  transcripts.list 
   esearch -db nucleotide -query NR_169596.1
   esearch -db nucleotide -query NR_169595.1
   esearch -db nucleotide -query NR_169594.1
   

2. Não há nada de estranho na própria lista, posso reproduzi-la com listas diferentes e não há caracteres ocultos:

   $ od -c transcripts.list 
   0000000   N   R   _   1   6   9   5   9   6   .   1  \n   N   R   _   1
   0000020   6   9   5   9   5   .   1  \n   N   R   _   1   6   9   5   9
   0000040   4   .   1  \n
   0000044
   

3. Eu recebo o mesmo comportamento em bash e dash, então não pode estar relacionado a coisas como PIPEFAIL ou algo assim. Em qualquer caso, o status de saída do comando é 0:

    while read -r line; do esearch -db nucleotide -query "$line"; echo "EXIT: $?"; done <  transcripts.list 
   <ENTREZ_DIRECT>
     <Db>nucleotide</Db>
     <WebEnv>MCID_61bb69e71191d1185543b24a</WebEnv>
     <QueryKey>1</QueryKey>
     <Count>1</Count>
     <Step>1</Step>
   </ENTREZ_DIRECT>
   

4. Isso está acontecendo em um sistema rodando Ubuntu, bash, versão 4.4.20(1)-release. Você pode instalar a efetchferramenta com sudo apt install ncbi-entrez-direct, se quiser experimentar isso.

5. Funciona conforme o esperado em um loop usando um idioma diferente. Por exemplo, em perl:

   $ perl -ne 'chomp;system("esearch -db nucleotide -query \"$_\"")' transcripts.list 
   <ENTREZ_DIRECT>
     <Db>nucleotide</Db>
     <WebEnv>MCID_61bb6c68d8f66e4bb03f00e8</WebEnv>
     <QueryKey>1</QueryKey>
     <Count>1</Count>
     <Step>1</Step>
   </ENTREZ_DIRECT>
   <ENTREZ_DIRECT>
     <Db>nucleotide</Db>
     <WebEnv>MCID_61bb6c69947ca95fce4d4f0f</WebEnv>
     <QueryKey>1</QueryKey>
     <Count>1</Count>
     <Step>1</Step>
   </ENTREZ_DIRECT>
   <ENTREZ_DIRECT>
     <Db>nucleotide</Db>
     <WebEnv>MCID_61bb6c6a85c14642940393f9</WebEnv>
     <QueryKey>1</QueryKey>
     <Count>1</Count>
     <Step>1</Step>
   </ENTREZ_DIRECT>
   

Eu tenho dois servidores, server1e server2, e posso me conectar server2via server1:

localUser@localMachine $ ssh user1@server1
user1@server1 $ ssh user2@server2
user2@server2 $

Eu posso fazer isso em uma etapa usando:

localUser@localMachine $ ssh -t user1@server1 ssh user2@server2
user2@server2 $

Eu quero ser capaz de simplesmente executar a ssh server2partir da minha máquina local e conectar diretamente. Eu poderia configurar o comando acima como um alias, mas prefiro fazer isso por meio do ~/.ssh/config. O problema é que preciso usar as credenciais ssh presentes no server1 ao conectar ao server2 e não quero copiá-las para minha máquina local. Isso significa que a maneira "normal" de configurar isso, adicionando o seguinte ao meu local ~/.ssh/config, falha:

Host server1
    Hostname  server1.example.com
    User      user1

Host server2
    Hostname  server2.example.com
    User      user2
    ProxyJump server1

Se eu tentar conectar agora, recebo:

$ ssh server2
[email protected]: Permission denied (publickey).

Isso ocorre porque preciso usar a ~/.ssh/id_rsa_pubchave server1e não a que tenho na minha máquina local. Então, como posso configurar meu local ~/.ssh/configpara que ele se conecte ao server2, via server1e usando as credenciais presentes no server1?

Todas as máquinas são caixas Linux, os controles remotos estão executando o Ubuntu Server 18.04.4 e minha máquina local está executando o Arch Linux.

Eu tentei a solução dada na resposta de Hauke ​​e adicionei o seguinte ao meu ~/.ssh/config:

Host server1server2
    Hostname server1
    User     user1
    RemoteCommand ssh [email protected]

Isso quase funciona! Agora posso me conectar server2usando ssh server1server2, mas não recebo um prompt:

localUser@localMachine $ ssh server1server2 
Pseudo-terminal will not be allocated because stdin is not a terminal.

hostname
server2

Como você pode ver acima, estou conectado server2e posso até executar comandos lá, mas não estou recebendo um prompt. Eu então tentei adicionar -t -tao sshcomando no arquivo de configuração:

Host server1server2
    Hostname server1
    User     user1
    RemoteCommand ssh -t -t [email protected]

Isso me deu um prompt, mas os arquivos de inicialização do meu shell não estão sendo lidos e pressionar Ctrl+ Cmata a sshconexão. Eu preciso que isso se comporte exatamente da mesma maneira como se eu tivesse feito ssh user2@server1e depois do server1 ssh user2@server2. Isso significa que meus arquivos normais de inicialização do shell devem ser lidos e um Ctrl + C não deve matar a sessão.

Encontrei uma resposta em outro site que estava sugerindo grep -oP '^\w+|$. Apontei que o |$é inútil no PCRE, pois significa apenas "OU fim de linha" e, portanto, sempre será verdadeiro para linhas regulares. No entanto, não consigo descobrir exatamente o que ele faz em GNU grepPCREs quando combinado com -o. Considere o seguinte:

$ printf 'ab\na\nc\n\n' | perl -ne 'print if /ab|$/'
ab
a
c

$

(Estou incluindo o segundo $caractere de prompt ( ) para mostrar que a linha vazia está incluída nos resultados).

Como esperado, em Perl, isso corresponderá a todas as linhas. Ou porque contém um abou porque $corresponde ao final da linha. O GNU grepse comporta da mesma maneira sem o -osinalizador:

$ printf 'ab\na\nc\n\n' | grep -P 'ab|$'
ab
a
c

$

No entanto, -oaltera o comportamento:

$ printf 'ab\na\nc\n\n' | grep -oP 'ab|$'
ab
$

Isso é o mesmo que simplesmente grepping para ab. A segunda parte, o "OU fim de linha" parece ser ignorada. Funciona como esperado sem o -osinalizador:

O que está acontecendo? - oignora correspondências de comprimento 0? Isso é um bug ou é esperado?

Por vários anos, o rmutilitário GNU não será excluído /, a menos que seja chamado com a --no-preserve-rootopção. No entanto, o comando rm -rf /foi alojado no subconsciente coletivo como perigoso por muito tempo e as pessoas ainda o citam como um comando "assustador".

Eu queria saber quando essa regra que rmnão pode excluir /apareceu pela primeira vez. Eu verifiquei as especificações do POSIX e posso ver que, embora o POSIX:2008 inclua esse recurso de segurança, o POSIX:2001 não. Como as versões online das especificações do POSIX são atualizadas de tempos em tempos, a cada novo sub-lançamento, também verifiquei a máquina de retorno e encontrei a página relevante do POSIX:2008 de 2010 e pude confirmar que a regra que rmnão pode remover /já estava listado então.

Então, minhas perguntas são:

• Quando a regra que rmnão pode ser removida foi /adicionada às especificações POSIX? Ele estava na edição original de 2008 da Single UNIX Specification versão 4 ou foi adicionado em uma revisão?
• Quando essa limitação foi adicionada ao GNU rm? Tenho certeza de que foi antes de ser adicionado ao POSIX, mas quando isso aconteceu?