Set path не работает
| Конфигурация компьютера |
| ОС: Windows 10 Pro x64 Release Preview |
| хотя в переменный средах всё в порядке, в PATH прописано %systemroot%, %systemroot%\system32, %systemroot%\system32\Wbem » |
Неправильно прописано. Разделитель должен быть точка с запятой, пробелов быть не должно.
Приведите вывод команды
——-
Канал Windows 11, etc | Чат @winsiders
Это сообщение посчитали полезным следующие участники:
| () * / % + — > & ^ | = , | — группировка — арифметические операторы — арифметические операторы — двоичный сдвиг — двоичное И — двоичное исключающее ИЛИ — двоичное ИЛИ — присвоение — разделитель операторов |
При использовании любых логических или двоичных операторов необходимо заключить строку выражения в кавычки. Любые нечисловые строки в выражении рассматриваются как имена переменных среды, значения которых преобразуются в числовой вид перед использованием. Если переменная с указанным именем не определена в системе, вместо нее подставляется нулевое значение. Это позволяет выполнять арифметические операции со значениями переменных среды, причем не нужно вводить знаки % для получения значений. Если команда SET /A вызывается из командной строки, а не из пакетного файла, она выводит окончательное значение выражения. Слева от любого оператора присваивания должно стоять имя переменной среды. Числовые значения рассматриваются как десятичные, если перед ними не стоит префикс:
0x — для шестнадцатеричных чисел
0 — для восьмеричных чисел.
Пример использования префиксов:
SET /A REZ=0xA+012
ECHO %REZ%
В данном командном файле значение переменной REZ вычисляется сложением числа 10, представленного в шестнадцатеричном виде ( 0xA ) и числа 10 , представленного в восьмеричном ( 012 ).
Ключ /P позволяет установить значение переменной для входной строки, введенной пользователем. Показывает указанное приглашение promptString перед чтением введенной строки. Приглашение promptString может быть пустым. Данный ключ позволяет организовать диалог с пользователем в командном файле:
@ECHO OFF
SET /P NAME=Введите имя пользователя:
SET /P pass=Введите пароль:
ECHO Имя пользователя — %NAME% , Пароль — %PASS%
В командных файлах довольно часто требуется работать с частью значения, принимаемого переменной, для чего используются подстановочные значения:
переменная:строка1=строка2 — заменяет в принимаемом значении переменной строку1 на строку2
Следующий командный файл использует замену символа «точка» на символ «тире» в значении переменной, соответствующем текущей дате:
@ECHO OFF
set tm=%DATE%
ECHO Дата1 = %tm%
SET tm=%DATE:.=-%
ECHO Дата2 = %tm%
Для выделения части значения, принимаемого переменной, используется следующая конструкция:
x,y — где x — число пропускаемых символов от начала строки, а y — количество символов, используемых в качестве значения переменной.
Следующий пример использует отображение текущего времени без секунд и долей секунд (только первые 5 символов из стандартного значения переменной TIME):
@ECHO OFF
set tm=%TIME%
ECHO Время1 = %tm%
SET tm=%TIME:
0,5%
ECHO Время2 = %tm%
Если значение y ( длина ) не указана, то используется оставшееся до конца строки значение переменной. Если значение y отрицательно, то используется часть строки значения переменной от конца. Предыдущий пример можно изменить , указав, что в принимаемом значении времени отбрасываются 6 символов от конца:
@ECHO OFF
set tm=%TIME%
ECHO Время1 = %tm%
SET tm=%TIME:
Возможно использование число пропусков не задано, и используется отрицательное число, то принимаемое значение будет частью переменной от конца строки:
-10% — извлечет последние 10 символов переменной PATH
. Нулевое значение можно не указывать, сохраняя формат подстановки:
0,-2% эквивалентно %PATH:
При использовании переменных окружения в командных файлах существует определенное ограничение, связанное с тем фактом, что присваиваемое значение остается без изменения при его модификации внутри группы команд, задаваемой скобками, например в командах IF или FOR . Для обхода данного ограничения используется запуск командного процессора с параметром /V:ON и вместо знаков процента, для получения принимаемого переменной значения, используются восклицательные знаки. Кроме того, существует возможность использовать стандартный запуск командного процессора, но с локальным включением данного режима командой :
Разница в результатах использования значений переменных довольно наглядно демонстрируется следующим командным файлом:
Setlocal EnableDelayedExpansion
@ECHO OFF
set VAR=before
if «%VAR%» == «before» (
set VAR=after
if «!VAR!» == «after» @echo Со знаком процента=%VAR% , Со знаком вопроса=!VAR!
)
Команда set VAR=after выполняется внутри подпрограммы, ограниченной скобками и, если убрать команду Setlocal EnableDelayedExpansion или не использовать для получения значения переменной VAR восклицательные знаки, ее значение останется старым ( тем, что было установлено до входа в подпрограмму ). Аналогичная же проблема наблюдается и тогда, когда значение переменной изменяется внутри цикла команды FOR . Например, для получения списка файлов текущего каталога такой командный файл не будет работать:
set LIST=
for %%i in (*) do set LIST=%LIST% %%i
echo %LIST%
Значение переменной LIST внутри цикла изменено не будет. Для того, чтобы это произошло, командный файл нужно изменить следующим образом:
Setlocal EnableDelayedExpansion
set LIST=
for %%i in (*) do set LIST=!LIST! %%i
echo %LIST%
Теперь, значение переменной LIST внутри цикла FOR будет изменяться, последовательно принимая значения имен файлов, разделенных пробелом ( set LIST=!LIST! %%i )
Источник
[Статья] Дело о заблокированной переменной окружения %PATH%
Дело о заблокированной переменной окружения %PATH%.
Как-то раз мне потребовалось отсканировать документ, но при попытке открыть интерфейс сканера появилась ошибка:
Согласно одному из советов на официальном сайте было предложено добавить папку с библиотеками сканера в переменную PATH, что я и сделал по своей же инструкции:
- Скопировал в буфер обмена нужный путь (у меня это «C:Windowstwain_32CNQL25», без кавычек)
- Открыл оснастку «Система» быстрой комбинацией Win + R
- Нажал слева «Дополнительные параметры» => «Переменные среды»
- В группе «Системные переменные» нашел переменную PATH, «Изменить»
- Поставил курсор в конец строки с полем «Значение переменной» и убедился, что в конце строки есть знак «точка с запятой»
- И нажал «Вставить из буфера» по ПКМ.
Но ничего не вставилось , а в колонках раздался радостный звук «Дзыньк» =)))
Первая мысль – в буфер обмена ничего не скопировалось (хотя в этом случае пункт «Вставить» должен был быть серым).
Ну да ладно, гадать не буду, и решил просто вручную набрать путь с клавиатуры.
Но не тут-то было.
В ответ всё те же радостные звуки «Дзыньк-дзыньк».
Да нет же, проверил в блокноте, всё нормально набирается.
Что же делать?
1. Способ дилетанта
PATH можно заменить несколькими способами, и поскольку мне нужно было срочно отсканировать документ, мне было все равно как это сделать, и не было времени разбираться с ошибкой.
PATH – это особая переменная, которая собирается из двух параметров PATH в ключах реестра:
Учитывая, что у меня на полочке лежит недописанная статья о переменных окружения, было нетрудно «вспомнить» этот путь, перейти туда, открыв «Редактор реестра» (Win + R, regedit), и отредактировать значение параметра PATH.
OK, перезагрузка, и ошибка со сканером пропала.
Отступление от темы статьи:
Доброго времени суток. Дали задачу реализовать алгоритм поиска исполняемых файлов в CMD. Мне нужно.
Переменная окружения PATH
Зачем нужна переменная PATH?
Переменная окружения PATH
напишите пожалуйста как будет выглядеть прога которая дополняет значение PATH именем каталога.
Слетели переменные окружения PATH
Всем доброго времени суток. Собственно у меня полностью слетели переменные окружения и Builder XE.
2. Способ рядового исследователя
И вот, наконец, появилось время разобраться, что же происходит с PATH.
Новая мысль – заблокированы права (политики? список контроля доступа (DACL) ? ).
О политиках я не слышал, чтобы была такая, контролирующая PATH (но не исключаю).
А на счёт списка прав – они назначаются только на весь ключ реестра, а не на конкретный параметр (в нашем случае переменную). Т.е., если заблокирована PATH, то тоже самое должно происходить и со всеми соседними переменными.
Эксперимент.
Возьму первую попавшуюся – переменную «OS».
Пробую – и бац, в оснастке «Переменные среды» её значение легко поменялось.
Так-то. Давайте подойдём с другой стороны:
а что на счёт консоли?
Командная строка CMD (Win + R, cmd) позволяет также менять значение PATH, но это работает только в границах сессии консоли, а не на всю систему.
Там даже есть отдельная внутренняя команда Path. Но мы обойдёмся без неё.
Добавим для теста наш путь командой:
Получили «Отказано в доступе».
Любопытно.
Всё таки: проблемы в правах?
А что если просто распечатать содержимое?
Вот так новость. Я её даже не могу распечатать!
Попробуем с правами администратора?
Именем святого Админа, запускаем командную строку:
Нет, всё же, не везёт нам.
Может дело просто в каких-то спецсимволах в путях? Ком. строка очень не любит всякие птички ^, скобки и прочее.
Давайте заключим содержимое в кавычки:
Вуаля
И даже работает присвоение:
Хорошо. Но в чём именно проблема?
Я скопировал в блокнот всё значение (взял из реестра).
И методом половинного деления начал подставлять эту строку в echo.
В итоге выяснилось, что где-то в средину пути попала такая штука:
Символ перенаправления строки в файл >.
В итоге, вместо того, чтобы распечатать строку на экран консоли, она пыталась вывести её в файл C:\Windows\System32;C:\Windows;C:\Wi… не являющийся корректным именем. Из-за чего и возникала ошибка «Отказано в доступе»
А что же на счёт системы?
> — это недопустимый символ для пути. Получается, всё это время система «глючила» из-за него?
Открыв редактор реестра, я удалил знак > из параметра PATH.
(заодно заметив, что у меня 2 раза повторяются все пути, но пока решил это не трогать).
ОК, ещё раз захожу в оснастку «Система» в «переменные окружения», пытаюсь изменить значение PATH, и … снова не получается.
Но тут всё понятно:
Известно, что каждый процесс хранит в памяти блок переменных окружения, и не изменяет его, пока система не отправит специальное сообщение. И даже в этом случае процесс не обязан обновить переменные.
Так что мы просто перезапустим процесс explorer, который отвечает за загрузку окон оснасток (напомню, это можно сделать через Ctrl + Shift + ПКМ по окну в меню «Пуск»).
Или, что более надёжно, перезагрузим всю систему.
Вот уже появились ярлычки. Захожу, проверяю, и …
Каково было удивление, но ничего не сработало. Символы опять не печатаются в поле «Значение переменной». ))))
Но не отчаиваемся. Остался один очевидный факт:
1) Два раза дублируются пути
2) Строка с содержимым Path какая-то уж слишком длинная
3) Заметил, что в поле «Значение переменной» хоть и нельзя печатать, но можно удалять символы.
Итак, ограничение по длине?
Но, какого рода лимит?
Может, предел для длины значения параметра реестра?
Открываем базу знаний Micosoft: Registry Elements Size Limits.
А наша строка = 2271 символов.
Пишут, что в Win2k был жесткий лимит – в 260, но это только для ANSI-версий API-функций, а внутренне – строки хранятся в реестре все равно в Unicode. Точнее, в смешанном виде ANSI + Unicode (механизм оптимизации, детальнее о котором писал Руссинович в «Windows Internals»). Да и у меня под руками Windows 7, так что не вариант.
Эксперимент.
Поскольку оснастка даёт нам право удалять символы, а давайте так и сделаем.
Будем удалять их до тех пор, пока текстовое поле не позволит нам вводить новые символы.
И… ура, сработало
После нескольких десятков удалённых, нам позволили наконец-то вводить новые символы (не пришлось даже нажимать кнопку «ОК»).
Давайте же замерим, сколько получилось в итоге максимальное число символов.
Мой любимый AkelPad показывает что их – 2047.
Вот как. И что же за магическое число 2047 ?
Спросим у великого гуру – Google: «Path limit 2047»
Первая же ссылка ведёт на довольно любопытную статью от Karthiyayini C. (из Intel): Limitation to the length of the System PATH variable.
В ней даётся таблица с симптомами «переполнения» переменной PATH, когда её длина >= 2048 символов:
| Размер PATH | Windows XP, Windows Server 2003 | Windows 7, Windows 8, Windows Server 2008 |
|---|---|---|
| = 2048 и | ||
| = 4096 байтов | пп. 1, 2, 3, 4, 5 и 6 так же, как выше | пп. 1, 2, 3, 4, 5 и 6 так же, как выше |
| “Дополнительные параметры системы” не отображают большинство переменных окружения, включая PATH | “Дополнительные параметры системы” не отображают большинство переменных окружения, включая PATH | |
| После перезапуска системы, PATH больше не пустая, но обрезана до 2048 символов | После перезапуска системы, PATH больше не пустая, но обрезана до 4096 символов |
Решение проблемы даётся тоже весьма любопытное: перезагрузить систему, и она сама обрежет переменную до максимально допустимого размера.
Этого я, честно говоря, не наблюдал у себя, как и отказ системы запустить блокнот без указания полного пути. Но я особо и не пытался повторить эксперимент Intel. Может, у вас, читатели, это получится.
Заодно, и обратите внимание, что согласно статье Intel превышение длины значения PATH (больше 2047, и более серьёзные последствия, если больше 4095 символов) может привести к таким проблемам, как сбои в работе оснастки «Дополнительные параметры системы», а также других программ, зависящих от корректной работы этой переменной, т.к. значение обрезается.
Итог и решение проблемы.
Для однозначного решения проблемы остаётся второй вариант (также предложенный и в статье от Intel) – это обрезать значение самому.
После удаления лишних путей в строке PATH и приведения её длины до приемлемых размеров (меньше 2048 символов) я записал это значение через «Редактор реестра» в параметр PATH ключа HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment.
Проблема решена.
А сегодня мой сканер работает нормально даже в моей основной системе. Уж не знаю, связана ли его проблема была с PATH или нет. Но лично я доволен.
А моя статья надеюсь, ещё принесёт кому-то пользу, как и увлекательный рассказ о процессе поиска виновника, который может сподвигнуть вас на использование похожих методов при поиске и решении других видов неисправностей.
Источник