/bin/sh в каком пакете лежит?
Balancer 29 января, 2009 - 13:56
Собственно, сабж :)
Занялся тут чисткой cruft'а, удивился, что оно никакому пакету не принадлежит ни на одной из моих машин.
Не порядок...
»
|
|
|
Вход в аккаунтНавигацияОбсуждаемые темы
Новые записи в блогахСейчас на сайте0 пользователей и 5 гостей.
Сбор новостей |
/bin/sh в каком пакете лежит?
Balancer 29 января, 2009 - 13:56
Собственно, сабж :) Занялся тут чисткой cruft'а, удивился, что оно никакому пакету не принадлежит ни на одной из моих машин. Не порядок... » |
equery belongs /bin/sh По
equery belongs /bin/shПо врей видимости потерянный симлинк. По моим наблюдениям, этим portage грешит(л).
:wq
--
Live free or die
Нет, фишка в том, что этот
Нет, фишка в том, что этот симлик никому не принадлежит. (А так - есть и указывает на /bin/bash)
Но в системе быть просто обязан - масса скриптов его юзает.
Кроме него таких ещё немало.
Вот и интересно, кому же он должен принадлежать.
У меня и "qfile /bin/bash" и "equery belongs /bin/sh" выдают пустой результат.
Интересует - у кого иначе.
... чтобы понять рекурсию, нужно сперва понять рекурсию ...
У меня так же — ничей.
У меня так же — ничей.
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
/bin/sh никому не
/bin/sh никому не принадлежит, не удивлюсь если он создаётся правилами какого-нибудь скрипта. Указывает он на стандратный интерпретатор дистра. Нужен для совместимости скриптов с различными дистрами. Но чтобы скрипты были дистронезависимыми(говорю ест-но про скрипты написанные на языке командной оболчки) нужно писать их согласно POSIX и ставить вначале сигнатуру sha-bang -> #!/bin/sh.
abs-guide рулит ;)
Боюсь, эта ваша тирада никому
Боюсь, эта ваша тирада никому ничего нового не открыла (-:Е
Кстати, /usr/src/linux тоже никому не принадлежит
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
Скажу больше /usr/src/linux
Скажу больше /usr/src/linux не существует... по умолчанию, на новой системе и без флага symlink
Тем паче странно
Тем паче странно
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
Даже не знаю что и сказать.
Даже не знаю что и сказать. Почему вы сразу не ответили ту же мысль, что я описал ?
Если бы вы знали, не стали бы пробовать equery.
Я ответил на вопрос автору.
Офигеть, круто, а что такое linux ? Ваши слова донесли гораздо меньше для кого-то и новой информации чем мои.
И самое интересное :
Он как раз скрипты юзает.
Цитата:Даже не знаю что и
Потому что это вряд ли для кого-то новость.
Что бы я знал? Я исхожу из того, что любой файл в системе должен принадлежать какому-нибудь пакету.
В смысле — что такое linux?
Попрошу не обижаться впустую. Я никого не хотел задеть, просто изложенные мысли довольно-таки тривиальны и не особо относятся к теме. Вот придёт автор и что-нибудь скажет нам по этому поводу.
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
Цитата:Потому что это вряд ли
Но это вы всё же написали : Кстати, /usr/src/linux тоже никому не принадлежит
Так ведь тема создана и вопрос задан. Наверно кто-то из нас не верно понимает вопрос автора. Как видите не все файлы принадлежат пакету(ам). Насколья я понял, автора интересовал вопрос по поводу принадлежности /bin/sh к какому-либо пакету, что собственно я и объяснил - для чего пакет используется и что никому не принадлежит.
Вы выразились о моём посте №5, что он не принёс новой информации, следовательно вы в курсе про симлинк /bin/sh, именно это я и имел ввиду. А раз вы знаете, то зачем юзать equery ? Подтвердить мысли на практике ? Тогда извините, вопросов не будет.
По такому пустяковому вопросу да столько слов и времени...
итьб
Поскольку я немного знаю автора темы, подозреваю, что он в курсе, для чего нужен /bin/sh и чем он является. Равно как и большинство участников форума. Если файл является символьной ссылкой, то это не значит, что он не должен принадлежать какому-нибудь пакету. Поэтому автору темы и мне то обстоятельство, что некоторые ссылки как бы сами по себе, несколько удивительно.
Соответственно, из того, что я в курсе про символьноссылочную природу /bin/sh, никак не следует то, что мне незачем проверять его принадлежность к какому-либо пакету с помощью equery.
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
Хоть убейте меня, но я не
Хоть убейте меня, но я не вижу логики спрашивать имя президента Америки, если я его знаю.
Я объяснил несколько больше нежели только о символьноссылочной природе /bin/sh. Зная предназначение файла легко понять его непринадлежность к пакету(а вы написали что знали, отсюда и вопрос зачем проверять ?). Наверно вы всё-таки не вдумались в мой первый пост тут и нам нужно прекратить этот флайм.
Gentoo -- вообще удивительный дистр! =)))
Изначальное утверждение: "файлы принадлежат пакетам (в пакетной системе) либо пользователю" -- неверно! Взять к примеру /etc/init.d/net.ath0 или /etc/localtime -- чьи это файлы? Выходит, что они не системные, значит пользовательские. Но мы-то знаем, что это не совсем так. :) В том плане, что раз они относятся к настроенной системе, значит...
Нужно задаться вопросом: почему системный файл (директория, ссылка) иногда принадлежит не какому-то пакету, а вообще никому не принадлежит. Если сабж в этом, попробую рассудить "вслух"...
Это особенность не толко gentoo, но и других дистров, включая пакетные. Во-первых, потому, что пакетная система дистров (да даже portage gentoo) предусматривает фазу пост-инсталляции, где некий скрипт может сотворить в живой системе, что угодно. В gentoo это ещё усугубляется всевозможными eselect, gcc-config, etc... Во-вторых, есть например директории, куда могут складываться файлы конфигураций или файлы данных, котрые не входят в сам пакет при развёртывании. Они всё равно имеют отношение к работающей системе, а не к личным файлам пользователя, но тоже не принадлежат никакому пакету.
Если бы разработчики дистра (любого) захотели, они бы смогли обеспечить привязку каждого файла конкретному пакету. Но они этого не сделали. Откуда следует вывод, что все файлы на диске - это файлы пользователей и системные файлы, часть из которых принадлежит конкретным пакетам, тогда как другая часть не принадлежит никому И ОБ ИХ ЦЕЛОСТНОСТИ должен заботиться сам админ. Другой вывод заключается в том, что система - это не только набор пакетов в развёрнутом виде (последнее в меньшей степени относится к gentoo, ибо не пакетный дистр, а живая сборочная среда для создания не-пакетных дистров). В том смысле, что если развернуть из тарболов (или чего там?) все пакеты, цельно настроенной системы не получится.
Нужно принять, как данность. Иначе нужно работать в направлении, устраняющем эту данность!.. =)))
app-shells/bash/bash-3.2_p39.
app-shells/bash/bash-3.2_p39.ebuild :
...
pkg_postinst() {
# If /bin/sh does not exist, provide it
if [[ ! -e ${ROOT}/bin/sh ]]; then
ln -sf bash "${ROOT}"/bin/sh
fi
}
...
))
equery belongs /bin/bash
[ Searching for file(s) /bin/bash in *... ]
app-shells/bash-3.2_p48 (/bin/bash)
вопрос стоял откуда берется
вопрос стоял откуда берется /bin/sh. А /bin/bash и так понятно, что принадлежит bash-у
Мои пять копеек
В прошлый раз пробовал отвечать на автопилоте :)
Иногда и такое помогает... ;)
/bin/sh - это традиционное название стандартного командного интерпретатора Unix - Bourne Shell.
Где-то (например, из виденного лично - Solaris 8, FreeBSD) - он и есть, где-то (ЕМНИП ArchLinux) - его free клон.
Там же, где нет ни того, ни другого (Gentoo) принято назначение /bin/sh симлинком на бинарник шелла, совместимого с Bourne Shell. В данном конкретном случае - bash.
:wq
--
Live free or die
... совместимого с Bourne Shell...
Точнее сказать, умеющего по argv[0] определять, как он запущен.
И в случае имени /bin/sh работать не в нативном режиме (bash, zsh, etc..),
а в режиме совместимости с Bourne Shell... ;-)
А вот ни фига! ;)
Последнее требование избыточно.
И противоречит моему личному опыту (правда, эксперимент проводился немного с другой целью).
Совместимость же с Bourne Shell - один из пунктов ТЗ на разработку bash (про zsh не скажу).
Специальный режим здесь не нужен (хотя, в 3.Х может что и наворотили...) :)
:wq
--
Live free or die
Опять поспорить захотелось? :o
Изучай RTFM! ;-)
И вообще... щаз как народ понавалит!..
Хотя да, миллионы мух не могут ошибаться... =)))
Это Вы про себя? :)
Теория без практики мертва.
Если человек не хочет признавать факта, он его не признает. Сколько не пихай его носом в казалось бы очевидное.
Уроки Истории хдесь тоже бесполезны.
Утверждаешь - "совместимый режим"?
В таком случае я жду развёрнутого рассказа почему в Gentoo Linux скрипт формата
запускаемый посредством
./script.shработает, а на системе, где /bin/sh - бинарник Bourne Shell - не работает?!?:wq
--
Live free or die
> В таком случае я жду развёрнутого рассказа
У того, кто писал этот скрипт, просто не было возможности, времени или навыков отладить его на предмет переносимости. Вот и весь рассказ! Не так давно в gentoo community ещё шла "упорная борьба" по переводу скриптов на Bourne Shell - совместимость. И всё потому, что gentoo работает не только на i386, но и во встраиваемых системах, где Bash'а может просто не оказаться.
Насколько я понимаю изученное, bash в режиме sh - это на самом деле режим POSIX (bash --posix). Строгий режим (bash --restricted, sh -r) заставляет Bash быть ещё более строгим к соответствию SVR4.2 (соответствующий последней существовавшей версии Bourne Shell). При этом всё равно Bash является расширенной версией Bourne Shell, и хотя в этих "ограниченных" режимах многая функциональность меняется, авторам скриптов всё равно необходимо учитывать различия в целях переносимости. Начиная с того, что некоторые разновидности Unix (основанные на 4.2BSD) требуют, чтобы Sha-Bang состоял из 4х байт, за счет добавления пробела после "!": #! /bin/sh.
Вот основные отличия между Bash и Bourne Shell, но не все.
А вот ещё несколько ссылок по теме:
1. http://www.linuxjournal.com/article/2784
2. http://gazette.lrn.ru/rus/articles/abs-guide/c13694.html
3. http://citkit.ru/articles/1083/
Но главное, это man-страницы bash, sh, magic.
Я просто чуток скорректировал Вашу фразу, в направлении уточнения перевода с оригинала. ИМХО, так она прозвучала бы немного корректней. Bash действительно относится к поколению sh-совместимых оболочек, но это достигается путём принудительного режима ограничения функционала.
.
Или мотивации...
Т.е. Bourne, не смотря на прекращение разработки, и сейчас живее всех живых?
Соглашусь.
Совсем интересно.
Такие и сейчас есть или то - динозавры?
Я не возвожу чтение документации в самоцель.
И, честно говоря, не представляю чего с точки зрения функциональности стартового скрипта может не хватать в Bourne Shell.
За основу моего утверждения действительно взята цитата.
Но она корректировалась в соответствии с моим личным опытом.
Ещё интереснее... :)
Разве здесь есть много вариантов?
А csh хоть и, ЕМНИП, относится к поколению Bourne Shell; но никоим боком не является Bourne-совместимым шеллом.
:wq
--
Live free or die
И пошел флуд. Так что тред
И пошел флуд. Так что тред теперь заломинирован =)
___________________________________________
Working on Gentoo for iPAQ hx4700 and Openmoko Neo Freerunner :-)
Если у вас компьютер с Windows, есть два выхода: выбросить компьютер в форточку или выбросить форточки с компьютера