Wiersz polecenia systemu Windows: jak uzyskać wynik polecenia w zmiennej środowiskowej?

Chcę mieć zmienną środowiskową, która zawiera dzień tygodnia w cmd.exe.

Po uruchomieniu tego polecenia otrzymuję pożądany wynik.

C:\Users\tisc> powershell (get-date).dayofweek
Friday

Tutaj próbuję zapisać wynik w zmiennej środowiskowej.

C:\Users\tisc> set dow = powershell (get-date).dayofweek

Ale kiedy próbuję go zdobyć, nie otrzymuję łańcucha tak, jak chciałem.

C:\Users\tisc> set dow
DoW=0
dow = powershell (get-date).dayofweek

Moim celem jest użycie zmiennej w pliku wsadowym dla niektórych skryptów kopii zapasowych.

Możesz użyć czegoś takiego jak:

$env:DOW = "foo"

Powinieneś uruchomić oba polecenia w PowerShell, ponieważ PowerShell jest więcej niż zdolny do manipulowania zmiennymi środowiskowymi.

To znaczy:

$dow = (get-date).dayofweek
[Environment]::SetEnvironmentVariable("DOW", $dow, "Machine")

lub

[Environment]::SetEnvironmentVariable("DOW", $dow, "User")

Nawiasem mówiąc, twój skrypt nie działa, ponieważ otrzymujesz tylko kod powrotu PowerShell, a nie generowane przez niego dane. Może istnieć sposób na uruchomienie go, ale jest to ostatecznie bezcelowe w porównaniu z użyciem odpowiedniego skryptu PowerShell.

Dla kompletności, oto miły artykuł od Microsoft na temat PowerShell i zmiennych środowiskowych:

Tworzenie i modyfikowanie zmiennych środowiskowych

Aktualizacja: po sprawdzeniu tego rozwiązania w @ syneticon-dj na czacie, wydaje się, że napotykasz problem przy użyciu tej metody, ponieważ wiersz polecenia musi zostać ponownie załadowany, zanim będzie odzwierciedlał zmiany zmiennych środowiskowych, które miały miejsce na zewnątrz.

Nie podałeś zbyt wielu szczegółów na temat tego, co robisz, ale jeśli jest to jedyny powód, dla którego uruchamiasz PowerShell, to moja rzeczywista sugestia sprawdzi, jak to robisz.

Albo cały proces używasz programu PowerShell, czy zamiast tego rozważasz użycie zaplanowanych zadań? Możesz planować zadania na podstawie dnia tygodnia.

Uważam, że ustawienie zmiennej środowiskowej w programie PowerShell za pomocą [Environment]::SetEnvironmentVariablesugerowanej przez Dana jest bezcelowe, ponieważ albo stracisz zawartość zmiennej po zakończeniu programu PowerShell, jeśli wybierzesz tymczasowy kontekst „procesu”, albo nie będzie go jeszcze w środowisku pliku wsadowego jeśli wybrałeś stały kontekst „komputer” lub „użytkownik” - to znaczy, chyba że cały skrypt jest napisany w PowerShell, gdzie problem nie pojawiłby się w pierwszej kolejności:

C:\Users\myuser> echo %DOW%
%DOW%

C:\Users\myuser> powershell
Windows PowerShell
Copyright (C) 2009 Microsoft Corporation. Alle Rechte vorbehalten.

PS C:\Users\myuser> $dow = (get-date).dayofweek
PS C:\Users\myuser> [Environment]::SetEnvironmentVariable("DOW", $dow, "User")
PS C:\Users\myuser> [Environment]::SetEnvironmentVariable("DOW", $dow, "Process")
PS C:\Users\myuser> exit

C:\Users\myuser> echo %DOW%
%DOW%

C:\Users\myuser>

Można użyć tego forpolecenia jako obejścia, aby przeanalizować dane wyjściowe polecenia PowerShell i umieścić je w zmiennej:

  for /F "usebackq tokens=1" %%i in (`powershell ^(get-date^).dayofweek`) do set DOW=%%i

Zwróć uwagę na znaki karetki ^używane do ucieczki z nawiasów specjalnych w wywołaniu PowerShell.

Jeśli testujesz go z wiersza poleceń, a nie z kontekstu pliku wsadowego, musisz zastąpić %%odniesienia przed zmiennymi przez %:

C:\Users\myuser> for /F "usebackq tokens=1" %i in (`powershell ^(get-date^).dayofw
eek`) do set DOW=%i

C:\Users\myuser> set DOW=Friday

C:\Users\myuser>

Gdyby było mnie, a skrypt rodzic ma być skrypt, to bym po prostu zrobić bezczelny wywoływanie PowerShell w skrypcie cmd jak:

set DOW=
for /f %%D in ('%SystemRoot%\System32\WindowsPowerShell\V1.0\powershell.exe -NoLogo -NoProfile -Command Write-Host -Object ^(Get-Date^).DayOfWeek;') do set DOW=%%D

Może być konieczne sprawdzenie zasad wykonywania programu PowerShell (polecenie cmdlet Set-ExecutionPolicy).

Lub jeśli jesteś żonaty, robiąc to w starej powłoce, całkowicie pomiń PowerShell.

Użyj zmiennej% date% i rozwiń dzień ze skrótu, który daje (może to mieć wpływ na ustawienia regionalnego formatu daty):

C:\> echo %date%
Thu 09/05/2013

Chwyć pierwszy token w odpowiedzi i rozwiń na nim:

C:\> type dayofweek.cmd
@echo off
for /f %%A in ("%date%") do set DAYOFWEEK=%%A
if "%DAYOFWEEK%" == "Mon" set DAYOFWEEK=Monday
if "%DAYOFWEEK%" == "Tue" set DAYOFWEEK=Tuesday
if "%DAYOFWEEK%" == "Wed" set DAYOFWEEK=Wednesday
if "%DAYOFWEEK%" == "Thu" set DAYOFWEEK=Thursday
if "%DAYOFWEEK%" == "Fri" set DAYOFWEEK=Friday
if "%DAYOFWEEK%" == "Sat" set DAYOFWEEK=Saturday
if "%DAYOFWEEK%" == "Sun" set DAYOFWEEK=Sunday
echo.%DAYOFWEEK%
C:\>
C:\> dayofweek
Thursday

W rzeczywistości, umieszczając coś takiego jak poniżej w pliku .ps1 (powiedzmy t.ps1) i wywołując go z sesji CMD za pomocą PowerShell -File t.ps1... działa dobrze.

$DateAndTime = (get-date -UFormat "%Y%m%d_%H%M%S")[Environment]::SetEnvironmentVariable("DateAndTime", $DateAndTime, "Machine")

Ale nie w przypadku sesji CMD, z której został wywołany skrypt t.ps1. W nowej sesji CMD otrzymujemy:

D:> echo% DateAndTime% ==> 20120208_123106

Chyba musimy dowiedzieć się, jak zrobić coś takiego jak export T=datesesja CMD.

Jeśli chcesz, aby plik wsadowy miał dostęp do zmiennych środowiskowych ustawionych za pomocą polecenia PowerShell, uruchamianego z tego pliku wsadowego, możesz zastosować następujące obejście:

Spraw, aby skrypt PowerShell utworzył plik wsadowy podrzędny mysub.bat, który zawiera wiersze „ustaw zmienną = wartość”, i uruchom ten plik wsadowy mysub.bat z głównego pliku wsadowego zaraz po poleceniu PowerShell.

Użyj metody WriteAllLines zamiast domyślnych metod wyjściowych PowerShell, aby plik wsadowy nie był generowany w formacie kodowania UTF-8.

Przykład

main.bat:

REM main.bat first line
powershell -Command "[System.IO.File]::WriteAllLines(\".\mysub.bat\", \"set VARIABLE=VALUE\");"
.\mysub.bat
echo VARIABLE=%VARIABLE%
REM expected output: VARIABLE=VALUE