"Sh" precisa estar no diretório "/ bin"?

Eu li que os sistemas operacionais compatíveis com POSIX (por exemplo: Linux) devem ter o shshell.

Mas é necessário shestar no /bindiretório ou pode estar em qualquer diretório?

linux shell posix

— user270294
fonte

Você sempre pode usar um link simbólico /bin/sh, pois , na maioria dos casos, no linux, ele já é um link simbólico para bash. É que muitos scripts usam /bin/sh

— códigos

Agora que você tem a resposta de que ela pode morar onde quiser, você pode se perguntar: como você pode escrever uma linha shebang sh? E a resposta é: shebang também não faz parte do POSIX, então o problema nem se apresenta.

— Jörg W Mittag

@ JörgWMittag Sim, às vezes é surpreendente quantas das coisas que consideramos recursos Unix "padrão" não são realmente exigidas pelo POSIX.

— Barmar

Se você usa ou não um shebang, é independente se o caminho /bin/shdeve existir em um sistema POSIX.

— chepner

Pelo menos em sistemas derivados do Ubuntu, /bin/shé um link para dash. Nos BSDs, /bin/shnão é um link, mas um executável separado, e certamente não bash.

— Rhialto apoia Monica

Respostas:

POSIX única exige o /deve /tmpdiretórios de existir , e os /dev/null, /dev/ttye /dev/consolearquivos. Os utilitários padrão devem existir, mas não há um local específico especificado. Pode não haver um /bine, se houver, pode não conter um she, se houver, pode não ser um POSIX sh.

Você pode obter uma PATHvariável válida que inclui as ferramentas POSIX, incluindo sh, com o getconfcomando :

$ PATH=$(getconf PATH)
$ sh

Isso pode ser útil, por exemplo, no Solaris, onde o padrão shnão é compatível com POSIX , mas um compatível shé fornecido e acessível dessa maneira (porque o Solaris é um Unix certificado ). getconf PATHincluirá /usr/xpg4/binna frente, que contém o POSIX she várias outras ferramentas necessárias ( incluindocd ferramentas inúteis como ).

— Michael Homer
fonte

Re Solaris: ... a menos que você esteja executando uma instalação de "pequeno servidor" do Solaris, que omite muitas das ferramentas POSIX. Veja unix.stackexchange.com/q/360359/135943

— curinga

"Inúteis"? Prefiro chamá-los de redundantes.

— Mukesh Sai Kumar

Então, como o getconf é encontrado?

— Joshua

@MukeshSaiKumar um comando 'cd' stand-alone não pode nunca trabalho

— OrangeDog

Bem, "funcionará" apenas por um valor de trabalho que, digamos, testa se você pode mudar para um diretório, mas na verdade não deixa o processo que o chamou lá. Essa é mais funcionalidade do que nenhuma.

— Charles Duffy

Não, não é necessário shestar presente /bin. Ele explicitamente cita /bin, /usr/bine /usr/xpg4/bincomo possíveis localizações. A especificação POSIX requer apenas que shesteja no PATH.

A especificação POSIX declara:

Os aplicativos devem observar que o PATH padrão para o shell não pode ser assumido como um /bin/shou /usr/bin/sh, e deve ser determinado pela interrogação do PATH retornado pelo getconf PATH, garantindo que o nome do caminho retornado seja um nome de caminho absoluto e não um shell interno.

Por exemplo, para determinar a localização do utilitário sh padrão:

command -v sh

Em algumas implementações, isso pode retornar:

/usr/xpg4/bin/sh

— John1024
fonte

Como outros aqui disseram, isso não é estritamente necessário para conformidade com o POSIX.

Mas, sem dúvida, a compatibilidade com o software existente é muito mais importante (afinal, o objetivo do POSIX é fazer com que certas coisas funcionem em todos os sistemas operacionais em conformidade) e, se um sistema operacional não fornecer sh /bin/sh, isso quebrará algumas coisas.

Obviamente, scripts com #!/bin/shbase nesse caminho estão sendo padronizados. Isso não é necessário para o trabalho; O POSIX nem exige que as #!linhas sejam suportadas, embora mencione que essa funcionalidade é comum :

Outra maneira que algumas implementações históricas lidam com scripts de shell é reconhecendo os dois primeiros bytes do arquivo como a cadeia de caracteres "#!" e usando o restante da primeira linha do arquivo como o nome do interpretador de comandos a ser executado.

Mas se isso não for suportado, muitos softwares existentes serão interrompidos ou exigirão trabalho adicional para serem portados.

— Ian D. Scott
fonte