Попробуйте в окне «Выполнить» (Win+R) ввести wmplayer и нажать Enter — откроется Windows Media Player. Теперь сделайте то же самое в командной строке. Проигрыватель не запустится, потому что не найден путь к нему! Почему так происходит?
Читатель блога Андрей поинтересовался по почте, в каких случаях для запуска исполняемых файлов не требуется вводить полный путь к ним. Вопрос показался мне элементарным, и я кратко предложил читателю обратить внимание на переменную PATH.
[+] На этой странице
Переменная PATH
Переменная среды PATH содержит пути, в которых Windows при выполнении команды автоматически ищет исполняемые файлы (EXE, CMD, VBS и т.д.). Изначально в переменную внесены только основные системные расположения, поэтому программы из папок Windows и System32 можно запускать, не указывая полный путь.
Как посмотреть содержимое переменной PATH
Некоторые программы при установке прописывают туда путь к своей папке, в чем вы наверняка убедитесь, выполнив в консоли команду path, показывающей системные и пользовательские переменные вместе.
Когда исполняемый файл находится в одном из расположений, известных Windows, вводить полный путь к файлу необязательно. Я использую это свойство операционной системы, чтобы быстро запускать любимые инструменты Sysinternals, утилиты Nirsoft и другие программы из своего сундучка (на рисунке видно, что в PATH добавлена папка Tools).
Как добавить свои пути к переменной PATH
Вы можете добавить собственные пути, изменив системную переменную PATH, либо создав пользовательскую переменную с таким же именем. Разницу между типами переменных я объяснял в рамках одной из викторин. Там же рассказывается, как изменять переменные среды в графическом интерфейсе. Обратите внимание, что пути разделяются точкой с запятой.
Можно быстро добавить свои пути в PATH из командной строки с помощью утилиты setx, входящей в состав Windows 7. Ниже приводится пример добавления пути C:\myfolder в системную переменную PATH (командная строка должна быть запущена от имени администратора).
For /f "tokens=2*" %a In ('Reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v Path') Do Set "systempath=%b"
set newpath=%systempath%;C:\myfolder1
setx /m path "%newpath%"
Сначала с помощью команды reg считывается список путей из системной переменной PATH, хранящейся в реестре. Затем команда set задает переменную newpath с нужным путем в рамках текущей сессии командной строки, а команда setx /m делает новый путь постоянным для системной переменной (параметр /m).
Пользовательскую переменную можно задать без прав администратора, применив аналогичный подход. Добавление нового пути к имеющейся пользовательской переменной PATH осуществляется так:
For /f "tokens=2*" %a In ('Reg query "HKCU\Environment" /v Path') Do Set "userpath=%b"
set newpath=%userpath%;C:\myfolder2
setx path "%newpath%"
Учтите, что код выше рассчитан на выполнение в командной строке. В командном файле (CMD) символы процента в первой строке должны быть двойными.
Строго говоря, здесь можно было обойтись и без setx, поскольку reg может не только считывать данные из реестра, но и записывать их туда. Но во многих случаях с setx проще работать за счет более компактного синтаксиса.
Конечно, я не расписывал все это так подробно для Андрея, а просто задал ему направление. Однако на следующий день он написал мне, что все это знал (я — посредственный телепат :) и задал вопрос, которым я начал сегодняшний рассказ. Это было уже интереснее, и я пообещал раскрыть тему в блоге!
Раздел реестра App Paths
Действительно, не указывая полный путь, можно запустить некоторые стандартные программы Windows из окна «Выполнить», но не из командной строки. Помимо проигрывателя Windows Media, это, например, Paint (mspaint) и Wordpad (wordpad). То же самое верно и для приложений MS Office – проверьте команду excel или winword!
Разница между окном «Выполнить» и командной строкой заключается в том, что оболочка Windows (explorer) обладает более широкими возможностями, чем консольный интерпретатор команд. В данном случае все дело в функции ShellExecuteEx, которой снабжена оболочка. Когда вы запускаете исполняемый файл без указания полного пути к нему, функция выполняет поиск в:
- текущей папке
- папках Windows и System32
- разделе реестра
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
Как работает раздел App Paths
Давайте посмотрим на работу App Paths на примере Windows Media Player.
Здесь:
- создан подраздел с псевдонимом исполняемого файла (в данном случае – это wmplayer.exe)
- в параметре По умолчанию указан полный путь к файлу. Если в пути к файлу используется переменная, параметр должен быть расширяемым строковым (REG_EXPAND_SZ). Указывая абсолютный путь, можно обойтись обычным строковым параметром (REG_SZ).
- в параметре Path задана рабочая папка программы
Работает это очень просто. Вы вводите псевдоним файла в окне «Выполнить» или адресной строке проводника, а система автоматически смотрит в указанном пути.
Как ускорить свою работу с помощью App Paths
Этим разделом реестра можно пользоваться для быстрого запуска программ, ярлыки которых не нужны вам в панели задач или на рабочем столе. Например, для поиска и замены в текстовых файлах я применяю программу BKReplacem (replacem.exe), у которой своя папка внутри папки PortableSoft. В разделе App Paths я создал подраздел bkr.exe и указал полный путь к утилите. Теперь ее запуск сводится к выполнению bkr в окне «Выполнить».
Кстати, не забывайте заключать в кавычки пути, содержащие пробелы. И, надеюсь, вы уже догадались, что можно сократить команду до одной буквы. Продолжая этот пример, я мог бы создать подраздел b.exe. Вообще, у программы может быть сколько угодно псевдонимов, как вы увидите чуть ниже.
В нем всего одна строка:
schtasks /run /tn CMD_Admin
Теперь достаточно ввести в окно «Выполнить» команду cmda, чтобы открыть командную строку от имени администратора.
Что интересного можно найти в разделе App Paths
Во-первых, я уверен, что вы найдете там многие из установленных у вас программ. Вместо того чтобы прописывать путь к своей папке в переменную PATH, программы регистрируют свой исполняемый файл в разделе App Paths, следуя рекомендациям Microsoft.
Во-вторых, там есть подразделы WORDPAD.EXE и WRITE.EXE, причем оба ведут к файлу wordpad.exe.
Программа Write, входившая в состав первых операционных систем Microsoft, в Windows 95 была заменена на WordPad. Вы также найдете подраздел pbrush.exe, ссылающийся на mspaint, лежащий в System32.
Программ Write и Paintbrush нет в Windows уже лет 15, однако упоминание о них до сих пор содержится в системе! И это подводит нас к разговору о том, когда и зачем в Windows ввели раздел App Paths.
История App Paths
Раздел App Paths появился в Windows 95 в качестве противоядия от засорения пути PATH, который задавался в файле autoexec.bat. Программы традиционно добавляли туда пути к своим папкам, как это до сих пор иногда делается с одноименной переменной среды. При загрузке системы файл считывался, а программы оказывались в системном пути.
Кстати, старый способ autoexec.bat до сих пор работает, позволяя запускать исполняемые файлы без указания пути, хотя использовать его уже нет смысла.
Основная проблема для разработчиков состояла в том, что найти в autoexec.bat правильную строку SET PATH было нетривиальной задачей. При этом нельзя было вставлять свою строку в начало файла, поскольку другая команда ниже могла переопределить переменную.
Кроме того, добавлять путь в PATH ради того чтобы указать Windows на одну единственную программу, было не рационально, сродни стрельбе из пушки по воробьям. Вот тогда разработчики Windows 95 и придумали решение с разделом реестра, позволяющим указывать пути к конкретным исполняемым файлам.
Почему в этом разделе до сих пор есть подразделы для Write и Paintbrush? Так Windows обеспечивает совместимость программ!
Теоретически, какая-нибудь древняя программа может полагаться на своих ровесниц, наследницы которых уже сменили имя или расположение. Чтобы старые приложения не ломались, используется раздел реестра App Paths.
Псевдонимы магазинных приложений
В Windows 10 1709 у магазинных приложений появились псевдонимы выполнения. Разработчик приложения прописывает в манифесте псевдоним, что позволяет запускать по нему приложение из командной строки и оболочки Windows. В примере ниже фрагмент манифеста утилиты Monitorian, о которой я рассказывал.
<uap3:Extension Category="windows.appExecutionAlias" Executable="MonitorianPlus\MonitorianPlus.exe" EntryPoint="Windows.FullTrustApplication">
<uap3:AppExecutionAlias>
<desktop:ExecutionAlias Alias="Monitorian.exe" />
</uap3:AppExecutionAlias>
</uap3:Extension>
Пользовательское изменение псевдонимов не предусмотрено, их можно только отключить в параметрах — ищите там alias или псевдоним. Об этой возможности полезно знать, потому что бывают неприятные сюрпризы, как с Python.
Бонус: исследователь из Google Project Zero разбирает подноготную работы псевдонимов в контексте безопасности: Overview of Windows Execution Aliases.
Сводная таблица
Итак, подведем итог! Проще всего сравнить возможности оболочки Windows и командного интерпретатора системы в табличной форме.
| Поиск исполняемого файла | Проводник | Командная строка |
|---|---|---|
| Текущая папка | Да | Да |
| Системные папки (Windows, System32) | Да | Нет |
| Переменная PATH | Да | Да |
| Раздел реестра App Paths | Да | Нет 1 |
| Псевдонимы магазинных приложений | Да | Да |
В таком виде становится наглядным не только более широкий диапазон поиска исполняемых файлов в проводнике, но и не вполне очевидная зависимость командной строки от переменной PATH. Именно ее пути влияют на то, нужно ли в консоли указывать путь к файлам, расположенным в системных папках.
Наконец, раздел App Paths представляет дополнительную ценность за счет того, что в нем можно указывать короткие псевдонимы исполняемых файлов, упрощая их запуск.
А вы используете раздел реестра App Paths или собственные переменные среды? Если да, то расскажите в комментариях, как они упрощают вашу работу!
Но можно использовать команду start:
start wordpad↩
Замечательный материал! Про AppPaths слышу впервые, не знал про такую удобную штуку. Фокус с запуском командной строки cmda взял на вооружение, но у меня оно, к сожалению, не заработало. Пишет, «Не удается найти cmda», хотя делал все по инструкции.
equinox, а я не давал инструкций по cmda, просто обрисовал подход. Наверное, посмотрев скриншот раздела реестра cmda.exe, я смогу сказать что-то более конкретное.
Разумеется, не давали инструкций, но я же сразу кинулся пробовать новую для меня «фичу», к тому же исключительно удобную.
Скриншот — http://s2.ipicture.ru/uploads/20111019/RWkGszYW.png
equinox, ну да, я еще когда писал, подумал, что надо было разжевать этот момент получше.
Но прочтите внимательно:
Как заработает, киньте ссылку на правильный скриншот, я добавлю в статью :)
Vadim Sterkin,
Разумеется, теперь все заработало. Скриншот — http://s2.ipicture.ru/uploads/20111019/7iXaY4N1.png
equinox, я рад, что у вас все получилось :) Спасибо за скриншот, хотя его пришлось минут 10 фотошопить, ибо ширина в 1000 px ему не нужна была.
Я не использую. Просто пока не возникало необходимости. Про переменные среды знал. Теперь буду знать и нюансы -)
Это ладно, мне больше нравится невозможность создать папку или файл с названием типа «CON», ибо это имя было зарезервировано для какого- то устройства во времена MS- DOS. Резервируют до сих пор, хотя про такие устройства уже все забыли.
А вот с Вашей таблицей я бы поспорил: Командная строка всё таки ищет в Системных папках (Windows, System32), потому что они по умолчанию занесены в переменную PATH.
До сих пор поступал так:
1 Имею папку MyTools
2 Добавил ее в Path
3 В папку помещаю символические ссылки ( с краткими именами) на неомходимые мне программы
4 Вызов работает из любого места
Теперь можно сравнить с AppPaths
у меня также
Вадим, большое спасибо за очередную классную статью, но в ней, как в прочем и во всех остальных, есть один большой минус- чем больше я читаю Ваших статей, тем больше я понимаю, насколько мало я разбираюсь в этом , хоть и пытаюсь что- то как- то учить:). Грустно :)
jakv, интересный подход, но он очень похож на AppPaths. По сути разница в средствах достижения цели — вы используете файловую систему, а здесь задействован реестр.
Виталий, резервирование CON — хороший пример :) С другой стороны, вряд и у вас есть острая нбх в создании файла с таким названием.
С таблицей лучше не спорить :) Да, системные папки входят в PATH по умолчанию, о чем говорится в соотв. разделе статьи. Вряд ли их кто-то убирает оттуда, но это не отменяет факта, что командная строка зависит от PATH, а оболочка — нет.
Консоль не умеет искать в системных папках, именно эта разница отражена в таблице.
Интересно, а зачем нужны например
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\table30.exe
или
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\setup.exe
в которых значение по умолчанию не присвоено
Владимир, спасибо за отклик! Если честно, эта статья не открывает Америку — фича-то 95 года :)
Но интересно посмотреть на нее под другим углом. Во-первых, в контексте заданного мне вопроса. Действительно, исполняемые файлы из системных папок запускаются хоть в cmd, хоть в «Выполнить». Но не вполне очевидно, что из проводника можно запускать более широкий ассортимент файлов.
Второе «открытие» в том (если заглянуть в реестр), что без указания пути можно запускать очень многие программы. Это играет на руку ценителям клавиатуры (=более опытным пользователям), ибо для открытия программы достаточно нажать 3-4 клавиши. Например, Win+R — b — Enter (даже с более длинными псевдонимами получается не дольше, если включена автоподстановка).
А так, меня радует, что читатели пользуются возможностью повысить уровень знаний. Не все — один мне сегодня в почте выразил мысль, что теория не нужнна, достаточно REG-файла.
Я не считаю термин «чайник» зазорным (не стыдно не знать), однако незнание тонкостей работы Windows не означает, что человек не способен просканировать текст, проанализировать информацию и найти нужное. При условии, что автор сносно подал материал :)
jakv, хм… понятия не имел, пока не начал гуглить — вы пробовали? :)
table30.exe похоже на какое-то старье от Adobe — Adobe — PageMaker : For Windows : Adobe Table 3.04 Update (раньше была 3.0). Вряд ли кто-то еще делал программу с таким именем исполняемого файла.
setup.exe — трудно сказать. В библиотеках TechNet/MSDN нет объяснения параметров.
Но то, что туда нельзя прописывать пути — факт, иначе многие установщики не запустятся. Кстати, сама Microsoft попалась на этом, забыв подчистить после установки XP SP2 :) http://support.microsoft.com/kb/888470
Спасибо. Я начал искать , но так и не врубился.
Удивительно! Какая-нибудь тема из серии «мая программа круче» вызывает бурю эмоций и выплеск их в виде комментариев. А действительно интересный контент — 15 комментов. Удивительно!
Вадим, спасибо! Действительно интересная и полезная штука!
Интересно, он всё остальное тоже делает не зная ? :) Хотелось бы посмотреть на результат.
Morpheus, ничего удивительного. Фича для узкого применения опытными пользователями, которые запускают программы с клавиатуры. Что тут комментировать — ‘спасибо, не знал’ / ‘спасибо, знал’ :)
Да круто мне очень понравилась я каждый раз при запуске VB.net использовал пуск и мне захотелось добавить его но обнаружил что там уже стоить (devenv.exe) : ) но теперь буду использовать для других любимых программ…. Спасибо!
Скажу одно — ELE.
Да, я её сравнительно недавно написал, но после этого я использую только её. Я даже UAC готов пережить. Ибо удобно
Хуршед, да, все установленные программы можно найти в меню Пуск, если они там группу создают. Но из окна «Выполнить» получается быстрее.
Сергей Ткаченко, а при чем тут ELE? Допустим, тебе надо CMD запускать от имени админа и ты даже сделал командный файл ele cmd. Он у тебя должен лежать в PATH, чтобы путь не вводить. App Paths — альтернатива PATH, о чем и речь в статье.
Конечно, может быть проще кидать скрипты/утилиты в системную папку или добавлять условную папку Tools в PATH, но не для всех программ это удобно.
Я к тому, что cmd я запускаю с полными правами теперь только при помощи ELE. Я ничего не имею против алиасов App Paths, и не нападал на пути поиска исполняемых файлов :)
Вадим, спасибо большое, статья очень интересная, хотя я это знал. Вот только в Windows 8 DP у меня в папке windows есть именно приложение write.exe, оно же есть и в system32, а вот wordpad.exe уже нет. Так что, никто не забыт, ничто не забыто :D
Причем таких имен множество великое =)
CON, PRN, AUX, CLOCK$, NUL, COM1, COM2, COM3, COM4, LPT1, LPT2, LPT3. И также нельзя создать папку, имя которой начитается с точки.
Сергей Ткаченко, если работать с ограниченными правами, то планировщик не поможет — тут только ele. А так, если можно упростить жизнь, почему бы нет.
YaNkEE, wordpad лежит в другой папке — посмотрите путь в AppPaths. А write.exe как раз Wordpad и запускает, и будет это делать даже если вы переименуете этот раздел в App Paths.
Так что write.exe в том виде, что он был в 3.1, уже нет. Вы можете использовать параметры командной строки (имя файла — открытие, /p имя файла — печать), но по сути это ключи wordpad.
А вот почему у нас два write.exe, по одному в каждой системной папке, это уже другой вопрос :) В принципе, можно осветить его в отдельной записи, это любопытно.
А так же файлы или папки со знаками \ / : * ? » | При этом какой нибудь © размещается в имени без проблем.
И хотя создать папку, имя которой начинается с точки, нельзя, с такими папками можно работать.
Нельзя в проводнике, но в командной строке можно
Но притом это не ярлык, а просто копия программы с другим именем, и естественно, если убрать из AppPaths, то она будет из проводника вызываться и из cmd (так как в PATH есть system32). А в AppPaths ссылка именно на wordpad.exe с именем write, которая от этого write.exe не зависит.
YaNkEE, мимо кассы :)
1. Расположение wordpad не включено в PATH. Поэтому вызов из консоли не сработает (хотя это можно обойти вызовом write).
2. write.exe — это не копия программы wordpad. Да, это программа, но единственное ее назначение — запуск worpad. Больше она ничего не делает.
Причем расположение wordpad в нее зашито относительно жестко. Переименуйте write.exe в App Paths — wordpad продолжит запускаться командой write. Теперь перименуйте папку, где лежит wordpad. Ку? :)
Можно проводить серию пенальти между проводником и командной строкой :)
По моему, создать жёсткую ссылку на wordpad с именем write.exe было бы лучше, чем программку- запускалку.
Да, это хорошая идея (на первый взгляд ;), и думаю, что уже в понедельник мы как раз обсудим этот вопрос.
А пока подумайте, почему здесь не используется жесткая ссылка? Подсказкой будет ваша любимая ОС :)
Вадим, Вы меня не так поняли. Я и имел ввиду то, что в PATH есть ссылка на system32, поэтому выполнится write, даже если удалить ее из AppPaths. Но выполнится уже не ссылка на WordPad.exe из AppPaths, а именно сама write.exe из system32.
P.S. А вот насчет того, что write.exe просто запускает wordpad.exe и закрывается — Вы исключительно правы. Поэтому, если удалить из AppPath запись «write.exe», то будет с команды write будет запускаться не сам wordpad.exe, а write.exe (из PATH), которая в свою очередь уже вызовет wordpad.exe.
Программка в тему Rapid Environment Editor
okshef, в тему, но по-моему она нужна только тем, у кого 100500 переменных среды, которые постоянно приходится изменять. Я таких людей пока не встречал. А тебе она зачем?
YaNkEE, ок, я понял вас теперь. Меня заинтересовал описанный вами порядок поиска исполняемого файла. Не знаю, проверяли вы его или даже не задумывались о разных вариантах :)
MSDN просто перечисляет расположения, при этом App Paths идет последним в списке. Однако явно о приоритете там ничего не сказано.
Я проверил. Оболочка сначала ищет в App Paths, а потом уже в PATH или в системных папках. Логично, в свете того, что MSFT рекомендует именно App Paths для регистрации исполняемых файлов. Но проверить не повредит ;)
Думал, да ничего интересного и не придумал.
Скорее всего дело в совместимости со старым софтом, но конкретнее ничего сказать не могу.
Подожду понедельника.
Вадим, именно это я и имел ввиду. Сначала поиск происходит в AppPaths (там write — ссылка на wordpad.exe), а если там нет, то проверяет директории из PATH (а тут уже именно write.exe). Но еще разница в том, что cmd.exe не дружит с AppPaths, ссылки AppPaths работают только в проводнике, но об этом вы писали в статье.
Я вспомнил, что хотел сказать. В AppPaths под name.exe можно сделать ссылку не только на приложение, но и на любой файл, который откроется в программе по умолчанию. Например ссылка image.exe, а в адресе picture.jpg. Тогда, если запустить новую задачу и прописать image, то откроется та картинка.
Виталий, в принципе, в 7 технически ничего не мешало реализовать жесткую ссылку wordpad ↔ write (значок будет другой только), но в XP это было невозможно.
YaNkEE, практический смысл использования picture.jpg от меня ускользает. Возможно, с другим примером будет понятнее.
Вадим, ну или, например, html страница, сохраненная на диске. Смысл, конечно, может и не велик, но я говорил о возможности.
Хотя, вот, например: сохранены несколько плейлистов какого-нибудь проигрывателя. Создаем ссылки на них в AppPaths и в любой момент можем вызвать их, например, прописав: favorite — откроется любый плэйлист, rock — откроется плейлист с роком и т.д. И откроется-то он через программу, установленную по умолчанию, то есть ваш проигрыватель.
Почему? Можно было при установке на FAT32 делать две копии программы, а при установке на NTFS делать жёсткую ссылку.
Виталий, что-то вы мелочитесь. Я ожидал предложения внедрить в FAT поддержку жестких ссылок :)