All perguntas(unix)

Eu tenho um arquivo de texto sendo processado em uma máquina Windows. É necessário remover os caracteres de tabulação antes de usar bcpo utilitário para carregar os dados do arquivo em uma tabela de banco de dados.

O seguinte comando, em um script Bash, retirou as guias à direita:

sed 's/[\t]*$//' < ./input/raw.txt >> ./input/data.txt

mas converteu o CR- LFpara LFo qual causou bcpa falha do comando.

Em um esforço para manter o CR- LFeu tentei isso:

sed 's/[\t]*$/$CR/' < ./input/raw.txt >> ./input/data.txt

mas isso resultou em:

O resultado desejado é:

Como faço para modificar o comando para obter a saída desejada?

Relacionado: Como obter o nome do terminal atual?

Mas eu quero apenas o ID do terminal atual, por exemplo, quando ttyretornar /dev/pts/11, quero apenas imprimir 11.

A ideia é adicionar essa informação no prompt do shell após o nome de usuário \una PS1variável do meu .bashrcarquivo:

Resultado desejado:username11@localhost:~$

No momento tenho:

PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u$(tty)@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '

que dá:username/dev/pts/11@localhost:~$

Percebi que os navegadores Firefox e Chromium no Linux abrem o arquivo /proc/self/mempara leitura. Nenhum outro programa em meu sistema lê este arquivo, até onde eu sei.

/proc/self/memé notório por ser vetor de exploits de escalonamento de privilégios sem fim, onde geralmente a memória é substituída por código malicioso e a execução do programa é sequestrada.

Isso é ainda mais triste, já que os navegadores são os programas mais expostos, com a maior superfície de ataque, porque recebem entradas não confiáveis ​​da Internet.

Existe uma razão legítima para que os navegadores modernos precisem ler /proc/self/mem?

Nunca vi ncdu fazer isso. Qual é o problema com as Scolunas vermelha e de tamanho extra?

Esta é uma raiz do Windows (NTFS, montada com ntfs-3g), então presumo que tenha algo a ver com NTFS. Mas os tamanhos na coluna extra não fazem sentido algum, nem consigo encontrar nenhuma documentação do que isso significa.

Curiosamente, apenas os diretórios têm a segunda coluna de tamanho, mas nem todos a têm. E não encontro padrão entre os que fazem e os que não fazem.

Lugares que pesquisei:

• man ncdu
• Google

Eu me deparei com este pedaço de código daqui :

#!/bin/bash

# ...

if [[ "${1-}" =~ ^-*h(elp)?$ ]]; then
    echo "Usage..."
    exit
fi

Entendo que isso imprime as informações de uso quando qualquer argumento como -h, --help, -help, -------helpé passado.

Mas por que "${1-}"e não apenas "${1}"? O que o hífen faz?

A princípio pensei que poderia significar qualquer argumento da posição 1 em diante. Eu tentei e não, não era isso.

Então pensei que poderia ser um erro de digitação e o autor pretendia "${1-9}"permitir todas as posições numéricas. Novamente, não funcionou, nem é um código válido.

Em awk, o primeiro argumento para as funções sub()e gsub(), o segundo argumento para a match()função e o terceiro argumento opcional para split(), é uma expressão regular estendida.

Esse argumento pode ser uma expressão arbitrária avaliada como uma string interpretada como uma expressão regular ou pode ser uma constante de expressão regular.

Em awk, uma constante de expressão regular é escrita /RE/para alguma expressão regular RE(um " EREtoken" na awkgramática).

Pergunta: Supondo que REpermaneça o mesmo (alguma expressão regular não variável), há alguma diferença prática entre using /RE/e using "RE"(um " STRINGtoken" na awkgramática) em uma chamada para, por exemplo, sub()? Como alternativa: Existe alguma awkimplementação conhecida que faça diferença entre essas duas formas de representar uma expressão regular em uma chamada para as funções mencionadas acima?

O motivo da pergunta é que me lembro de ter que modificar algum awkcódigo que tentei usar "RE"como expressão regular em uma chamada para sub()ou gsub(), porque, por qualquer motivo, a awkimplementação em questão fez a coisa errada, a menos que eu chamasse a função com /RE/.

Infelizmente, isso foi há algum tempo (mais de 2 anos), então não me lembro dos detalhes e não tenho certeza de qual Unix eu usava na época (possivelmente OpenBSD), mas desde então venho querendo fazer a pergunta.

O código a seguir fará com que a instrução 'if' saia antecipadamente e não execute o comando 'echo' no bloco 'if'. Estou me perguntando por que isso acontece apenas no bloco 'if', mas não na parte principal do script. Observação: entendo que alterar ':=' para ':-' resolverá o problema - não estou procurando corrigir o problema, estou procurando entender a diferença entre o ambiente de execução do bloco 'if' que faz com que isso aconteça em primeiro lugar.

#!/bin/bash

if true; then
        VAR=${$1:='val'}
        echo "This does not run"
fi


VAR=${$1:='val'}
echo "This does run"

A saída é

line 4: ${$1:='val'}: bad substitution
line 7: ${$1:='val'}: bad substitution
This does run

Novamente - não estou interessado em corrigir a mensagem de erro de substituição incorreta, entendo como fazer isso e por que isso acontece. O que eu quero entender é porque a echo "This does not run"linha não roda quando há uma substituição ruim acima dela em um bloco 'if'.

Reproduzido nas seguintes versões bash:

GNU bash, versão 5.1.16(1)-release (x86_64-pc-linux-gnu)

GNU bash, versão 4.2.46(2)-release (x86_64-redhat-linux-gnu)

Por que ainda posso ssh na minha máquina Ubuntu usando uma senha? Este é o /etc/ssh/sshd_configarquivo do meu Ubuntu 20.04 na hospedagem da ovh (mostrando apenas as linhas não comentadas para abreviar):

Include /etc/ssh/sshd_config.d/*.conf
Port xxx
PermitRootLogin no
AllowUsers      user1 user2
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys .ssh/authorized_keys2
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
PrintMotd no
AcceptEnv LANG LC_*
Subsystem       sftp    /usr/lib/openssh/sftp-server

As permissões dos arquivos relevantes parecem estar OK:

$ stat -c %a /home/user1/.ssh/
700

$ stat -c %a /home/user1/.ssh/authorized_keys`
600

Eu corri sudo service ssh restarte sudo service sshd restart.

Por que ainda consigo fazer login na minha máquina Ubuntu por senha no ssh? Consigo logar por usuário e senha pelo ssh (PuTTY), ele só pede senha. Ambos user1 e user2 têm suas chaves na pasta inicial .ssh. O que está faltando?

Eu verifiquei o arquivo de inclusão:

-rw------- 1 root root   27 Dec  1 12:52 50-cloud-init.conf
...:/etc/ssh/sshd_config.d$ sudo cat 50-cloud-init.conf
PasswordAuthentication yes

então eu acho que é a causa? No entanto, minha configuração não substituiria essa configuração? uma vez que está incluído acima (em linha)?

Por que o uso de *(1)*remove tudo de um diretório? Então como selecionar todos os arquivos que tem (1)no meio do nome?

O comando usado é rm *(1)*ou rm -rf *(1)*(não lembro exatamente). Era o shell padrão do Ubuntu.

Estou usando Linux 5.15 com Ubuntu 22.04.

Eu tenho um processo que usa muita memória. Requer mais memória do que tenho RAM na minha máquina. A primeira vez que o executei, foi morto pelo OOM Killer. Eu entendo isso: o sistema ficou sem memória, o OOM Killer foi acionado, meu processo foi encerrado. Isso faz sentido. Também tenho certeza de que foi isso que aconteceu: dei uma olhada dmesge está tudo lá.

Então eu adicionei algum espaço de troca. Não me importo se esse processo demorar muito para ser executado: não o executarei com frequência.

Executei o processo novamente. Desta vez, funcionou por mais tempo do que da primeira vez. Todo o sistema ficou muito lento, daquele jeito que os sistemas ficam quando estão trocando muito. Parecia estar funcionando... e então morreu. Não apenas o processo morreu, mas o processo shell que era seu pai também morreu, e o processo Tmux que era seu pai, e o processo shell que era pai do processo Tmux, e até mesmo o processo do terminal GNOME que era seu pai ! Mas então o processo de assassinato parou: nenhum outro pai morreu.

A princípio, pensei que o OOM Killer havia sido acionado novamente - embora ainda houvesse muito espaço de troca disponível - e que ele havia escolhido encerrar o processo do terminal GNOME. Mas eu verifiquei dmesge journalctl -knão havia nada de novo lá. Não havia sinal de que o OOM Killer havia sido acionado.

Então, primeira pergunta: existe alguma circunstância em que o OOM Killer pode ser acionado sem registrar nada no buffer de anel do kernel?

Fiquei intrigado com o fato de que o kernel do Linux parecia ter começado a trocar, mas de alguma forma não havia trocado o suficiente... ou não havia trocado rápido o suficiente... ou algo assim.

Então eu aumentei vm.swappiness. Isso realmente não deve afetar a estabilidade do sistema: é apenas um botão para girar para otimizar o desempenho. Mesmo com o kernel vm.swappinessdefinido 0, ainda deve iniciar a troca quando a memória livre em uma zona cair abaixo de um limite crítico.

Mas parecia que tinha começado a trocar, mas não havia trocado o suficiente ... então aumentei vm.swappinesspara 100incentivá-lo a trocar um pouco mais.

Então eu executei o processo novamente. Todo o sistema ficou muito lento, daquela forma que os sistemas fazem quando estão trocando muito ... até que o processo seja executado com sucesso até a conclusão.

Então, segunda pergunta: por que o kernel não usou o espaço de troca disponível, mesmo quando a memória livre caiu abaixo do limite crítico e certamente havia muito espaço de troca disponível? Por que a mudança vm.swappinessfez a diferença?

Atualizar:

Testes adicionais revelaram que a configuração vm.swappinessnão é uma solução confiável. Eu tive algumas falhas mesmo com vm.swappinessset to 100. Isso pode melhorar as chances de o processo ser concluído com sucesso, mas não tenho certeza.