#windows #batch-file #cmd #timeout #abort
Вопрос:
У меня есть пакетный файл Windows, который соединяет несколько сетевых дисков. Сначала он проверяет серверы, и если это удается, он затем пытается сопоставить общий ресурс с net use ...
:
SET host=mini3
IF /I NOT %host% == %COMPUTERNAME% (
ping -4 -n 2 -w 1000 %host% | find "TTL=" > NUL
IF !ERRORLEVEL! EQU 0 (
echo Q: == \%host%Q_ -- mini3-Volumes
net use Q: \%host%Q_ /persistent:yes > NUL amp;amp; echo OK
) ELSE (
echo %host% not found. Skipping.
)
)
Иногда, даже если машина доступна по пингу, net use
команда зависает навсегда. Причина, по которой он зависает, по-видимому, связана с неправильной настройкой сервера SMB и/или учетных данных Windows, хранящихся на клиенте.
Поэтому, когда это произойдет, по какой бы то ни было причине, я хотел бы напечатать ошибку и перейти к следующему диску для сопоставления.
Команда Windows Timeout
, по-видимому, на самом деле является командой «задержка», эквивалентной Unix sleep
, а не таймаутом.
Есть ли хороший способ установить реальный тайм-аут для net use
команды, не прерывая весь сценарий .cmd?
Ответ №1:
С несколькими модами у меня нет проблем, ключ исправлял %уровень ошибок%, поскольку задержка во время выполнения не была включена/необходима, сопоставления дисков создаются независимо, поэтому задачи могут выполняться, если все хорошо, должна быть краткая вспышка, в противном случае, если общий ресурс не найден, они должны естественным образом отключиться.
Адвент в моем случае-это еще одна рабочая станция, а не сервер. Измените это обратно на mini3
@echo off
SET "host=Advent"
IF /I NOT "%host%"=="%COMPUTERNAME%" (
ping -4 -n 2 -w 1000 %host% | find "TTL=" > NUL
IF %ERRORLEVEL% EQU 0 (
echo Q: == \%host%Q_ -- %host%-Volumes
START "Z Drive" net use Z: \%host%users /persistent:yes
START "Q Drive" net use Q: \%host%Q_ /persistent:yes
REM surplus from above line > NUL amp;amp; echo OK
) ELSE (
echo %host% not found. Skipping.
)
)
rem delay this file so it waits to let the new connections process above
timeout 2
net use | find ":"
Комментарии:
1. Действительно, проблема заключалась в
> NUL
перенаправлении в тех случаях, когда приходилось запрашивать имя пользователя/пароль. Теперь все равно было бы полезно найти Windows-эквивалент команды Unixtimeout
, но это, вероятно, должен быть отдельный вопрос.