Existe alguma garantia de que / usr / bin / env existirá?

Muitas vezes, vejo scripts começarem com uma linha shebang usada #!/usr/bin/env interpreter_namepara qualquer intérprete, com a lógica de que sistemas diferentes podem ter o intérprete de que precisam para serem instalados em locais diferentes. Por exemplo, se eu assumir que pythonestá instalado como /usr/bin/pythonum usuário que decidiu instalá-lo /opt/pythonpor algum motivo, não será capaz de usá-lo tão facilmente.

Mas a pergunta óbvia é: existe alguma garantia que envserá instalada em /usr/bin/env(ou nesse local em particular), ou será apenas um caso de "mudar o problema", por assim dizer?

Esta questão um pouco relacionada tem um comentário que diz que é uma péssima idéia e é preferível instalá-la com o caminho real do intérprete e cita a especificação unix única, mas realmente não trata dessa questão.

scripting env

— scott_fakename
fonte

Não, envnão há garantia de entrada /usr/bin, como você pode ler no histórico do mecanismo shebang , na seção "O utilitário env":

No entanto, a localização do env (1) pode variar. Free-, Net-, OpenBSD e algumas distribuições Linux (por exemplo, Debian) só vêm com / usr / bin / env. Por outro lado, há apenas / bin / env pelo menos no SCO OpenServer 5.0.6 e Cray Unicos 9.0.2 (embora o último seja apenas de interesse histórico). Em algumas outras distribuições Linux (Redhat), ele está localizado em / bin e / usr / bin / contém um link simbólico apontando para ele.

Não move o problema completamente, devido à flexibilidade da envpesquisa $PATH. Se acontecer de você obter alguns scripts que usam um local diferente para envde seu, você unicamente tem que saber sobre onde suas envvidas, e não também onde perl, pythone outros intérpretes pode ser instalado.

E você não precisa codificar /opt/python/3.3.2/bin/python3.3se esse é o primeiro python3.3executável no seu PATH. Você pode apenas envencontrá-lo, para não precisar atualizar todos os scripts se atualizar para usar /opt/python/3.3.3/bin/python3.3. O cabeçalho do seu script permanece o mesmo:

#! /usr/bin/env python3.3

— Anthon
fonte

Aha. Obrigado. Não consegui encontrar nenhuma informação sobre isso. Quando eu disse "movendo" o problema, quis dizer que, em vez de procurar python perletc, agora você só precisa caçar env, o mesmo problema, mas um alvo diferente. Parece que envé muito mais fácil encontrar, e obviamente muito mais versátil, por isso ainda é muito favorável. O que responde perfeitamente à minha pergunta. Obrigado!

— scott_fakename 31/01