Чи повинен "sh" знаходитись у каталозі "/ bin"?

Я читав, що сумісні з POSIX операційні системи (наприклад: Linux) повинні мати shоболонку.

Але чи потрібно, shщоб воно було в /binкаталозі, чи воно може бути в будь-якому каталозі?

linux shell posix

— user270294
джерело

Ви завжди можете використовувати симпосилання, оскільки /bin/shв більшості випадків на Linux це вже посилання bash. Просто багато сценаріїв використовують жорстко /bin/sh

— кодовані

Тепер, коли у вас є відповідь, що вона може жити де завгодно, ви можете запитати себе: як тоді ви можете портативно написати рядок shebang sh? І відповідь така: shebang теж не є частиною POSIX, тому проблема навіть не представляється.

— Йорг W Міттаг

@ JörgWMittag Так, іноді дивно, що багато речей, які ми вважаємо "стандартними" функціями Unix, фактично не потрібні POSIX.

— Бармар

Чи ви використовуєте shebang чи ні, не залежить від того, чи /bin/shповинен існувати шлях у системі POSIX.

— чепнер

Принаймні, на системах, що походять з Ubuntu, /bin/shє посиланням на dash. Що стосується BSD, /bin/shце не посилання, а окремий виконуваний файл, і, звичайно, ні bash.

— Ріалто підтримує Моніку

Відповіді:

POSIX мандатів тільки /devі /tmpкаталоги існувати , і /dev/null, /dev/ttyі /dev/consoleфайли. Стандартні утиліти повинні існувати, але конкретного місця не вказано. Він може не бути /binзовсім, і якщо він є, він може не містити a sh, а якщо він є, це може бути не POSIX sh.

Ви можете отримати дійсну PATHзмінну, що включає інструменти POSIX, в тому числі sh, за допомогою getconfкоманди :

$ PATH=$(getconf PATH)
$ sh

Це може бути корисно, наприклад, у Solaris, де за замовчуванням shне сумісні POSIX , але сумісність shнадається та доступна таким чином (оскільки Solaris є сертифікованим Unix ). getconf PATHвключатиме в себе /usr/xpg4/binв передній, яка містить POSIX shі ряд інших необхідних інструментів ( в тому числі непотрібних з них , якcd ).

— Майкл Гомер
джерело

Re Solaris: ... якщо ви не працюєте з установкою "маленького сервера" Solaris, яка опускає багато інструментів POSIX. Дивіться unix.stackexchange.com/q/360359/135943

— Wildcard

"Марні"? Я вважаю, що я вважаю їх зайвими.

— Мукеш Сай Кумар

тож як можна знайти getconf?

— Джошуа

@MukeshSaiKumar автономна команда "cd" ніколи не може працювати

— OrangeDog

Ну, він буде "працювати" лише для значення роботи, яке, скажімо, перевіряє, чи можна змінити каталог, але насправді не залишає процес, який його там викликав. Це більше функціональності, ніж взагалі немає.

— Чарльз Даффі

Ні, це не потрібно для того, shщоб бути в /bin. Він прямо цитує /bin, /usr/binта /usr/xpg4/binяк можливі місця. Специфікація POSIX вимагає лише того, щоб він shбув у PATH.

Специфікація POSIX визначає:

Програми повинні зауважити, що стандартний PATH для оболонки не можна вважати рівним /bin/shабо /usr/bin/shі повинен визначатися шляхом допиту PATH, повернутого getconf PATH, гарантуючи, що повернене ім'я шляху є абсолютним іменем шляху, а не вбудованою оболонкою.

Наприклад, для визначення місцезнаходження стандартної утиліти sh:

command -v sh

У деяких реалізаціях це може повернутися:

/usr/xpg4/bin/sh

— John1024
джерело

Як уже говорили інші, це не суворо потрібно для дотримання POSIX.

Але, мабуть, сумісність із існуючим програмним забезпеченням набагато важливіша (адже мета POSIX полягає в тому, щоб певні речі працювали на всіх відповідних операційних системах), і якщо ОС не надає можливості /bin/sh, це порушить деякі речі.

Найбільш очевидно, що сценарії, які #!/bin/shпокладаються на цей шлях, стандартизуються. Це не потрібно для роботи; POSIX навіть не вимагає, щоб #!лінії підтримувалися, хоча він зазначає, що така функціональність є загальною :

Інший спосіб, яким деякі історичні реалізації обробляють сценарії оболонки, - це розпізнавання перших двох байтів файлу як символьного рядка "#!" і використовуючи залишок першого рядка файлу як ім'я інтерпретатора команд для виконання.

Але якщо це не підтримується, багато існуючого програмного забезпечення зламається або вимагає додаткової роботи для порту.

— Ян Д. Скотт
джерело