Quando procuro phanno meu arquivo hunspell-dic /usr/share/hunspell/de_DE_frami.dic, recebo uma lista de palavras, incluindo
cellophan/Sozm
cellophan/hke
cellophan/ozm
glaukophan/EPSozm
Onde encontro documentação, o que significam os sufixos? Procurei uma página de manual para hunspell, mas só encontrei uma não útil para atualizar-dictcommon-hunspell. man dict?também não ajudou.
Eu gosto de salvar todo histórico no bash em uma espécie de arquivo de log e criei um diretório extra ~/lib/hists/ para esse propósito.
Escrever tal arquivo de log no shell é fácil:
history -w /home/stefan/lib/hists/bash-hist-$(date +%F_%T_%N)
Agora, se eu desligar, todos os xterms de fechamento devem gravar seu arquivo de log, e é por isso que incluo o nanotime no nome do arquivo, para evitar colisão.
Então eu coloquei esse comando em ~/.bash_logout
Infelizmente, fechar um xterm não gerou esse arquivo de log. Pensei, talvez porque seja porque fechei a janela. Então comece o bash no bash:
bash
ls
exit
mas, novamente, nenhuma história escrita.
Na maioria das vezes, tenho de 4 a 6 terminais abertos, mas apenas um arquivo de histórico para o qual não sei, quais comandos estão terminando ali - do primeiro shell aberto, do último shell fechado? Durante o trabalho, os históricos não interferem, então acho que está vinculado apenas a uma instância do shell.
Estou interessado em explicações, por que minha abordagem falha, como posso corrigi-la, incluindo abordagens muito diferentes.
Tenho problemas para entender a correspondência do padrão de string com =~ em bash .
Eu escrevi a seguinte função (não se assuste - é apenas uma experiência, não uma abordagem de segurança com md5sum):
md5 () {
[[ "$(md5sum $1)" =~ $2* ]] && echo fine || echo baarr;
}
e testei com alguma entrada. Aqui alguma referência:
md5sum wp.laenderliste
b1eb0d822e8d841249e3d68eeb3068d3 wp.laenderliste
É desnecessariamente difícil comparar, se a fonte para a soma de controle não contiver os dois espaços em branco com o nome do arquivo já. É daí que vêm as observações, mas mais interessante do que as muitas maneiras de resolver esse problema foi a minha observação:
Eu defino uma variável de controle e testo minha função com strings muito curtas, mas correspondentes:
ok=b1eb0d822e8d841249e3d68eeb3068d3
for i in {29..32}; do md5 wp.laenderliste ${ok:1:$i} ;done
fine
fine
fine
fine
Isso é esperado e bom, já que é o propósito da função, ignorar a incompatibilidade do "wp.laenderliste" ausente e, portanto, incompatibilidades ainda mais longas.
Agora, se eu acrescentar coisas aleatórias, que não correspondem, espero, é claro, erros e os obtenho:
for i in {29..32}; do md5 wp.laenderliste ${ok:1:$i}GU ;done
baarr
baarr
baarr
baarr
Como esperado. Mas quando há apenas um, último caractere incompatível , veja o que acontece:
for i in {29..32}; do md5 wp.laenderliste ${ok:1:$i}G ;done
fine
fine
fine
fine
Sou eu, não percebendo como isso deveria funcionar (a seleção está quebrada), ou há realmente um erro de erro por um na correspondência de padrão do bash?
Incompatibilidades no meio da string importam desde a contagem 1:
for i in 5 9 e ; do echo md5 wp.laenderliste ${ok//$i/_} ;done
md5 wp.laenderliste b1eb0d822e8d841249e3d68eeb3068d3
md5 wp.laenderliste b1eb0d822e8d84124_e3d68eeb3068d3
md5 wp.laenderliste b1_b0d822_8d841249_3d68__b3068d3
for i in 5 9 e ; do md5 wp.laenderliste ${ok//$i/_} ;done
fine
baarr
baarr
A versão bash:
bash -version
GNU bash, Version 4.3.48(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
Lizenz GPLv3+: GNU GPL Version 3 oder jünger <http://gnu.org/licenses/gpl.html>
Isenção de responsabilidade : md5sum é útil apenas contra erros não intencionais, não contra ataques. Eu não incentivo o uso.
E esta questão não é uma busca por melhores soluções ou soluções alternativas. É sobre o Operador =~ , se ele deve agir como age e, em caso afirmativo, por quê.