А>в myConsoleApplication написанном на шарп А>есть System.Environment.SetEnvironmentVariable("RRR", "333");
А>почему после выполнения some.bat %RRR% равно 0? как вернуть в бат нужные environment?
Здравствуйте, Nuseraro, Вы писали:
N>Здравствуйте, Аноним, Вы писали:
А>>есть some.bat А>>set RRR=0 А>>myConsoleApplication.exe А>>echo %RRR%
А>>в myConsoleApplication написанном на шарп А>>есть System.Environment.SetEnvironmentVariable("RRR", "333");
А>>почему после выполнения some.bat %RRR% равно 0? как вернуть в бат нужные environment?
N>Почти так как вы думали: N>
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Nuseraro, Вы писали:
N>>Здравствуйте, Аноним, Вы писали:
А>>>есть some.bat А>>>set RRR=0 А>>>myConsoleApplication.exe А>>>echo %RRR%
А>>>в myConsoleApplication написанном на шарп А>>>есть System.Environment.SetEnvironmentVariable("RRR", "333");
А>>>почему после выполнения some.bat %RRR% равно 0? как вернуть в бат нужные environment?
N>>Почти так как вы думали: N>>
А>я, тогда, перепробывал все EnvironmentVariableTarget, и это не помогло. А>Думаю, проблема в другом
У Вас не работает с EnvironmentVariableTarget.Machine? У меня вроде работает. И set, и Environment.GetEnvironmentVariable. Хотя всех тонкостей не знаю. А в общем списке (set без параметров) что показывает?
Можно еще Process.Start просто применить на худой конец наверное...
Здравствуйте, Nuseraro, Вы писали:
А>>почему после выполнения some.bat %RRR% равно 0? как вернуть в бат нужные environment?
N>Почти так как вы думали: N>
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Дело в том, что окружение создается при запуске процесса. Если его изменить для машины, то это повлияет на новые процессы, но не на уже запущенные.
PD>bat — это тоже процесс (реально ntvdm.exe). И запуск myConsoleApplication.exe ничего не изменит в окружении этого процесса на основе bat-файла.
PD>В данном случае надо повлиять на окружение родительского процесса. Легальных средств для этого нет.
Дополню немного, с Вашего разрешения.
Переменные окружения хранятся между сеансами работы в ключах Environment соответствующих веток реестра, отдельно для каждого из пользователей и общие для системы. Блок окружения процесса создаётся при входе пользователя их объединением и далее наследуется от процесса к процессу, если специально не указано иного. Функция WinApi SetEnvironmentVariable изменяет значение только в окружении текущего процесса. Для внесения персистентных изменений, необходимо новое знвчение занести в реестр, что видимо и делает перегруженная версия Environment.SetEnvironmentVariable. Но эти изменения не будут видны другим процессам, в том числе и новым, в существующих сессиях. Чтобы они стали видны, нужно пересоздать блок окружения, то есть в общем случае перелогиниться или перезагрузиться. В принципе, при изменениии настроек принято рассылать WM_SETTINGCHANGE. Но отправить её мало, нужно ещё чтобы получатели отреагировали должным образом, что имеет место далеко не всегда.
Исходя из изложенного, можно из батника передать через окружение новое значение запускаемому им процессу, но не в обратную сторону. Этим, кстати, пользуются CGI приложения. Входные параметры они получают через переменные окружения, а результат пишут в стандартный вывод.
Здравствуйте, Мизантроп, Вы писали:
М>Дополню немного, с Вашего разрешения.
Поправлю немного, с Вашего разрешения
М>Но эти изменения не будут видны другим процессам, в том числе и новым, в существующих сессиях. Чтобы они стали видны, нужно пересоздать блок окружения, то есть в общем случае перелогиниться или перезагрузиться.
Нет. Проверяем.
Запускаем FAR
C:\>set RRR
Environment variable not defined
Запускаем myConsoleApplication.exe из под админа с таким кодом
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Поправлю немного, с Вашего разрешения
Это не противоречит сказанному мной, просто это частный случай, а я специально указал, что перелогин требуется в общем случае.
Другой частный случай. В консольном приложении пишем
Запускаем раз, выводит "evv =". Запускаем ещё раз, выводит то-же самое. Перелогиниваемся, запускаем — выводит "evv = 33". Просто кто-то реагирует на WM_SETTINGCHANGE с "Environment", а кто-то нет. Потому я бы не посоветовал закладываться на такое поведение, если-бы моего совета кто-нибудь спросил
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет. Проверяем.
PD>Запускаем FAR
Видимо какой-то плагин для фара который рефрешит. Или версия более поздняя чем у меня.
У меня фар сам не ловит изменения глобальных переменных. Мало того, cmd запускаемый из процесса наследует его переменные.
>set RRR
Переменная среды RRR не определена
>type ..\..\Program.cs
я¬¬using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace ConsoleApplication3
{
class Program
{
static void Main(string[] args)
{
var t = args.Length > 0 ? args[0] : "worked";
Environment.SetEnvironmentVariable("RRR", t, EnvironmentVariableTarg
et.Machine);
}
}
}
>cmd
Microsoft Windows XP [Версия 5.1.2600]
(С) Корпорация Майкрософт, 1985-2001.
>set RRR
Переменная среды RRR не определена
Вот если запустить cmd из эксплорера (Win+R например), то он уже получит новые переменные из реестра.
Microsoft Windows XP [Версия 5.1.2600]
(С) Корпорация Майкрософт, 1985-2001.
C:\Documents and Settings\ziaw>set RRR
RRR=test
C:\Documents and Settings\ziaw>
З.Ы. Хочу такой же плагин к фару, или достаточно обновить сам фар?
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Нет. Проверяем.
PD>>Запускаем FAR
Z>Видимо какой-то плагин для фара который рефрешит. Или версия более поздняя чем у меня.
Такое поведение у FAR сколько я его помню. И FAR тут ни при чем.
Сделал совершенно те же действия, но запускал CMD вмето FAR. Эффекты 1:1
Здравствуйте, Pavel Dvorkin, Вы писали:
Z>>Видимо какой-то плагин для фара который рефрешит. Или версия более поздняя чем у меня.
PD>Такое поведение у FAR сколько я его помню. И FAR тут ни при чем.
Значит влияет что-то другое, оффициальная дока ничего не говорит о авторефреше машинных переменных.
In the command shell, each instance of Cmd.exe inherits the environment of its parent application. Therefore, you can change the variables in the new Cmd.exe environment without affecting the environment of the parent application.
PD>Сделал совершенно те же действия, но запускал CMD вмето FAR. Эффекты 1:1
У меня тоже 1:1 только эффект противоположный
Сколько помню, столько и наблюдал такое поведение, после иземенения переменных в свойствах компьютера всегда рестартил фар или шелл
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, Pavel Dvorkin, Вы писали:
Z>>>Видимо какой-то плагин для фара который рефрешит. Или версия более поздняя чем у меня.
PD>>Такое поведение у FAR сколько я его помню. И FAR тут ни при чем.
Z>Значит влияет что-то другое, оффициальная дока ничего не говорит о авторефреше машинных переменных.
А я разве говорю об авторефреше ? прочти внимательно, что я написал.
Z>
Z>In the command shell, each instance of Cmd.exe inherits the environment of its parent application. Therefore, you can change the variables in the new Cmd.exe environment without affecting the environment of the parent application.
Совершенно верно.
PD>>Сделал совершенно те же действия, но запускал CMD вмето FAR. Эффекты 1:1
Z>У меня тоже 1:1 только эффект противоположный Z>Сколько помню, столько и наблюдал такое поведение, после иземенения переменных в свойствах компьютера всегда рестартил фар или шелл
Так я о том же и говорю — новая копия FAR получит эту переменную Уже запущенные остаются при своем.
Z>In the command shell, each instance of Cmd.exe inherits the environment of its parent application. Therefore, you can change the variables in the new Cmd.exe environment without affecting the environment of the parent application.
Стоит, вероятно, добавить, что все процессы, не только CMD, по умолчанию наследуют своё окружение от родительского процесса, и об этом сказано в описании CreateProcess, если правильно помню. А для всех пользовательских процессов в родителях (прямо или опосредованно) числится shell, от него и наследуется окружение. (Отдельная история с RunAs) То есть если мы в своём процессе добавим в своё окружение какую-то переменную или наоборот, удалим, а потом запустим какой-нибудь процесс, то в этом новом процессе будут видны сделанные нами изменения.
Другое дело, что в частных случаях в CreateProcess можно передать собственноручно созданный блок окружения, в том числе и считав его из реестра. Но это частный случай. Другой частный случай, что у нового процесса может вообще оказаться пустой блок, если передать в CreateProcess соответствующим параметром указатель на ноль
1. Запускаем CMD (назову его CMD1)
C:\>set 333
Environment variable not defined
2. Запускаем .cs программу
3. Запускаем новый CMD -2
C:\>set RRR
RRR=333
4. Из CMD1 запускаем CMD3. Он запустится в той же консоли, но это не важно — по Task Manager видно, что запустился новый cmd
C:\>set 333
Environment variable not defined
4. Из CMD2 запускаем CMD4. Он запустится в той же консоли, но это не важно — по Task Manager видно, что запустился новый cmd
C:\>set RRR
RRR=333
5. Удаляем RRR для компьютера
6. Из CMD4 запускаем CMD5
C:\>set RRR
RRR=333
хотя в системе этой переменной уже нет
Подводим итоги.
При запуске CMD из shell shell берет новую информацию из реестра. Видимо, shell это умеет. Например, он мог подписаться на RegNotifyChangeKeyValue. Или просто перечитать значение из реестра. После этого shell запускает новый процесс с измененным окружением.
Сам CMD этого не умеет. Поэтому он просто запускает новый процесс, передавая NULL в соответствующем параметре CreateProcess, что приводит к копированию его окружения в новый процесс. Поэтому CMD5 получил эту переменную, хотя ее уже нет в машине.
Аналогично CMD будут вести себя и другие программы-стартеры, если они не позаботятся о том, чтобы прочитать значения из реестра
На всякий случай утоню
М>То есть если мы в своём процессе добавим в своё окружение какую-то переменную или наоборот, удалим, а потом запустим какой-нибудь процесс
Имелось в виду — запустим новый процесс из того, в котором вносили изменения в его окружение. То есть изменяем вызовом
"Нормальные герои всегда идут в обход!"
