unix

Pelo que entendi, o número de CPUs no meu computador deve ser dado por

CPU = Thread(s) por núcleo x Núcleo(s) por soquete x Soquete(s)

Aqui estão as primeiras linhas da lscpusaída:

$ lscpu | head -n18
Architecture:             x86_64
CPU op-mode(s):         32-bit, 64-bit
Address sizes:          46 bits physical, 48 bits virtual
Byte Order:             Little Endian
CPU(s):                   22
On-line CPU(s) list:    0-21
Vendor ID:                GenuineIntel
Model name:             Intel(R) Core(TM) Ultra 7 155H
CPU family:           6
Model:                170
Thread(s) per core:   2
Core(s) per socket:   16
Socket(s):            1
Stepping:             4
CPU(s) scaling MHz:   14%
CPU max MHz:          4800.0000
CPU min MHz:          400.0000
BogoMIPS:             5990.40

O que está acontecendo? 2 × 16 = 32, não 22. Mesmo em execução, nproc --allmostra 22.

Estou esquecendo de alguma coisa?

Estou executando o kernel 6.12.10 e nas profundezas do meu log do dmesg, encontrei estas entradas:

kernel: ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
kernel: ata4.00: Model 'INTEL SSDSCKJF360A5L', rev 'LT2i', applying quirks: zeroaftertrim
kernel: ata4.00: ACPI cmd f5/00:00:00:00:00:a0(SECURITY FREEZE LOCK) filtered out
kernel: ata4.00: supports DRM functions and may not be fully accessible
kernel: ata4.00: ATA-10: INTEL SSDSCKJF360A5L, LT2i, max UDMA/133
kernel: ata4.00: 703282608 sectors, multi 0: LBA48 NCQ (depth 32), AA
kernel: ata4.00: Features: Trust Dev-Sleep
kernel: ata4.00: ACPI cmd f5/00:00:00:00:00:a0(SECURITY FREEZE LOCK) filtered out
kernel: ata4.00: supports DRM functions and may not be fully accessible
kernel: ata4.00: configured for UDMA/133
kernel: scsi 3:0:0:0: Direct-Access     ATA      INTEL SSDSCKJF36 LT2i PQ: 0 ANSI: 5
kernel: sd 3:0:0:0: Attached scsi generic sg0 type 0
kernel: sd 3:0:0:0: [sda] 703282608 512-byte logical blocks: (360 GB/335 GiB)
kernel: sd 3:0:0:0: [sda] Write Protect is off
kernel: sd 3:0:0:0: [sda] Mode Sense: 00 3a 00 00
kernel: sd 3:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
kernel: sd 3:0:0:0: [sda] Preferred minimum I/O size 512 bytes
kernel:  sda: sda1 sda2 sda3 sda4 sda5 sda6
kernel: sd 3:0:0:0: [sda] Attached SCSI disk

O que significam as seguintes mensagens?

• supports DRM functions and may not be fully accessible
• read cache: enabled, doesn't support DPO or FUA

O que DRM significa neste contexto? (Duvido que signifique gerenciamento de direitos digitais.) Essas mensagens estão relacionadas?

Essas mensagens parecem ser novas. Não me lembro de tê-las visto antes. Mas não sei desde qual versão do kernel elas começaram a aparecer.

No Linux, RHEL-8.10 ou posterior, se for importante, eu gostaria de escrever algum código C que receba vários parâmetros e, sob uma determinada condição, emita um system("init 0")para desligar o sistema. Antes de emitir o desligamento, gostaria de lançar uma mensagem de uma linha nesse /var/log/messagessistema informando que o sistema foi desligado pelo código de Ron para que eu tenha um registro de quando isso aconteceu.

Como você escreve corretamente /var/log/messages?

Obviamente eu posso fazer um fopen("/var/log/messages, "a")e um simples, fprintfmas isso parece um pouco complicado.

Isso está relacionado, mas acredito que não seja uma duplicata, de " Por que não consigo definir a data das minhas máquinas GNU/Linux para a Época? ".

Descobri que um dos meus kernels Linux rejeita tentativas de acertar o relógio para um horário durante os primeiros seis minutos após a época:

root@beaglebone:/# date 010100061970
date: cannot set date: Invalid argument
Thu 01 Jan 1970 12:06:00 AM UTC
root@beaglebone:/# date 010100071970
Thu 01 Jan 1970 12:07:00 AM UTC

Mas sete minutos depois da época funciona bem.

Alguém tem alguma ideia de por que isso pode acontecer? Quando tiver oportunidade, verificarei as fontes do kernel em busca de pistas.

(Não, não é uma questão prática, apenas curiosidade e, portanto, talvez mais adequada para retrocomputing.se ou algo assim. Minha tentativa de acertar o relógio dessa maneira foi um erro, e o kernel me fez um favor ao rejeitá-la. Mas, ainda assim, é estranho.)

Sei por outras evidências que a rejeição não está acontecendo no datecomando, mas no próprio kernel. O settimeofdaysyscall está retornando -1, com errno definido como EINVAL.

Isso ocorreu em um sistema Debian 10 executando o kernel 4.19.94-ti-r42.

Eu também tentei em uma máquina Debian 11, kernel 5.10.179-1, e ele se comportou de forma semelhante, embora a "região proibida" fosse de dois meses inteiros no início de 1970 - não consegui definir uma data antes de março 1.

Atualização: Não apenas a pergunta foi respondida, mas o pequeno mistério estranho também foi resolvido, ou seja, por que diferentes máquinas nas quais testei tinham comportamentos diferentes. A primeira máquina em que testei havia sido reinicializada recentemente e não me permitia definir o tempo para um valor inferior a sete minutos após a época. Mas a segunda máquina estava em funcionamento há alguns meses e não me permitia definir a hora para uma data anterior a março - isto é, não dentro dos primeiros dois meses após a época. Mas isso faz sentido, porque uma maneira de declarar a restrição é que você não pode ter (tempo desde 1970) menor que (tempo desde a inicialização).

Estou na zona da UE +1 ou quando o horário de verão está ativado, +2. Agora é domingo, 31.3.2024. Na manhã deste domingo, mudamos para horário de verão, às 2→3 ( CET → CEST ).

Tenho servidores Linux em redes separadas informando o consumo mensal de energia às 23h58 do último dia do mês. Eles funcionaram perfeitamente por muitos anos. As redes estão separadas por até 8 horas de viagem!

Cada servidor possui um RTC e sincroniza o NTP regularmente. Existem muitas proteções caso algo seja suspeito, e três servidores principais em cada rede verificam constantemente entre si se tudo, incluindo a hora, está OK. Sim, sou paranóico. Não tolero nenhum (0) bug. Meus sistemas funcionam perfeitamente estáveis ​​por muitos anos. Funcionou, desculpe.

Ontem à noite, às 23h58 do dia 30 de março, todos os meus servidores Raspberry Pi decidiram que o dia 30 de março será seguido pelo dia 1º do próximo mês! Verifiquei de 7 (sete) maneiras diferentes e independentes por cada rede, que tudo realmente ocorreu no dia 30 de março no minuto 23h58! A confirmação inclui 9 dispositivos separados que ignoram o horário de verão, além de um provedor de correio externo dos EUA e da UE.

Às 23h58 de cada dia, meus servidores fazem um teste bash que aparentemente pode dar errado de várias maneiras:

(( $(date -d tomorrow +"%-d") == 1 )) && ZadnjiDanMjeseca=1 || ZadnjiDanMjeseca=""

Não vejo nenhuma maneira desse teste dar errado! Espero estar errado. Neste momento em 31.3.2024. Tudo funciona perfeitamente bem e o zdump está correto! (O exemplo a seguir parece formatado incorretamente para mim. Deve haver quatro linhas distintas mostradas.)

hwclock; date; date -d tomorrow +"%-d"
2024-03-31 19:22:23.311664+02:00
ned, 31.03.2024.  19:22:23 CEST
1

A única maneira de explicar esse problema é: A distribuição Linux que uso, Raspbian , de alguma forma tem duas funções de kernel separadas para calcular o tempo. Um deles, infelizmente, não percebeu que este é um ano bissexto! Ups!

Mas, em caso afirmativo, por que deveria ser limitado a esta versão e kernel do sistema operacional Raspberry Pi? Inferno, a Microsoft não conseguiu fazer o Excel calcular os anos bissextos corretamente!

Durante este fim de semana, vi várias instituições (bancos, a nossa administração fiscal nacional...) no meu país tendo problemas relacionados com datas e fechando a loja também, por isso parece não estar limitado ao Raspbian.

Isso vai contra mim como programador, mas não consigo encontrar nenhuma explicação alternativa. Espero que eu esteja errado...

Antes de postar, mudei das 23h58 para as 00h03 do dia 1º, e onde devo registrar os dados às 23h58 do último dia do mês, faço o teste adicionando 300 segundos, não pedindo +1 dia. Essas soluções devem funcionar.

Portanto, não está enterrado nos comentários: como nunca uso esses cálculos, cometi um erro básico ao esperar que “amanhã” na verdade significa amanhã! Não faz nenhum sentido para mim; significa +1 dia. Então, esperava que esses dois comandos produzissem a mesma saída:

> date -d 'next tue'
uto,  2.04.2024.  00:00:00 CEST

> date -d 'tomorrow'
uto,  2.04.2024.  10:24:55 CEST

em vez de ter que digitar:

date -d "tomorrow 0"

Comecei a estudar código C antigo (Unix v6) e estou me perguntando qual a finalidade de um single #no início do .carquivo. Por exemplo, em https://github.com/lsahn-gh/unix-v6/blob/master/sys%2Fken%2Falloc.c

#
/*
 */

#include "../param.h"
#include "../systm.h"
#include "../filsys.h"
...

Resumidamente, tenho um endereço físico dentro do kernel (9.932.111.872 ou 0x250000000), que aparentemente está alinhado a 4kB (tamanho da página). Quando uso a __va()função do kernel para obter o endereço virtual do kernel , recebo algo como 0xf570660f(diferente em cada inicialização), que não está alinhado a 4kB .

Estou em um sistema de 64 bits, então não há HIGHMEM e pensei que, devido ao modelo de memória liner, um endereço virtual de um endereço físico alinhado a 4kB também deveria ser alinhado a 4kB. Perdi algo? O endereço virtual não deveria ser phys_addr + PAGE_OFFSET? Ou é a influência do sparsemem? Mas talvez também deva ser alinhado a 4kB?

Aqui estão mais detalhes:

Meu ambiente de trabalho está em uma VM QEMU x86 de 64 bits. Estou tentando usar um PMEM no DEV-DAXmodo como memória normal. Posso obter o endereço inicial físico dele ( 0x250000000), que foi confirmado como correto. Então preciso transferi-lo para o endereço virtual no espaço do kernel para poder usá-lo conforme necessário. Aqui está um código:

static long nvpc_map_whole_dev(struct dax_device *dax_dev, void **kaddr, pfn_t *pfn)
{
    // get the device
    struct dev_dax_nvpc *dax_nvpc = (struct dev_dax_nvpc *)dax_get_private(dax_dev);
    
    // get the virtual address and the pfn_t
    *kaddr = __va(dax_nvpc->phys_start);
    *pfn = phys_to_pfn_t(dax_nvpc->phys_start, PFN_MAP);
    
    pr_info("[NVPC DEBUG]: paddr %#llx kaddr %p pfn %lu\n", dax_nvpc->phys_start, *kaddr, pfn_t_to_pfn(*pfn));
    pr_info("[NVPC DEBUG]: kaddr-paddr %#llx\n", __pa(*kaddr));
    return PHYS_PFN(dax_nvpc->size);
}

E aqui está o resultado que obtive:

Mostrado na linha marcada, o paddr dax_nvpc->phys_start, e o pfn, estão ambos certos. Mas o kaddr(endereço virtual) é confuso para mim. Então, quando transfiro de kaddrvolta para o endereço físico (a próxima linha de saída), o resultado fica correto.

Além do mais, posso fazer qualquer operação na memória de kaddraté kaddr + dax_nvpc->size, não há falha de página.

Alguém poderia me dizer por que o endereço virtual não está alinhado a 4kB? Estou sendo um idiota em algum lugar? Além disso, posso fazer algo para garantir que o endereço virtual também esteja alinhado a uma página?

Eu corri isso:

cat /usr/bin/* |
  perl -ne 'map {$a{$_}++} split//; END{print map { "$a{$_}\t$_\n" } keys %a}' |
  grep --text . | sort -n | plotpipe --log y {1}

e consegui isso:

(Mesmo com um log do eixo y, ainda parece exponencial! Há mais de 100x entre o topo e o fundo)

Olhando para os números:

:
31919597        ^H
32983719        ^B
33943030        ^O
39130281        \213
39893389        $
52237360        \211
53229196        ^A
76884442        \377
100776756       H
746405320       ^@

Não é de surpreender que ^@ (NUL) seja o byte mais comum em executáveis. \377 (255) e ^A (1) também fazem sentido intuitivamente para mim.

Mas o que faz com que 'H' (72) seja o segundo byte mais comum em executáveis ​​- muito mais comum que 255 e 1?

$ seq 10 | unbuffer -p od -vtc
0000000   1  \n   2  \n   3  \n   4  \n   5  \n   6  \n   7  \n   8  \n

Para onde foi 9e 10foi?

$ printf '\r' | unbuffer -p od -An -w1 -vtc
  \n

Por que foi \ralterado para \n?

$ : | unbuffer -p printf '\n' | od -An -w1 -vtc
  \r
  \n
$ unbuffer -p printf '\n' | od -An -w1 -vtc
  \r
      \n

O que é isso?

$ printf foo | unbuffer -p cat
$

Por que nenhuma saída (e um atraso de um segundo)?

$ printf '\1\2\3foo bar\n'  | unbuffer -p od -An -w1 -vtc
$

Por que não há saída?

$ (printf '\23'; seq 10000) | unbuffer -p cat

Por que ele trava sem saída?

$ unbuffer -p sleep 10

Por que não consigo ver o que digito (e por que é descartado mesmo sleepsem ter lido)?

Aliás, também:

$ echo test | unbuffer -p grep foo && echo found foo
found foo

Como foi grepencontrado foo, mas não imprimiu as linhas que o contêm?

$ unbuffer -p ls /x 2> /dev/null
ls: cannot access '/x': No such file or directory

Por que o erro não foi para /dev/null?

Veja também Unbuffer convertendo todos os caracteres em sino?

$ echo ${(l[10000][foo])} | unbuffer -p cat | wc -c
4095

Isso é com:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux trixie/sid
Release:        n/a
Codename:       trixie
$ uname -rsm
Linux 6.5.0-3-amd64 x86_64
$ expect -c 'puts "expect [package require Expect] tcl [info patchlevel]"'
expect 5.45.4 tcl 8.6.13
$ /proc/self/exe --version
zsh 5.9 (x86_64-debian-linux-gnu)

O mesmo no Ubuntu 22.04 ou no FreeBSD 12.4-RELEASE-p5 (exceto que os odcomandos precisam ser adaptados lá, e eu recebo 2321 (todos os caracteres BEL lá) em vez de 4095 acima).

No Linux, parece que o tempo do sistema de arquivos está sempre alguns milissegundos atrás do tempo do sistema, levando a inconsistências se você quiser verificar se um arquivo foi modificado antes ou depois de um determinado tempo em intervalos de tempo muito estreitos (milissegundos).

Em qualquer sistema Linux com um sistema de arquivos que suporte resolução de nanossegundos (tentei com ext4 com inodes de 256 bytes e ZFS), se você tentar fazer algo como:

date +%H:%M:%S.%N; echo "hello" > test1; stat -c %y test1 | cut -d" " -f 2

o segundo valor de saída (hora de modificação do arquivo) está sempre alguns milissegundos atrás do primeiro (hora do sistema), por exemplo:

17:26:42.400823099
17:26:42.395348462

enquanto deveria ser o contrário, já que o arquivo test1é modificado após chamar o datecomando.

Você pode obter o mesmo resultado em python:

import os, time

def test():
    print(time.time())
    with open("test1", "w") as f:
        f.write("hello")
        print(os.stat("test1").st_mtime)

test()

1698255477.3125281
1698255477.3070245

Por que é tão? E existe uma maneira de evitá-lo, para que a hora do sistema seja consistente com a hora do sistema de arquivos? A única solução alternativa que encontrei até agora é obter o "tempo" do sistema de arquivos (seja lá o que isso signifique na prática) criando um arquivo temporário fictício e obtendo seu horário de modificação, assim:

def get_filesystem_time():
    """
    get the current filesystem time by creating a temporary file and getting
    its modification time.
    """
    with tempfile.NamedTemporaryFile() as f:
        return os.stat(f.name).st_mtime

mas me pergunto se existe uma solução mais limpa.

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?

Existem muitas constantes no Kernel nomeadas comHORKAGE ,

• ATA_HORKAGE_ZERO_AFTER_TRIM
• ATA_HORKAGE_NODMA
• ATA_HORKAGE_ATAPI_MOD16_DMA
• ATA_HORKAGE_NO_DMA_LOG
• ATA_HORKAGE_NO_ID_DEV_LO
• ATA_HORKAGE_NO_LOG_DIR
• ATA_HORKAGE_WD_BROKEN_LPM

No entanto, estes não são realmente documentados

Force horkage de acordo com libata.force e reclame sobre isso. Para consistência com a seleção do link, o dispositivo número 15 seleciona o primeiro dispositivo conectado ao link do host.

O que significa "horkage"?

"Sim, e..." é uma regra prática maravilhosa na comédia improvisada. Não tanto no mundo UNIX.

Quando executo o yes&comando reconhecidamente bobo, não consigo interrompê-lo. O terminal trava ou fica preso em um loop.

Espero que o yesprocesso seja suspenso imediatamente, pois qualquer processo em segundo plano deve ser suspenso se tentar gravar no stdout, mas não parece ser o caso e estou me perguntando o porquê.

Meu empregador está localizado na Europa (CET) e, portanto, usamos o horário de verão, o que requer uma mudança de uma hora duas vezes por ano. Nossos servidores estão rodando na nuvem em diferentes locais. O funcionário que montou toda a infraestrutura se foi. Ele decidiu usar UTC como fuso horário do sistema em todos os servidores (atualmente Ubuntu 18.04, 20.04 e 22.04).

Isso não é o ideal, porque você precisa adicionar mentalmente 1/2 hora a cada data que vê em um arquivo de log, dependendo da época do ano (+2 horas no verão, +1 hora no inverno). O tempo de alguns cronjobs também precisa ser ajustado duas vezes ao ano, porque as tarefas devem ser executadas ao meio-dia CET.

Existe algum bom motivo para (ainda) usar UTC como fuso horário do sistema? Ou devo mudar para CET, para que meus cronjobs e arquivos de log se alinhem melhor com o relógio de parede?

Sim, eu sei o que você está pensando: "Quem diabos nomeia seu arquivo `a`b?"

Mas vamos supor que você tenha um arquivo chamado `a`b(possivelmente feito por um usuário maluco do Mac - obviamente não por você), e você deseja rsyncisso. A solução óbvia:

rsync server:'./`a`b' ./.;
rsync 'server:./`a`b' ./.;

dá:

bash: line 1: a: command not found
rsync: [sender] link_stat "/home/tange/b" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1865) [Receiver=3.2.7]
rsync: [Receiver] write error: Broken pipe (32)

Até:

$ rsync 'server:./\`a\`b' ./.;
bash: line 3: a\: command not found
rsync: [sender] link_stat "/home/tange/\b" failed: No such file or directory (2)
:

Qual é o rsynccomando que devo executar?

$ rsync --version
rsync  version 3.2.7  protocol version 31

Se eu definir a escala de 175% nas configurações do Gnome, o valor será salvo como 1.7518248558044434em ~/.config/monitors.xml:

<monitors version="2">
  <configuration>
    <logicalmonitor>
      <x>0</x>
      <y>0</y>
      <scale>1.7518248558044434</scale>
      <primary>yes</primary>
      <monitor>
        <monitor spec>
          <connector>DP-3</connector>

Por que é tão? A princípio, pensei que poderia ser devido a um erro de arredondamento de ponto flutuante, mas 1,75 é um daqueles números felizes cujo valor exato pode ser expresso.

Gnomo Wayland 43.3

Quando um sistema Linux hiberna e sai da hibernação, acho que o kernel precisa saber que está retomando, não inicializando. Caso contrário, o kernel iniciará o processo de inicialização normal e não carregará os dados trocados. Como o kernel sabe que está retomando?

A princípio, pensei que o GRUB (ou outro gerenciador de inicialização) informa o kernel pelos parâmetros do kernel. Mas, desde que eu verifique /proc/cmdline, os parâmetros do kernel são os mesmos de sempre. Existe algum mecanismo para o kernel saber que está retomando?

 July 2022      mac os Monterey V12.1 
   awk --version 20200816
   GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin21)

Por que awk -Ffunciona para a maioria das letras, mas NÃO para a letra t? Eu tenho a solução, mas gostaria de entender porque o awk falha para a letra t.

# Count 'e's
% echo "tweeter" | awk -F "e" '{print NF-1}'
3

# Count 'r's
% echo "tweeter" | awk -F "r" '{print NF-1}'
1

# (Attempt to) count 't's
% echo "tweeter" | awk -F "t" '{print NF-1}'
0   <=== ????

# Use gsub()
% echo "tweeter" | awk '{print gsub(/t/, "")}'
2

Não consigo excluir um arquivo com rm -rf /home/wordpress/testDomain.comda minha máquina Linux. Em vez do arquivo ser excluído, recebo um Operation not permittederro. Como posso consertar isso?

$ cd /home/wordpress/testDomain.com/wp-content/plugins/sitepress-multilingual-cms/vendor/otgs
$ sudo rm -f annmanagement
rm: cannot remove 'annmanagement': Operation not permitted
$ ls -al
total 3308
drwxr-xr-x 2 www-data www-data    4096 May 27 13:43 .
drwxr-xr-x 3 www-data www-data    4096 May 27 13:46 ..
-r-------- 1 root     root     3375768 Dec 27  2016 annmanagement

$ sudo find . -inum 535255 -exec rm -i {} \;**
rm: remove regular file './annmanagement'? y
rm: cannot remove './annmanagement': Operation not permitted


$ lsattr
----i---------e----- ./annmanagement

$ stat annmanagement
  File: annmanagement
  Size: 3375768         Blocks: 6600       IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 535255      Links: 1
Access: (0400/-r--------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2022-05-27 09:02:30.650849241 +0200
Modify: 2016-12-27 10:48:37.000000000 +0100
Change: 2022-03-15 07:59:42.524922372 +0100
 Birth: -

Saída de linha:

$ sudo strace rm -f annmanagement**
execve("/bin/rm", ["rm", "-f", "annmanagement"], 0x7ffc24e45690 /* 13 vars */) = 0
brk(NULL)                               = 0x55cd820a2000
arch_prctl(0x3001 /* ARCH_??? */, 0x7ffe7894d320) = -1 EINVAL (Invalid argument)
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=42697, ...}) = 0
mmap(NULL, 42697, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f8c5d386000
close(3)                                = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300A\2\0\0\0\0\0"..., 832) = 832
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
pread64(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0", 32, 848) = 32
pread64(3, "\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\30x\346\264ur\f|Q\226\236i\253-'o"..., 68, 880) = 68
fstat(3, {st_mode=S_IFREG|0755, st_size=2029592, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8c5d384000
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
pread64(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0", 32, 848) = 32
pread64(3, "\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\30x\346\264ur\f|Q\226\236i\253-'o"..., 68, 880) = 68
mmap(NULL, 2037344, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8c5d192000
mmap(0x7f8c5d1b4000, 1540096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7f8c5d1b4000
mmap(0x7f8c5d32c000, 319488, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19a000) = 0x7f8c5d32c000
mmap(0x7f8c5d37a000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e7000) = 0x7f8c5d37a000
mmap(0x7f8c5d380000, 13920, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f8c5d380000
close(3)                                = 0
arch_prctl(ARCH_SET_FS, 0x7f8c5d385580) = 0
mprotect(0x7f8c5d37a000, 16384, PROT_READ) = 0
mprotect(0x55cd80c6a000, 4096, PROT_READ) = 0
mprotect(0x7f8c5d3be000, 4096, PROT_READ) = 0
munmap(0x7f8c5d386000, 42697)           = 0
brk(NULL)                               = 0x55cd820a2000
brk(0x55cd820c3000)                     = 0x55cd820c3000
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3035952, ...}) = 0
mmap(NULL, 3035952, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f8c5ceac000
close(3)                                = 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
newfstatat(AT_FDCWD, "annmanagement", {st_mode=S_IFREG|0400, st_size=3375768, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(AT_FDCWD, "annmanagement", 0)  = -1 EPERM (Operation not permitted)
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2996, ...}) = 0
read(3, "# Locale name alias data base.\n#"..., 4096) = 2996
read(3, "", 4096)                       = 0
close(3)                                = 0
openat(AT_FDCWD, "/usr/share/locale/en_US.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en_US.utf8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en_US/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en.utf8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale-langpack/en_US.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale-langpack/en_US.utf8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale-langpack/en_US/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale-langpack/en.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale-langpack/en.utf8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale-langpack/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, "rm: ", 4rm: )                     = 4
write(2, "cannot remove 'annmanagement'", 29cannot remove 'annmanagement') = 29
openat(AT_FDCWD, "/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale-langpack/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale-langpack/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale-langpack/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale-langpack/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale-langpack/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale-langpack/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, ": Operation not permitted", 25: Operation not permitted) = 25
write(2, "\n", 1
)                       = 1
lseek(0, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
close(0)                                = 0
close(1)                                = 0
close(2)                                = 0
exit_group(1)                           = ?
+++ exited with 1 +++

Acabei de aprender um truque para criar um novo arquivo com o catcomando. Pelos meus testes, se a última linha não for seguida por uma nova linha, terei que digitar ctrl+dduas vezes para finalizar a entrada, conforme demonstrado abaixo.

[root@192 ~]# gato > teste
uma
b
ctrl+d[root@192 ~]# gato > teste
uma
b ctrl+dctrl+d[root@192 ~]#

Isso é esperado? Por que esse comportamento?