All perguntas(unix)

 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

Eu preciso apagar discos rígidos com segurança de tempos em tempos e usei uma variedade de ferramentas para fazer isso:

• cat /dev/zero > /dev/disk
• cat /dev/urandom > /dev/disk
• shred
• badblocks -w
• DBAN

Todos eles têm em comum o fato de levarem séculos para serem executados.

Em um caso cat /dev/urandom > /dev/diskmatou o disco, aparentemente superaquecendo-o.

Existe uma abordagem "boa o suficiente" para conseguir que quaisquer dados no disco sejam inutilizados em tempo hábil? Sobrescrever superblocos e alguns blocos estrategicamente importantes ou algo assim?

Os discos (tanto giratórios quanto ssd) vêm de computadores doados e serão usados ​​para instalar Linux-Desktops neles posteriormente, entregues a pessoas que não podem comprar um computador, mas precisam de um.

Os discos dos computadores doados geralmente não foram criptografados. E às vezes os doadores nem pensam em excluir os arquivos antes.

Atualização :

Das respostas que chegaram até agora, parece que não há atalhos. Minha melhor aposta é provavelmente configurar um computador de laboratório para apagar vários discos de uma só vez. Mais um motivo para pedir doações a grandes empresas :-)

Obrigado a todos!

Quero ter certeza de que entendi o seguinte código:

tar xvzf FILE --exclude-from=exclude.me --strip-components 1 -C DESTINATION

que foi postado nesta resposta .

De man tar:

--strip-components=NUMBER
retire NUMBER componentes principais de nomes de arquivos na extração

-C, --directory=DIR
mude para o diretório DIR

Não entendi a explicação do manual para --strip-components.

Sobre -C, entendi que significa algo como "colocar componentes despojados em um diretório notável".

O que --strip-components -Csignifica?

Quais são os diferentes métodos para executar um executável não-nixos no NixOs? (Por exemplo, binários proprietários.) Eu gostaria de ver também os métodos manuais.

Usar um comando para iniciar e habilitar systemctlsoftware gerenciado seria útil para poupar algumas linhas em alguns scripts, tornando-os um pouco mais estéticos (não é realmente um problema, mas uma coisa boa de se ter).

Existe um systemctlcomando para ambos starte enableum programa controlado por systemctl?

Eu tenho um arquivo iso chamado ubuntu.iso.

Eu posso mountcom o comando: mount ubuntu.iso /mnt. Depois de montá-lo, posso vê-lo fora do comando df -h: /dev/loop0 825M 825M 0 100% /mnt.

No entanto, se eu executar o comando mount -o loop ubuntu.iso /mnt, obterei o mesmo resultado.

Como eu sei, o dispositivo de loop nos permite visitar o arquivo iso como um dispositivo, acho que é por isso que adicionamos a opção -o loop. Mas eu posso visitar meu arquivo iso mesmo se eu apenas executar mount ubuntu.iso /mnt.

Então não consigo ver a diferença entre mounte mount -o loop.

Em um script Bash, estou tentando armazenar as opções que estou usando rsyncem uma variável separada. Isso funciona bem para opções simples (como --recursive), mas estou tendo problemas com --exclude='.*':

$ find source
source
source/.bar
source/foo

$ rsync -rnv --exclude='.*' source/ dest
sending incremental file list
foo

sent 57 bytes  received 19 bytes  152.00 bytes/sec
total size is 0  speedup is 0.00 (DRY RUN)

$ RSYNC_OPTIONS="-rnv --exclude='.*'"

$ rsync $RSYNC_OPTIONS source/ dest
sending incremental file list
.bar
foo

sent 78 bytes  received 22 bytes  200.00 bytes/sec
total size is 0  speedup is 0.00 (DRY RUN)

Como você pode ver, passar --exclude='.*'para rsync"manualmente" funciona bem ( .barnão é copiado), não funciona quando as opções são armazenadas em uma variável primeiro.

Suponho que isso esteja relacionado às aspas ou ao curinga (ou ambos), mas não consegui descobrir exatamente o que está errado.

Brian Kernighan explica neste vídeo a atração inicial do Bell Labs por pequenas linguagens/programas baseados em limitações de memória

Uma máquina grande teria 64 k-bytes - K, não M ou G - e isso significava que qualquer programa individual não poderia ser muito grande, e então havia uma tendência natural de escrever programas pequenos, e então o mecanismo de pipe, basicamente o redirecionamento de entrada e saída, tornou possível vincular um programa a outro.

Mas não entendo como isso pode limitar o uso de memória, considerando o fato de que os dados precisam ser armazenados na RAM para transmitir entre os programas.

Da Wikipédia :

Na maioria dos sistemas do tipo Unix, todos os processos de um pipeline são iniciados ao mesmo tempo [ênfase minha], com seus fluxos adequadamente conectados e gerenciados pelo agendador junto com todos os outros processos em execução na máquina. Um aspecto importante disso, separando os pipes Unix de outras implementações de pipe, é o conceito de buffer: por exemplo, um programa de envio pode produzir 5.000 bytes por segundo, e um programa de recebimento pode aceitar apenas 100 bytes por segundo, mas não dados são perdidos. Em vez disso, a saída do programa de envio é mantida no buffer. Quando o programa receptor estiver pronto para ler os dados, o próximo programa no pipeline fará a leitura do buffer. No Linux, o tamanho do buffer é de 65.536 bytes (64 KB). Um filtro de terceiros de código aberto chamado bfr está disponível para fornecer buffers maiores, se necessário.

Isso me confunde ainda mais, pois isso anula completamente o propósito de pequenos programas (embora eles sejam modulares até uma certa escala).

A única coisa que posso pensar como uma solução para minha primeira pergunta (as limitações de memória sendo problemáticas dependendo do tamanho dos dados) seria que grandes conjuntos de dados simplesmente não eram computados na época e os pipelines de problemas reais deveriam resolver era o quantidade de memória exigida pelos próprios programas. Mas dado o texto em negrito na citação da Wikipedia, até isso me confunde: como um programa não é implementado de cada vez.

Tudo isso faria muito sentido se os arquivos temporários fossem usados, mas é meu entendimento que os pipes não gravam no disco (a menos que a troca seja usada).

Exemplo:

sed 'simplesubstitution' file | sort | uniq > file2

Está claro para mim que sedestá lendo o arquivo e cuspindo-o linha por linha. Mas sort, como BK afirma no vídeo vinculado, é um ponto final, então todos os dados precisam ser lidos na memória (ou é?), então são passados ​​para uniq, o que (na minha opinião) seria um -programa linha por vez. Mas entre o primeiro e o segundo pipe, todos os dados têm que estar na memória, não?

Eu tenho um controlador de processo baseado em Linux que ocasionalmente trava até o ponto em que você não pode fazer ping nele (ou seja, eu posso fazer ping nele, então ele não pode mais fazer ping sem nenhuma modificação nas configurações de rede).

Estou curioso, qual processo/sistema é responsável por realmente responder aos pings? Parece que este processo está falhando.

Como posso remover uma unidade da systemctl --failedlista sem reiniciar a máquina?

Antecedentes: Tenho, entre outros, a seguinte entrada na lista:

● [email protected] loaded failed failed OpenVPN service for intranert

Isso aconteceu porque escrevi errado intranet, que é a instância produtiva real, na ativação do modelo de unidade há algum tempo. No entanto, agora sempre fico confuso à primeira vista, quando verifico as unidades com falha do servidor, pois parece que o serviço produtivo realmente falhou até que eu reconheça o erro de ortografia e me lembre do meu erro de digitação antigo.