Existe alguma desvantagem de configurar 'noclobber'?

Question

Dado que zsh pode atacar todos os arquivos com o comando:

>*

Estou pensando que definir a opção noclobber seria uma boa ideia.

Eu sempre posso usar >| file se eu quiser usar o comportamento padrão do clobber tanto no bash quanto no zsh. (zsh também permite a sintaxe alternativa >!file ).

Eu estou supondo que noclobber esteja desabilitado por padrão por causa da compatibilidade POSIX, mas só para ter certeza:

Há alguma desvantagem na configuração de noclobber ?

Existe alguma maneira de definir noclobber apenas para o shell interativo?

    

Answer 1

O motivo noclobber não é definido por padrão é tradição. Como uma questão de design da interface do usuário, é uma boa idéia fazer com que “crie este novo arquivo” a ação fácil e colocar um obstáculo extra na ação mais perigosa “criar um novo arquivo ou substituir um arquivo existente”. Portanto, noclobber é uma boa idéia ( > para criar um novo arquivo, >| para potencialmente sobrescrever um arquivo existente) e provavelmente teria sido o padrão se o shell tivesse sido projetado algumas décadas depois.

É altamente recomendável usar o seguinte no seu arquivo de inicialização do shell interativo ( .bashrc ou .zshrc ):

set -o noclobber
alias cp='cp -i'
alias mv='mv -i'

Em cada caso (redirecionamento, cópia, movimentação), o objetivo é adicionar um obstáculo extra quando a operação pode ter o efeito colateral de apagar alguns dados existentes, embora apagar os dados existentes não seja o objetivo principal da operação. Eu não coloco rm -i nesta lista porque apagar dados é o objetivo principal de rm .

Observe que noclobber e -i são redes de segurança . Se eles dispararem, você fez algo errado. Portanto, não os use como desculpa para não verificar o que está sobrescrevendo! O ponto é que você deveria ter verificado que o arquivo de saída não existe. Se você disser file exists: foo ou overwrite 'foo'? , isso significa que você cometeu um erro e deve se sentir mal e ser mais cuidadoso. Em particular, não tenha o hábito de dizer y se for solicitado a sobrescrever (sem dúvida, os aliases devem ser alias cp='yes n | cp -i' mv='yes n | mv -i' , mas pressionar Ctrl + C faz a saída parece melhor): se você quisesse sobrescrever, cancele o comando, mova ou remova o arquivo de saída e execute o comando novamente.

Também é importante não ter o hábito de acionar essas seguranças, porque, se o fizer, um dia você estará em uma máquina que não tem sua configuração e perderá dados porque as proteções que estava contando não estão lá.

noclobber só será definido para shells interativos, já que .bashrc ou .zshrc é lido apenas por shells interativos. É claro que você não deve alterar as opções do shell de uma maneira que afete os scripts, já que isso poderia quebrar esses scripts.

    

Answer 2

A configuração da opção noclobber shell em ~/.bashrc (para bash ) ou ~/.zshrc (ou mais precisamente $ZDOTDIR/.zshrc , para zsh ) o tornará ativo em sessões de shell interativas.

Shells não interativos (scripts) não lêem esses arquivos.

As opções de shell normalmente não são herdadas de shells pai.

Isso significa que você deve ser capaz de definir a opção nesses arquivos sem modificar o comportamento em scripts existentes, a menos que os scripts forneçam explicitamente esses arquivos.

A única desvantagem de fazer isso é que você vai esquecer repetidamente que você definiu a opção, pelo menos no começo. Posteriormente, como acontece com todo esse tipo de coisa, você começará a usar habitualmente >| , mesmo nos casos em que você realmente não queira destruir o arquivo (como pessoas com aliases para rm , cp e mv com a opção -i sempre definida, eventualmente comece a usar sempre -f na linha de comando).

    

Answer 3

A desvantagem é que, se você se acostumar a ter noclobber ativo, um dia usará um sistema em que ele não está ativo e executará alegremente um comando potencialmente perigoso, esperando o noclobber para te salvar ... e não vai. E então você terá que esperar que haja um backup recente suficiente para recuperar os dados que você destruiu, porque você assumiu que seria solicitado a você a confirmação primeiro.