Комментарии 39
За {} спасибо. Всю жизнь xargs использовал.
в мане это описано:
find. -type f -exec file '{}' \;
find. -type f -exec file '{}' \;
find.unixpin.com/ru/ Вот в помощь. Я много от туда подчерпнул, переодически пользуясь.
С тем же успехом можно использовать какой-нибудь kfind (если у вас кеды, или любой другой графический интерфейс к find, подходящий для вашего DE)… Веб-интерфейс к командной строке это жесть.
Это же помошник по команде, а не интерфейс к cli. Первое время у меня попросту небыло времени выучить весь синтаксис find.
Да я понял, но отличая от gui получаются лишь в том, что тут вам еще надо копировать команду в интерпретатор. Впрочем, конечно, некоторую образовательную функцию оно будет нести, но только в том случае, если пользователь будет вникать в то, что он копирует. В противном случае, лучше просто уж пользоваться gui.
НЛО прилетело и опубликовало эту надпись здесь
-exec: каждый раз делает запуск чайлда, иногда это дорого.
По-умолчанию — да. Но если использовать его в форме
-exec command {} +
то {} заменится на все найденные файлы, command будет запущена один раз.
xargs рулит только в случае если нужно сделать что-то вроде
|xargs -n 1 -P 2 -I '{}' sh -c 'oggenc -Q -q 7 "{}" && rm -fv "{}"'т.е. нужно запускать несколько инстансов command параллельно
Становится интересно ) присоединяюсь к предидущему посту про {} не знал )
кстати
$ export PATH=
А то мб для кого-то не очевидно )
кстати
$ export PATH=
А то мб для кого-то не очевидно )
Ээээ… куда ставить по этой иерархии неразделяемые несистемные пакеты?
Что вы понимаете под несистемными/системными пакетами? Это вам не freeBSD.
Я понимаю /opt и иже с ним.
Вы предлагает делить по месту компиляции или степени открытости кода?
Т.е. если я собрал пакет сам, то ставлю его в /usr/local?
А если тот же пакет получил бинарно — то в usr/opt?
Вы предлагает делить по месту компиляции или степени открытости кода?
Т.е. если я собрал пакет сам, то ставлю его в /usr/local?
А если тот же пакет получил бинарно — то в usr/opt?
Я ничего не предлагаю. Я говорю по факту имея маны, гугл, и арч с генту под рукой. Не вижу никаких проблем с пониманием куда чего ставить.
Когда вы написали про «несистемные» пакеты я вообще то подумал, что вы тонкий freebsd тролль. Ох уж как меня достало это понятие «системы» во фре. Разработчики freebsd считают, что им лучше пользователей известно, какие пакеты считать системными, а какие нет. В итоге мы имеем обязательную систему с громоздким dns-сервером bind на борту (ох да, что же это за система без dns-сервера), парочку ftp серверов (разной степени убогости), сэндмыл и еще кучка всячины. А за тем, что действительно нужно приходится постоянно лазить в /usr/local…
Cразу после установки фри выпиливается сендмыл, заменяется на связку exim + dovecot, затем bind меняется на nsd, а фтп валяется в двух экземплярах ненужный, ибо в наш век это жутко устаревший протокол, есть sftp, есть rsync. В итоге в системе остается кучка ненужного хламу, а все нужное живет в /usr/local. Вот такая вот «система» с «системными» пакетами в / и «несистемными» в /usr/local.
Когда вы написали про «несистемные» пакеты я вообще то подумал, что вы тонкий freebsd тролль. Ох уж как меня достало это понятие «системы» во фре. Разработчики freebsd считают, что им лучше пользователей известно, какие пакеты считать системными, а какие нет. В итоге мы имеем обязательную систему с громоздким dns-сервером bind на борту (ох да, что же это за система без dns-сервера), парочку ftp серверов (разной степени убогости), сэндмыл и еще кучка всячины. А за тем, что действительно нужно приходится постоянно лазить в /usr/local…
Cразу после установки фри выпиливается сендмыл, заменяется на связку exim + dovecot, затем bind меняется на nsd, а фтп валяется в двух экземплярах ненужный, ибо в наш век это жутко устаревший протокол, есть sftp, есть rsync. В итоге в системе остается кучка ненужного хламу, а все нужное живет в /usr/local. Вот такая вот «система» с «системными» пакетами в / и «несистемными» в /usr/local.
А если через менеджер пакетов — то куда авторы дистрибутива захотели? :)
А если у меня пакет свободный, то в usr/opt. Как OpenOffice, например.
Но если пакет не свободный, то в /opt — как StarOffice :) :) :)
Вы, дорогой товарищ, как-то определитесь :)
А если у меня пакет свободный, то в usr/opt. Как OpenOffice, например.
Но если пакет не свободный, то в /opt — как StarOffice :) :) :)
Вы, дорогой товарищ, как-то определитесь :)
/usr/opt — такого вообще нет во многих дистрибутивах.
Если пакет имеет закрытый исходный код, тупо бинарники, то в /opt. В противном случае, если неразделяемый, может быть нужен для загрузки то в /, иначе в /usr.
В /usr/local ставятся пакеты собранные на дайнной машине, пакеты не из репозитория.
Мне определятся не с чем, есть FHS, вполне конкретный документ. Но со временем назначение некоторых папок устарело, и они просто были переориентированы под сегодняшние нужны с минимальными противоречиями.
Если пакет имеет закрытый исходный код, тупо бинарники, то в /opt. В противном случае, если неразделяемый, может быть нужен для загрузки то в /, иначе в /usr.
В /usr/local ставятся пакеты собранные на дайнной машине, пакеты не из репозитория.
Мне определятся не с чем, есть FHS, вполне конкретный документ. Но со временем назначение некоторых папок устарело, и они просто были переориентированы под сегодняшние нужны с минимальными противоречиями.
Кто-нибудь, поясните, пожалуйста, разницу между /opt и /usr/local/.
В /opt сейчас чаще всего ставится коммерческое ПО. В то время как в /usr/local/ самостоятельно собранное на данной машине.
В /opt ставится софт, который тащит за собой всю иерархию. Т.е. /opt/BazBuz/usr, /opt/BazBuz/lib, /opt/Boooo/var и т.д. Каждая софтинка там получает полный комплект нужного, без опасности затереть файлы ОС.
Не одобряю, но из всех вариантов самый аккуратный.
Не одобряю, но из всех вариантов самый аккуратный.
Простите за офтоп, где можно почитать про виндовс консоль?
Интересно, а кто-нибудь удосужился прочитать упомянутый FHS? Такое ощущение, что его авторы сами для себя пишут — создатели дистрибутивов на него плевать хотели. А уж среди пользователей так и вообще какие-то поверия и мифы ходят :) Даже по обсуждению здесь видно :)
Посмотрите, когда вышел FHS и какой сейчас год. Я не вижу явных противоречий с тем, как сейчас принято в дистрибутивах. Суть одна и та же, только назначения некоторых конкретных папок поменялась с учетом сегодняшних реалий.
В том смысле, что прошло шесть лет, а FHS всё ещё никто не выполняет? Я её сейчас заново просмотрел — всё логично и правильно. Но создатели дистрибутивов упорно игнорируют FHS.
Давайте разберемся. В каком месте вы считаете, что они FHS игнорируют? С ссылкой на конкретной раздел www.pathname.com/fhs/pub/fhs-2.3.html
Почему-то ответилось не туда
Ха, забавно, но в точь-точь та же проблема.
Ну и прошло то более 6 лет, там в последних релизах не существенные правки. А самое занимательное, что сам редактор FHS в анонсе версии 2.0 пишет:
FHS 2.0 is the direct successor for FSSTND 1.2, which is currently implemented by most major Linux distributions (I've lost track, but the list includes Red Hat, Debian, and others. I am interested in hearing from compliant and non-compliant developers).
Ну, так чтобы с ходу, лично у меня такие вопросы:
1) Где и у нас нынче размещаются данные для публичных серверных служб — (www, ftp и т.п)? В FHS ясно и понятно написано, про /srv (которая ни разу ни optionаl).
2) Бардак c /opt и /usr/bin. В FHS ясно написано — ВЕСЬ дополнительный софт должен устаналвливаться в /opt причём в подкаталоги. Желающие могут создавать символьные ссылки в /usr/bin и т.п. Причём это тоже ни разу не опционально. По факту имеем бардак.
3) Многие программописатели до сих пор не удосужились прочитать про раздел /etc и о том, как нужно именовать/располагать файлы конфигурации.
1) Где и у нас нынче размещаются данные для публичных серверных служб — (www, ftp и т.п)? В FHS ясно и понятно написано, про /srv (которая ни разу ни optionаl).
2) Бардак c /opt и /usr/bin. В FHS ясно написано — ВЕСЬ дополнительный софт должен устаналвливаться в /opt причём в подкаталоги. Желающие могут создавать символьные ссылки в /usr/bin и т.п. Причём это тоже ни разу не опционально. По факту имеем бардак.
3) Многие программописатели до сих пор не удосужились прочитать про раздел /etc и о том, как нужно именовать/располагать файлы конфигурации.
1. в арче, например, в /srv и размещаются
$ ls /srv
ftp http
так уже из коробки, но оба каталога пустые.
В генту на ваше усмотрение, можете создать /srv и класть туда. В любом случае, я честно говоря не знаю дистрибутивов в комплекте с которыми уже идут какие-то site-specific данные, это было бы очень странно. Сайты и файло-хранилища вы создаете сами, и можете создать каталог /srv в любом дистрибутиве. Сам дистрибутив ничего туда класть не должен.
2. Что такое дополнительный софт для linux? Так весь софт кроме ядра — дополнительный. А если нет, то какой дополнительный? Наверное тот, что не поставляется сообществом, т.е. коммерческий, закрытый.
3. Это же уже проблемы отдельно взятых программо-писателей, но на самом деле никакой проблемы в том нет, да и майнтеинеры многих дистрибутивов делают все возможное, чтобы все было в ожидаемых местах с ожидаемым названием.
$ ls /srv
ftp http
так уже из коробки, но оба каталога пустые.
В генту на ваше усмотрение, можете создать /srv и класть туда. В любом случае, я честно говоря не знаю дистрибутивов в комплекте с которыми уже идут какие-то site-specific данные, это было бы очень странно. Сайты и файло-хранилища вы создаете сами, и можете создать каталог /srv в любом дистрибутиве. Сам дистрибутив ничего туда класть не должен.
2. Что такое дополнительный софт для linux? Так весь софт кроме ядра — дополнительный. А если нет, то какой дополнительный? Наверное тот, что не поставляется сообществом, т.е. коммерческий, закрытый.
3. Это же уже проблемы отдельно взятых программо-писателей, но на самом деле никакой проблемы в том нет, да и майнтеинеры многих дистрибутивов делают все возможное, чтобы все было в ожидаемых местах с ожидаемым названием.
2. Именно, что весь кроме ядра. Причём тут открытость/закрытость? И пакеты должны ставится в /opt.
3. К сожалению майнтейнеры как-то не слишком убедительно это делают — многие занимают какие-то странные позиции — «наши деды так делали и мы будем».
3. К сожалению майнтейнеры как-то не слишком убедительно это делают — многие занимают какие-то странные позиции — «наши деды так делали и мы будем».
2. Полный бред. Ваше личное мнение, ничего не имеющие общего ни с реальностью, ни с FHS, ни даже со здравым смыслом. Т. е., по вашему, практически все остальные папки должны оставаться пустыми, включая /etc, /bin, /usr/bin, /usr/lib и т. д.
Т.е. Вы считаете логичным деление места установки программы по степени открытости кода? :) Т.е. StarOffice ставим в одну место, а OpenOffice — в другое? Что делать с программами у которых код частично открыт? Со смешанными лицензиями? И наконец — хит сезона, что делать с программами, которые могут быть и коммерческими и открытыми? Если я использую программу в некоммерческих целях, то ставлю по одному пути, а если в коммерческих, то по другому? :)
Это не я предлагаю. Так сделано, так работает, так написано, так принято, в конце-концов так разумно.
И никаких проблем не возникает. Если я ставлю открытую версию VirtualBox, которая OSE, то она ставиться как положено в систему. Если я ставлю проприетарную редакцию, то она устанавливается в opt. У opt есть вполне конкретное назначение. Он нужен для того, чтобы программы установленные в нем, не вызывали конфликтов, не нарушали правил. В /opt у каждой программы своя маленькая песочница, которая не пересекается ни с системой, ни с другими программами. Нельзя задать пути установки и изменить правила именования у многих программ с закрытым кодом, вот поэтому их и помещают в /opt, чтобы им там жилось хорошо, и при этом, они не нарушали равновесия, никому не мешали.
И никаких проблем не возникает. Если я ставлю открытую версию VirtualBox, которая OSE, то она ставиться как положено в систему. Если я ставлю проприетарную редакцию, то она устанавливается в opt. У opt есть вполне конкретное назначение. Он нужен для того, чтобы программы установленные в нем, не вызывали конфликтов, не нарушали правил. В /opt у каждой программы своя маленькая песочница, которая не пересекается ни с системой, ни с другими программами. Нельзя задать пути установки и изменить правила именования у многих программ с закрытым кодом, вот поэтому их и помещают в /opt, чтобы им там жилось хорошо, и при этом, они не нарушали равновесия, никому не мешали.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Основы Linux от основателя Gentoo. Часть 2 (2/5): Назначения папок, поиск файлов