Por que a substituição de histórico bash ainda está ativada por padrão? [fechadas]

Question

Alguém sabe por que o bash ainda tem substituição de histórico ativado por padrão? Meu .bashrc incluiu set +H por muitos anos, mas algumas outras pessoas ainda estão sendo mordidas por esse recurso.

Dado que praticamente todos estão usando terminais com recursos de copiar e colar e bash compilados com readline library e a substituição do histórico é ativada por padrão apenas em shells interativos, Existe realmente algum motivo para ter o recurso em tudo? Nenhum dos scripts existentes seria quebrado mesmo se este fosse desativado por padrão para todos os shells.

Tente isso se você não souber porque a substituição do histórico foi interrompida:

$ set +H # disable feature history substitution
$ echo "WTF???!?!!?"
WTF???!?!!?
$ set -H # enable feature history substitution
$ echo "WTF???!?!!?"
echo WTF???echo WTF???!?!!?
WTF???echo WTF???!?!!?

(Claramente, o recurso tem grandes problemas se estiver desabilitado por padrão em todos os scripts e existe um recurso para verificar os resultados antes de executar: shopt -s histverify .)

Veja também:

• Por que o ponto de exclamação '! ' às vezes chateado bash?
• Por que o histórico do Bash não registra esse comando?
• Como ecoar um estrondo!
• Bash : Expansão do histórico dentro de aspas simples após uma aspa dupla dentro da mesma linha

Answer 1

Se você já está familiarizado com bash , então lidar com padrões de substituição de histórico não é muito mais provável do que manipular quaisquer outros caracteres que sejam especiais para este shell. No entanto, se alguém não estiver familiarizado com o shell ou simplesmente nunca usou seus recursos de substituição de histórico, obviamente será uma surpresa quando aparentemente inócuas seqüências de caracteres sem aspas ou com aspas duplas o acionarem.

Em um shell interativo com substituições de histórico ativadas, o caractere ! é especial praticamente da mesma maneira que o caractere $ é especial, ou seja, em todos os lugares, a menos que seja escapado com \ ou em strings com aspas simples. / p>

Ao contrário de $ through, as substituições de histórico não se expandem aqui-documents, e como elas são orientadas a linha, elas também acontecem em linhas onde a substituição cai dentro de um contexto sem aspas ou um contexto duplo citado (nessa linha quando digitalizado separadamente). Veja este relatório de erros para mais informações .

A substituição de histórico é desativada em shells não-interativos (scripts) porque o recurso de histórico de comandos do shell não é necessário lá, não porque o recurso possui "problemas maiores". Em um script, salvar todos os comandos em $HISTFILE não faz sentido, e a substituição de histórico também não é algo em que você gostaria de confiar em um script.

Se deve ou não ser ativado por padrão ou não em shells interativos pode ser debatido (embora eu não esteja totalmente convencido de que um debate aqui importaria muito para os desenvolvedores bash ). Você parece pensar que a maioria dos usuários de bash está tendo problemas com as expansões de histórico, mas nenhum de vocês e eu sabemos como é comum usá-los.

Unix shells permitem modificar o comportamento do shell para atender às necessidades e gostos pessoais. Se você quiser desativar as substituições de histórico de todos os seus shells interativos, continue fazendo o que está fazendo usando set +H no arquivo ~/.bashrc ou faça lobby dos desenvolvedores bash para alterar o padrão (que, acredito, seria chateado e confundir mais pessoas do que ajudaria).

    

Answer 2

A substituição do histórico é útil. Tomemos por exemplo

% make-me-a-sandwich
make-me-a-sandwich: Permission denied
% sudo !!
Ok.

    

Answer 3

Inércia social / cultural.

Esta questão está no espaço do problema how-humans-work, então vou responder a partir desse ângulo, sem dar nenhuma opinião sobre se o recurso deve ser ativado por padrão.

Para começar, para ter certeza de que você entende o outro lado, considere que o aborrecimento que você sente por ter que sair do seu caminho para desativar o recurso é o incômodo que eles sentiriam se eles teve que sair de seu caminho para ativar o recurso.

Combine o acima com o fato de que um número suficiente de usuários bash usa o recurso, sugestões de removê-lo ou desativá-lo por padrão são recebidos com resistência das pessoas que já estão confortáveis com ele por padrão.

Além disso, bash é o shell padrão para muitas pessoas (não apenas no login padrão ou no sentido do shell do sistema, mas em um sentido psicológico). Se o seu quadro de referência para o shell quoting for bash , se esse for o shell que você aprendeu primeiro, o fato de ! ser um caractere de shell especial parecerá natural e automático para você (ou, pelo menos, vai ser apenas parte da maneira como a casca é, apenas um capricho para aceitar entre muitos).

E se você pensar bem, muitos bash usuários provavelmente encontrarão a sintaxe de substituição de histórico em um contexto positivo : eles lêem sobre isso ou alguém mostra para eles e eles vêem o possível utilidade, quando eles estão aprendendo bash .

É apenas proveniente do mundo periférico de outras shells parecidas com Bourne, que você seria mordido por ! sendo especial e sendo assim inclinado a vê-lo negativamente: Porque se você é Se você está acostumado com shells onde você nunca teve o recurso, então sua primeira exposição será quando você estiver tentando fazer algo com pressa.

TL; DR: A maioria dos usuários provavelmente não se importa muito com o que é padrão , alguns usuários gostam do recurso e têm a grande vantagem de já ser assim, e não tem Há pessoas suficientes ativamente advogando contra o recurso para superar isso.

    

Answer 4

Why is bash history substitution still enabled by default?

Como muitas pessoas o usam, e pessoas que usam um shell bash interativo provavelmente devem conhecer as regras para evitar problemas e geralmente acham que isso ajuda mais do que dói.

My .bashrc has included set +H for many many years but some other people are still getting bitten by this feature.

Portanto, é um recurso que você não usa, o que não significa que a maioria dos usuários não o use. Você pode pedir que o padrão seja alterado, mas você tem que olhar para A) a porção de pessoas que se importam, e B a proporção de pessoas que preferem o seu caminho. As pessoas que cuidam e não gostam provavelmente já o desativaram. Mudá-lo ajudaria quando eles obtivessem uma conta em um novo computador. As pessoas que cuidam e gostam disso precisam atualizar as configurações em todos os computadores que usam e em todas as contas que receberem no futuro.

Given that pretty much everybody are using terminals with copy-paste features

Uma opção clunkier na minha opinião ...

is there really any reason to have the feature at all? None of the existing scripts would be broken even if this was disabled by default for all shells.

Sim, as pessoas acham útil. De que adianta ter um controle remoto dado que você costumava se levantar e mudar de canal?

(Clearly the feature has major issues if it's disabled by default for all scripting and a feature exists to verify the results before executing: shopt -s histverify.)

O histórico não faz sentido em scripts, mas, mais importante, pode causar problemas de segurança. No seu caso, você poderia evitar o problema usando aspas simples. Eu não me lembro disso sempre causando um problema para mim, então eu não sei como você pode dizer que tem "grandes problemas". Isso causou um problema real para você ou você ficou incomodado por ter que definir seus padrões em um novo computador?

Eu não vejo como é diferente de ter que escapar ou usar aspas simples se você realmente quiser algum dinheiro:

$ echo "Give me $50 or the cat gets it"
Give me $0 or the cat gets it