Интуитивным методом указания пути при установке.
А можно просто в Program Files глянуть.
Это в Лине нужно утилитой пользоваться, чтобы узнать название запускаемых файлов, манов (с этим вообще хаос) и другой полезной инфы, нужной для работы.

Если ты про 100% всех файлов, то для этого sandbox есть, но для простой работы такая инфа не нужна.
Да и большинство прог, как Лиса, 1 папкой обходятся.

Спасибо.

Ой, я наверно неудачно сформулировал вопрос. Меня интересовало, можно ли как-нибудь как получить эту информацию программно, не подскажете?

Не понимаю, чем Вас так смущает equery f virtualbox? Если уж на то пошло, найдите в Винде все файлы и записи в реестре, которые были добавлены/внесены/изменены/удалены при установке VirtualBox. В Linux аналогом этого является equery f <имя пакета> (если Gentoo), или аналогичная команда другого дистрибутива (например, rpm -ql <имя пакета> в fedora), так как в Linux пакет определяется набором своих файлов. А что там в Windows инсталлятор в систему под админом поставил --- понять практически невозможно.
Строго говоря, в Gentoo тоже зачем-то добавили возможность выполнения произвольных скриптов без sandbox, за что разработчикам следовало бы поотрывать руки. Но там это хотя бы можно отследить при желании, проверив ebuild'ы grep'ом перед установкой.

Что касается возможности использования одновременно нескольких версий одного пакета, то всё это можно сделать. В gentoo сущетвует понятие slotted пакета, правда, к сожалению, не для всех пакетов. В любом случае, никто не запрещает поставить особо проблемные пакеты в /opt.

Существует также попытка сделать дистрибутив, в котором всё это позволяет делать встроенный менеджер пакетов (см. http://nixos.org/nixos/). Там происходит примерно следующее: каждый пакет ставится в уникальный каталог, а файловые деревья в стиле FHS поддерживаются с помощью символических ссылок. К сожалению, этот дистрибутив пока не допилен, и там есть далеко не все пакеты, а также там маловато документации. Правда я смотрел его года полтора назад --- может, с тех пор что-нибудь изменилось.

Так в стоит стразу несколько версий .NET Framework, несколько версий пакетов Visual библиотек, даже может быть несколько версий MS SQL Server. И ничего. Что мешает сделать так же?

Встроенных средств я не знаю, но куча способов с дополнительным ПО.
Самое популярное - ProcMon или sandbox - мне достаточно.

По расширению *.exe

Да. MSDN и дока в CHM заткнёт за пояс любой man, у которого возможности навигации скудны - в info попытались исправить дело, но не поперло.

Тем, что это - 100% костыль. Самое интересное начинается, когда не знаешь из какого пакета файл.
Вот если бы тот же вывод equery f virtualbox встроили, например, в Midnight Commander для удобства навигации - это решило бы проблему, но не полностью.

Тот же /usr/bin разрастается быстро. После установки кучи пакетов найти что-то в /usr/bin становится сложней. Так же программистам приходится придумывать порой совершенно странные имена своим запускаемым файлам, чтобы не нарваться на конфликт имен в /usr/bin. Страшно представить сколько super-mega-paint было бы в той папке, если софтосоздатели кинутся на Линь. А еще регистрозависимость бесит: VBox* найдет, а vbox* уже нет.

Сейчас у меня в /usr/bin 2612 файлов - как в этом бардаке вообще можно ориентироваться?

Не... Майк этот кактус жрал в DOS'e, а в Винде они правило c:\Program Files\создатель\прога установили.

Ты предложение то доцитируй полностью, а то выдернул пол предложения и задаёшь глупые вопросы.

Какая то слабая отмазка, особенно на счёт исошников. Ты если разрабатываешь чего для VirtualBox, то у тебя уже стоит его SDK в виде отдельного пакета, исошники с дровами те тоже не надо искать, т.к. VirtualBox их монтирует сам, у него кнопка есть, установить дополнения для гостевой ОС. А доки, картинки и иные ресурсы лежат на своем месте в /usr/share.

И какая то странная постановка вопроса у тебя, будто ты все знания подчерпываешь методом тыка, глядя чего там в каталогх с программами.

Это не аргумент, с быдлокодерами бороться очень просто - не использовать их ПО. А применение... Хотя если твои знания основываются только на исследовании каталогов программ...

тебе объяснили, что специфика расположение файлов в никсах обусловлена централизацией, бинарники в одном месте, библиотеки в другом, ресурсы (картинки, звуки, шрифты) в третьем, доки в четвертом и т.д.

только не говори, что складирование всех файлов в одном каталоге - это новаторство, и соответствие неким современным реалиям. Особенно когда на диске установлено 100500 программ, у каждой свой каталог, и для запуска этих программ надо рыскать по каталогам а не просто ввести команду в консоли. Хорошо если есть ярлык, а если программа консольная?

Чот ты не проснулся видать, там речь шла об объёме НЖМД а не размере конкретных каталогов.

Я не только про этот каталог говорил, поищи сам ДЛЛки в каталоге винды, и увидишь, что в c:\Windows\System32\ их как раз меньшинство.

Какое интересное совпадение, то же самое и с библиотеками линукса, там тоже нужные библиотеки ставятся зависимостями.

Так же большинство юзеров и не исследует файлы программ, и им так же фиолетово где и что размазано, есть ярлык на рабочем столе или в Пуске, они его жамкают и довольны.

Вот с таким умным видом, такую глупость ты брякнул, особенно про управление памятью. В память грузится один экземпляр библиотеного ФАЙЛА. А если этих библиотечных файлов несколько то и грузятся они все, и не важно одинаковые они или нет.

Ты бы осилил бы инструменты на вроде System Explorer, или список процессов в Far Manager, что бы не делать более таких грубых ошибок.

Тебе про equery уже говорили, и бросал бы ты ерундой заниматься, книги бы почитал, начал бы с незнайки на луне, потом плавно к математике, так глядишь и до дискретной математики дойдёшь.

И еще, МСО туеву кучу файлов копирует в каталог винды, если ты это не знал, впрочем чего говорить, исследовать каталог с установленным МСО  ты догадался, а вот глянуть внутрь инсталляшки МСО нет.

Отредактировано ladserg (20-02-2013 09:18:41)

Ну да, спросить, где файлы такого-то пакета — это костыль, а руками лезть в Program Files и вспоминать, как там оно обозвалось и не переименовал ли его ты (или не ты) — это труъ.

Как получить список файлов пакета, который ты не знаешь? Или что?

А зачем? У меня 3381, и никаких проблем не испытываю. Да, я не открываю /usr/bin/ в приказчике папокъ, чтобы удивляться количеству файлов там. Потому что смысла нет. Зато никакого бардака с $PATH, как в винде. И чем лучше поиски нужного файла в бардаке Program Files\создатель\прога?

Да, сплошная польза!

Молодец, MSDN приплёл. Ну ты красавчик.
Лично меня как раз CHM и вообще Справка Windows вымораживали неудобством использования.

Это больше ударяет по потреблению оперативной памяти.

А-а-а. Итак, я должен пойти в C:\Program Files\ (там 100500 каталогов, естественно), вспомнить производителя, проверить, что оно установилось не просто по названию программы, влезть в каталог программы и искать там исполняемые файлы по расширению в куче прочих. Само удобство, да.

«Неужели?» — подумал я. И полез искать как оно в gentoo...
http://www.gentoo.org/doc/en/gentoolkit … hap2_pre15
Сам я пользователь иной системы и там тоже всё с этим в порядке:

> pkg which -q /usr/local/include/aupvlist.h 
libaudiofile-0.2.7

А где тут чего интересного?

Отредактировано Azathoth (20-02-2013 12:57:28)

Ну в любом случае инструмент для этого есть.

Azathoth
Конечно, просто я поправил во имя Истины (-:Е

Каким вопросом? Причём здесь GNOME?

Так ведь ничто не мешает, я об этом и говорю.

Никакой это не костыль. Информация о том, какой файл к какой программе относится, хранится в централизованной базе данных, вполне разумно. Утилита equery предоставляет доступ к этой базе.

Можно воспользоваться, например, способом, который продемонстрировал krigstask, или, например, так:

# equery belongs /путь/к/файлу

Эта команда покажет, к какому пакету принадлежит файл.
После этого введя

equery f имя_пакета

можно узнать список всех файлов данного пакета. При желании можно написать элементарный скрипт, который это делает одной командой.

Спасибо, про qfile не знал. Но equery вроде не особо тормозит (а может, просто редко нужна).

Возможно, это было бы неплохо. Есть же, например, под Windows плагин к Total Commander для доступа к реестру...

Не все конечно, но это быстрый способ узнать возможности проги.
В c:\Windows\System32\ так вообще много интересного. При курении доки можно не придать должного значения файлу... да и его описание может не попасться на глаза...
А можешь залезть в папку Лисы. omni.ja заинтересует по круче доков.

А ты сам не думал, что SE может показывать разные пути вызова ДЛЛки, но копия файла в оперативе одна?
Если бы этот бред был правдой, то в 90-х все мои 60МБ выжрали множество копий MFC. Менеджер Памяти в Вине - это черный ящик, которым в Майке гордятся.

И как мне это ДЛЛки помогут в работе? А вот дока по управлению Вордом через макросы и СОМ, которая лежит на своем месте... ммм... хорошо, что я в 2003г. её там обнаружил...

Так ты объясни, что будет, если не подозревающие Вася и Петя создадут разные super-mega-paint? Имена запускаемых файлов совпадут.

Поиск 1 файла одинаковый. А вот "искал одно, а нашел поинтересней" в ПФ часто бывает.

Интересней не спрашивать, а взаимодействовать с файлом. Или ты по имени всегда можешь определить его содержимое?

Приехали. Ты когда содержимое этой переменной смотрел? А редактировал? Мне наплевать на ее "бардак" - для этого её и придумали.

Ты в последний раз её когда открывал? А справку Гнома и КЕД? КЕДешная вообще слизана с CHM.
А слабо про STL через man почитать? - вот жесть без разделов.

У меня всего лишь 84. И поиск пашет, если автора забыл...