Comments 39
За {} спасибо. Всю жизнь xargs использовал.
+1
в мане это описано:
find. -type f -exec file '{}' \;
find. -type f -exec file '{}' \;
+7
find.unixpin.com/ru/ Вот в помощь. Я много от туда подчерпнул, переодически пользуясь.
+1
С тем же успехом можно использовать какой-нибудь kfind (если у вас кеды, или любой другой графический интерфейс к find, подходящий для вашего DE)… Веб-интерфейс к командной строке это жесть.
0
Это же помошник по команде, а не интерфейс к cli. Первое время у меня попросту небыло времени выучить весь синтаксис find.
0
Да я понял, но отличая от gui получаются лишь в том, что тут вам еще надо копировать команду в интерпретатор. Впрочем, конечно, некоторую образовательную функцию оно будет нести, но только в том случае, если пользователь будет вникать в то, что он копирует. В противном случае, лучше просто уж пользоваться gui.
0
UFO just landed and posted this here
-exec: каждый раз делает запуск чайлда, иногда это дорого.
По-умолчанию — да. Но если использовать его в форме
-exec command {} +
то {} заменится на все найденные файлы, command будет запущена один раз.
xargs рулит только в случае если нужно сделать что-то вроде
|xargs -n 1 -P 2 -I '{}' sh -c 'oggenc -Q -q 7 "{}" && rm -fv "{}"'
т.е. нужно запускать несколько инстансов command параллельно
0
Становится интересно ) присоединяюсь к предидущему посту про {} не знал )
кстати
$ export PATH=
А то мб для кого-то не очевидно )
кстати
$ export PATH=
А то мб для кого-то не очевидно )
0
Ээээ… куда ставить по этой иерархии неразделяемые несистемные пакеты?
0
Что вы понимаете под несистемными/системными пакетами? Это вам не freeBSD.
+4
Я понимаю /opt и иже с ним.
Вы предлагает делить по месту компиляции или степени открытости кода?
Т.е. если я собрал пакет сам, то ставлю его в /usr/local?
А если тот же пакет получил бинарно — то в usr/opt?
Вы предлагает делить по месту компиляции или степени открытости кода?
Т.е. если я собрал пакет сам, то ставлю его в /usr/local?
А если тот же пакет получил бинарно — то в usr/opt?
0
Я ничего не предлагаю. Я говорю по факту имея маны, гугл, и арч с генту под рукой. Не вижу никаких проблем с пониманием куда чего ставить.
Когда вы написали про «несистемные» пакеты я вообще то подумал, что вы тонкий 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.
0
А если через менеджер пакетов — то куда авторы дистрибутива захотели? :)
А если у меня пакет свободный, то в usr/opt. Как OpenOffice, например.
Но если пакет не свободный, то в /opt — как StarOffice :) :) :)
Вы, дорогой товарищ, как-то определитесь :)
А если у меня пакет свободный, то в usr/opt. Как OpenOffice, например.
Но если пакет не свободный, то в /opt — как StarOffice :) :) :)
Вы, дорогой товарищ, как-то определитесь :)
0
/usr/opt — такого вообще нет во многих дистрибутивах.
Если пакет имеет закрытый исходный код, тупо бинарники, то в /opt. В противном случае, если неразделяемый, может быть нужен для загрузки то в /, иначе в /usr.
В /usr/local ставятся пакеты собранные на дайнной машине, пакеты не из репозитория.
Мне определятся не с чем, есть FHS, вполне конкретный документ. Но со временем назначение некоторых папок устарело, и они просто были переориентированы под сегодняшние нужны с минимальными противоречиями.
Если пакет имеет закрытый исходный код, тупо бинарники, то в /opt. В противном случае, если неразделяемый, может быть нужен для загрузки то в /, иначе в /usr.
В /usr/local ставятся пакеты собранные на дайнной машине, пакеты не из репозитория.
Мне определятся не с чем, есть FHS, вполне конкретный документ. Но со временем назначение некоторых папок устарело, и они просто были переориентированы под сегодняшние нужны с минимальными противоречиями.
0
Кто-нибудь, поясните, пожалуйста, разницу между /opt и /usr/local/.
0
В /opt сейчас чаще всего ставится коммерческое ПО. В то время как в /usr/local/ самостоятельно собранное на данной машине.
+1
В /opt ставится софт, который тащит за собой всю иерархию. Т.е. /opt/BazBuz/usr, /opt/BazBuz/lib, /opt/Boooo/var и т.д. Каждая софтинка там получает полный комплект нужного, без опасности затереть файлы ОС.
Не одобряю, но из всех вариантов самый аккуратный.
Не одобряю, но из всех вариантов самый аккуратный.
0
Простите за офтоп, где можно почитать про виндовс консоль?
+2
Интересно, а кто-нибудь удосужился прочитать упомянутый FHS? Такое ощущение, что его авторы сами для себя пишут — создатели дистрибутивов на него плевать хотели. А уж среди пользователей так и вообще какие-то поверия и мифы ходят :) Даже по обсуждению здесь видно :)
0
Посмотрите, когда вышел FHS и какой сейчас год. Я не вижу явных противоречий с тем, как сейчас принято в дистрибутивах. Суть одна и та же, только назначения некоторых конкретных папок поменялась с учетом сегодняшних реалий.
0
В том смысле, что прошло шесть лет, а FHS всё ещё никто не выполняет? Я её сейчас заново просмотрел — всё логично и правильно. Но создатели дистрибутивов упорно игнорируют FHS.
0
Давайте разберемся. В каком месте вы считаете, что они FHS игнорируют? С ссылкой на конкретной раздел www.pathname.com/fhs/pub/fhs-2.3.html
0
Ха, забавно, но в точь-точь та же проблема.
0
Ну и прошло то более 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).
0
Ну, так чтобы с ходу, лично у меня такие вопросы:
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 и о том, как нужно именовать/располагать файлы конфигурации.
0
1. в арче, например, в /srv и размещаются
$ ls /srv
ftp http
так уже из коробки, но оба каталога пустые.
В генту на ваше усмотрение, можете создать /srv и класть туда. В любом случае, я честно говоря не знаю дистрибутивов в комплекте с которыми уже идут какие-то site-specific данные, это было бы очень странно. Сайты и файло-хранилища вы создаете сами, и можете создать каталог /srv в любом дистрибутиве. Сам дистрибутив ничего туда класть не должен.
2. Что такое дополнительный софт для linux? Так весь софт кроме ядра — дополнительный. А если нет, то какой дополнительный? Наверное тот, что не поставляется сообществом, т.е. коммерческий, закрытый.
3. Это же уже проблемы отдельно взятых программо-писателей, но на самом деле никакой проблемы в том нет, да и майнтеинеры многих дистрибутивов делают все возможное, чтобы все было в ожидаемых местах с ожидаемым названием.
$ ls /srv
ftp http
так уже из коробки, но оба каталога пустые.
В генту на ваше усмотрение, можете создать /srv и класть туда. В любом случае, я честно говоря не знаю дистрибутивов в комплекте с которыми уже идут какие-то site-specific данные, это было бы очень странно. Сайты и файло-хранилища вы создаете сами, и можете создать каталог /srv в любом дистрибутиве. Сам дистрибутив ничего туда класть не должен.
2. Что такое дополнительный софт для linux? Так весь софт кроме ядра — дополнительный. А если нет, то какой дополнительный? Наверное тот, что не поставляется сообществом, т.е. коммерческий, закрытый.
3. Это же уже проблемы отдельно взятых программо-писателей, но на самом деле никакой проблемы в том нет, да и майнтеинеры многих дистрибутивов делают все возможное, чтобы все было в ожидаемых местах с ожидаемым названием.
0
2. Именно, что весь кроме ядра. Причём тут открытость/закрытость? И пакеты должны ставится в /opt.
3. К сожалению майнтейнеры как-то не слишком убедительно это делают — многие занимают какие-то странные позиции — «наши деды так делали и мы будем».
3. К сожалению майнтейнеры как-то не слишком убедительно это делают — многие занимают какие-то странные позиции — «наши деды так делали и мы будем».
-1
2. Полный бред. Ваше личное мнение, ничего не имеющие общего ни с реальностью, ни с FHS, ни даже со здравым смыслом. Т. е., по вашему, практически все остальные папки должны оставаться пустыми, включая /etc, /bin, /usr/bin, /usr/lib и т. д.
0
Т.е. Вы считаете логичным деление места установки программы по степени открытости кода? :) Т.е. StarOffice ставим в одну место, а OpenOffice — в другое? Что делать с программами у которых код частично открыт? Со смешанными лицензиями? И наконец — хит сезона, что делать с программами, которые могут быть и коммерческими и открытыми? Если я использую программу в некоммерческих целях, то ставлю по одному пути, а если в коммерческих, то по другому? :)
0
Это не я предлагаю. Так сделано, так работает, так написано, так принято, в конце-концов так разумно.
И никаких проблем не возникает. Если я ставлю открытую версию VirtualBox, которая OSE, то она ставиться как положено в систему. Если я ставлю проприетарную редакцию, то она устанавливается в opt. У opt есть вполне конкретное назначение. Он нужен для того, чтобы программы установленные в нем, не вызывали конфликтов, не нарушали правил. В /opt у каждой программы своя маленькая песочница, которая не пересекается ни с системой, ни с другими программами. Нельзя задать пути установки и изменить правила именования у многих программ с закрытым кодом, вот поэтому их и помещают в /opt, чтобы им там жилось хорошо, и при этом, они не нарушали равновесия, никому не мешали.
И никаких проблем не возникает. Если я ставлю открытую версию VirtualBox, которая OSE, то она ставиться как положено в систему. Если я ставлю проприетарную редакцию, то она устанавливается в opt. У opt есть вполне конкретное назначение. Он нужен для того, чтобы программы установленные в нем, не вызывали конфликтов, не нарушали правил. В /opt у каждой программы своя маленькая песочница, которая не пересекается ни с системой, ни с другими программами. Нельзя задать пути установки и изменить правила именования у многих программ с закрытым кодом, вот поэтому их и помещают в /opt, чтобы им там жилось хорошо, и при этом, они не нарушали равновесия, никому не мешали.
0
Sign up to leave a comment.
Основы Linux от основателя Gentoo. Часть 2 (2/5): Назначения папок, поиск файлов