===[ Секреты мастерства ]=== #post-id: 5315-20-39 #original-date: 13.02.2015 Fri #original-time: 8:39 PM #original-day: 5315 #original-host: WinXP Prof SP3 (Build 2600) Гы! Есть такая переменная окружения PATH, существующая со времён DOS. Каталоги, указанные в ней, будут использоваться при поиске екзешника, который пользователь запускает не указав к нему путь. Тоесть, если в консоли мы пишем ARJ.EXE (или просто ARJ), то система будет искать исполняемый файл с таким именем в текущем каталоге, в системных каталогах (Windows и System32) и в каталогах, указанных в переменной PATH. Если найдёт, то запустит первый же найденный файл с таким именем. Вроде бы в этом сценарии работают относительные пути. Тоесть если указать "Utils\ARJ", то во всех перечисленных каталогах будет искаться подкаталог Utils, а в нём - файл ARJ.EXE. Расширение, как я уже сказала, можно не указывать. Но как система узнаёт его? Ещё во времена DOS, а потом - Windows 9x этими расширениями были EXE и COM. Это расширения исполняемых файлов, которые были у оных всегда. А также искались файлы с расширением BAT, тоесть пакетные файлы. При чём сначала система искала BAT файл, а только потом - EXE и COM. На этом эффекте были основаны приколы вроде вирусов (DIR.BAT, какой-нибудь) или пакетных файлов, которые создавали всё необходимое для работы одноимённого екзешника. Например, пишешь ты в консоли CZZ, запускается CZZ.BAT, который создаёт нужные каталоги, переменные окружения, а потом запускает CZZ.EXE, лежащий рядом. Удобно! А вот в Windows NT есть переменная окружения PATHEXT, в которой перечислены такие расширения. Тоесть список можно сильно расширить. При чём по умолчанию в нём присутствуют не только EXE, COM, BAT, CMD (тоже самое, что и BAT, но для гордых энтишников), но и всякие скрипты вроде VBS, JS, WSH. К слову о приколах. В DOS и консоли Windows есть команда PATH, которая, как легко заметить, имеет то же имя, что и переменная окружения PATH. Она не существует в виде екзешника, а является внутренней командой командного процессора. Она выводит содержимое переменной PATH. Тоесть можно набрать "ECHO %PATH%", а можно просто "PATH". Такой прикол с другими переменными не работает. Там нужно набирать конкретно "ECHO %PATHEXT%" или SET, чтобы посмотреть все переменные разом. Вооот. А ещё есть AppPath в реестре, где задаётся имя екзешника и полный путь к нему. Но работает оно немного иначе. Так в консоли и при запуске процесса через CreateProcess() (и другие функции, которые используют её, типа winexec()) система скажет, что нет такого файла. Тоесть она не будет смотреть AppPath в реестре. А вот при запуске через START (каманда), окно "Запуск" или функцию ShellExecute() (которую вся эта компания и использует), прежде всего будет проверен реестр, и нужная программа будет запущена. Я это всё к чему? AppPath - удобная штука, но в BAT файлах не работает. Тоесть, если мы хотим запускать из них какие-то консольные туилиты, нужно указать к ним путь в PATH. А если таких каталогов двести? PATH не резиновая! Я нашла такое решение. Рекомендуют переместить файлы утилит в каталог, который указан в PATH. Особенно, если они не требуют каких-то дополнительных файлов (файлы данных, библиотеки, конфиги). Но я не люблю таскать туда-сюда файлы, что-то создавать, поэтому нашла такой вариант. Берём утилиту и создаём на неё симлинк в системном каталоге Windows. Тоесть екзешник находится на старом месте, а все программы думают, что он в System32. Не очень хорошее решение, но надёжное. Если утилита потом будет удалена, то симлинк просто перестанет работать - никаких кусков по системе разбросано не будет. Ну, кроме, собственно, симлинка. Можно ещё сделать хардлинк (не ссылку, а новое имя для того же файла, но в другом каталоге), но в случае удаления утилиты, её екзешник останется валяться в системном каталоге. Так что симлинк. Есть, правда, проблема. В Windows XP симлинки изначально не работают (работают только хардлинки и junction менее продвинутый вариант симлинков, который может ссылаться только на каталоги и только на локальной машине). Однако в драйвере NTFS есть весь необходимый функционал для этого, поэтому нужно установить ещё один маленький драйвер, который врубит данный функционал. После этого симлинки работают как и в боле епоздних версиях Windows. Этот драйвер можно скачать здесь (в самом низу): http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html Как работать с симлинками (ниже я буду называть этим словом также хардлинки и junction)? Что для этого нужно? • В Windows 7 и выше (а может быть и в Висте - именно с этой системы MS начала активно использовать симлинки) есть специальные системные утилиты для работы с симлинками. Честно говоря, не пользовалась, но Хикедая рекомендует. • Существует утилита ln, которая идёт с драйвером. Эта утилита очень простая, похожа на линуксовую команду. • Есть ещё одна утилита ln, более продвинутая. Качается там же, где и драйвер (см. выше). • Есть расширение для Проводника, которое позволяет создавать симлинки мышкой, а в папках видеть, какие файлы имеют хардлинки, какие папки на самом деле - junction и симлинки. Качается по той же ссылке выше. • А ещё файловый менеджер FAR прекрасно справляется с симлинками. При файловых операциях внимательно смотрит, не попадётся ли симлинк, а создаёт оные через Alt+F6 - прямо как копирование файлов или папок. Считаю это наиболее удобным вариантом, особенно если настроить раскраску папок. Это всё, что так или иначе проверено. Замечу, что симлинки - мощная вещь, но всёже немного небезопасная. Например, в XP есть прикол. Допустим, у нас есть папка, в которой имеется симлинк на другую папку. Удаляем папку в корзинку - симлинк остаётся внутри. Потом очищаем корзинку. Проводник XP ещё ничего не знал о симлинках, поэтому при отчистке он заодно вытирал файлы и папки из папки, на которую ссылался симлинк. Пичалька! Для борьбы с этим тот же FAR сначала пробегается по дереву каталогов и разрывает все симлинки (именно симлинки и junction), а потмо только отправляет папку в корзинку. LinkShell Extension вроде бы тоже так делает, перехватывая попытки проводника и программ отправить папку в корзинку и налету разрывая все найденные симлинки. Разумеется, в Висте это дело поправили. Вот такая история! Хотела написать как преодолеть ограничения PATH, а накатала целый манускрипт ^^'