All perguntas(unix)

Estou procurando o equivalente zsh do comando bash history -c, em outras palavras, limpe o histórico da sessão atual. Em zsh history -cretorna 1 com uma mensagem de erro history: bad option: -c.

Só para esclarecer, não estou procurando uma maneira de excluir o conteúdo de $HISTFILE, só quero um comando para redefinir o histórico para o mesmo estado em que abri o terminal. Excluir o conteúdo de $HISTFILEfaz o oposto do que eu quero: ele exclui o histórico que quero preservar e preserva o histórico que quero excluir (já que o histórico da sessão atual seria anexado a ele, independentemente de seu conteúdo ter sido apagado anteriormente).

Há uma solução alternativa que uso por enquanto, mas obviamente não é o ideal: na sessão atual, defino HISTFILE=/dev/nulle apenas fecho e reabro o terminal. Isso faz com que o histórico da sessão fechada não seja anexado ao $HISTFILE. No entanto, eu realmente gostaria history -cde algo como bash, que é muito mais elegante do que ter que fechar e reiniciar o terminal.

Quando o Unix deixou de armazenar senhas de texto simples em passwd? Além disso, quando o arquivo shadow foi introduzido?

Depois de ler a resposta de ilkkachu a esta pergunta , aprendi sobre a existência do shell declare(com argumento -n) embutido.

help declaretraz:

Defina valores e atributos de variáveis.

Declare variáveis ​​e dê-lhes atributos. Se nenhum NOME for fornecido, exiba os atributos e valores de todas as variáveis.

-n ... torna NAME uma referência à variável nomeada por seu valor

Peço uma explicação geral com um exemplo a respeito declareporque não entendo o man. Eu sei o que é uma variável e expandi-la, mas ainda sinto falta do man( declareatributo variável?).

Talvez você queira explicar isso com base no código de ilkkachu na resposta:

#!/bin/bash
function read_and_verify  {
    read -p "Please enter value for '$1': " tmp1
    read -p "Please repeat the value to verify: " tmp2
    if [ "$tmp1" != "$tmp2" ]; then
        echo "Values unmatched. Please try again."; return 2
    else
        declare -n ref="$1"
        ref=$tmp1
    fi
}

Em algum momento, em algum material didático (da Linux Foundation) sobre Linux que encontrei, é mencionado o seguinte:

ipO comando é mais versátil e mais eficiente do que ifconfigporque usa soquetes netlink em vez de chamadas de sistema ioctl .

Alguém pode elaborar um pouco sobre isso, porque eu não consigo entender o que está acontecendo sob o capô?

PS Estou ciente deste tópico sobre essas ferramentas, mas não aborda essa diferença específica em como elas operam

Em um bashscript, preciso de vários valores de /proc/arquivos. Até agora eu tenho dezenas de linhas grepping os arquivos diretamente assim:

grep -oP '^MemFree: *\K[0-9]+' /proc/meminfo

Em um esforço para tornar isso mais eficiente, salvei o conteúdo do arquivo em uma variável e fiz isso:

a=$(</proc/meminfo)
echo "$a" | grep -oP '^MemFree: *\K[0-9]+'

Em vez de abrir o arquivo várias vezes, isso deve abri-lo apenas uma vez e grep o conteúdo da variável, que eu assumi que seria mais rápido - mas na verdade é mais lento:

bash 4.4.19 $ time for i in {1..1000};do grep ^MemFree /proc/meminfo;done >/dev/null
real    0m0.803s
user    0m0.619s
sys     0m0.232s
bash 4.4.19 $ a=$(</proc/meminfo)
bash 4.4.19 $ time for i in {1..1000};do echo "$a"|grep ^MemFree; done >/dev/null
real    0m1.182s
user    0m1.425s
sys     0m0.506s

O mesmo vale para dashe zsh. Suspeitei do estado especial dos /proc/arquivos como motivo, mas quando copio o conteúdo de /proc/meminfoum arquivo regular e uso que os resultados são os mesmos:

bash 4.4.19 $ cat </proc/meminfo >meminfo
bash 4.4.19 $ time for i in $(seq 1 1000);do grep ^MemFree meminfo; done >/dev/null
real    0m0.790s
user    0m0.608s
sys     0m0.227s

Usar uma string here para salvar o pipe o torna um pouco mais rápido, mas ainda não tão rápido quanto com os arquivos:

bash 4.4.19 $ time for i in $(seq 1 1000);do <<<"$a" grep ^MemFree; done >/dev/null
real    0m0.977s
user    0m0.758s
sys     0m0.268s

Por que abrir um arquivo é mais rápido do que ler o mesmo conteúdo de uma variável?

Vim 8.1 adicionou o :terminalcomando, que abre um novo terminal bash como uma divisão. No entanto, sempre parece ser uma divisão horizontal e prefiro divisões verticais. Existe uma maneira de abrir um terminal como uma divisão vertical sem usar:

:vsp
:terminal
<c-w>j
:q

Como alternativa, existe uma maneira de adicioná-lo como um comando no meu .vimrc , assim:

command Vterm :vsp | :terminal | <c-w>j | :q

O comando acima engasga ao tentar executar <c-w>j, abre uma nova divisão do vim com o seguinte:

falha na execução do trabalho: Arquivo ou diretório inexistente

Apenas tendo:

command Vterm :vsp | :terminal

Funciona bem, mas deixa a divisão original.

Eu tenho um arquivo binário e devo quebrar sua senha (lição de casa). Também foi fornecida uma função (uma função que faz parte do arquivo binário). Essa função mostrou que a string de entrada foi comparada com a senha correta caractere por caractere e retornou false instantaneamente quando um caractere estava errado (essa não é uma maneira segura de fazer isso, acho porque está vazando tempo e temos uma ideia do comprimento correto da senha como exemplo). Mas nosso professor adicionou um cronômetro aleatório que retorna o resultado (Correto / Errado) para tornar um pouco mais difícil para nós...

De qualquer forma, já fiz isso com sucesso com engenharia reversa e obtive a senha correta. Agora estou brincando com ele na linha de comando:

/usr/bin/time -v ./program_name enter_password

Com este comando, obtenho muitas informações como hora do sistema, trocas, tempo de execução. " Eu recebo!

Quanto mais caracteres errados eu inserir, mais "mudanças voluntárias de contexto" eu recebo.

Levei quase duas horas para quebrar a senha apenas digitando esse comando, inserindo caracteres e observando "Mudanças voluntárias de contexto". Sempre que UM caractere estava correto, as "mudanças de contexto voluntárias" diminuíam em um.

Minha pergunta, o que exatamente são "interruptores de contexto voluntários" e por que eles me ajudaram a quebrar a senha?

Eu tenho um script bash myhome.shcontendo apenas uma linha:

echo $HOME

O proprietário do script é um usuário:

$ ls -l myhome.sh
-rw-rw-r-- 1 user user <date> <time> myhome.sh

No Ubuntu 16.04 e 17.10 , recebo:

$ echo $HOME
/home/user

$ sudo echo $HOME
/home/user

$ bash myhome.sh
/home/user

$ sudo bash myhome.sh
/home/user

No Debian Buster/Testing eu recebo:

$ echo $HOME
/home/user

$ sudo echo $HOME
/home/user

$ bash myhome.sh
/home/user

# WHY ?
$ sudo bash myhome.sh
/root

Não entendo porque dentro do script no Debian, se for executado com sudo, sempre recebo $HOME=/rootenquanto no Ubuntu recebo $HOME=/home/user. Alguém sabe o que os desenvolvedores do Ubuntu mudaram?

Um aplicativo que estou usando não iniciará com esta mensagem de usuário:[Errno 13] Permission denied: '/home/sleblanc/.config/app/.config

Quando eu usei ls, o arquivo apareceu como tal:

?--------- 1 root root     0 Dec 31  1969 .config

Executar stat no arquivo me dá isso:

% stat .config
  File: .config
  Size: 0           Blocks: 0          IO Block: 4096   weird file
Device: 2dh/45d Inode: 9799944     Links: 1
Access: (0666/?rw-rw-rw-)  Uid: ( 1000/     sleblanc)   Gid: ( 1000/         sleblanc)
Access: 1969-12-31 19:00:00.000000000 -0500
Modify: 1969-12-31 19:00:00.000000000 -0500
Change: 2018-04-07 23:40:22.549653691 -0400

O mais surpreendente é a menção de um "arquivo estranho".

O que é um arquivo estranho?

Pelo que entendi, o hostsarquivo é um dos vários recursos do sistema que auxiliam no endereçamento de nós de rede em uma rede de computadores. Mas o que deve estar dentro dele? Quando eu instalo o Ubuntu por padrão

127.0.0.1 localhost 

estarei lá. Por quê?

• Como /etc/hostsfunciona no caso de sistemas JVM como Cassandra?
• Quando é a alternativa DNS, acho que não em um único computador?