Хотя приведенный выше пример Shez является хорошим стандартным способом сбора ошибок от большинства программ на основе dos, которые устанавливают ERRORLEVEL и выдают выходные данные из стандартной ошибки (2>), ftp.exe из коробки от MS не устанавливает ERRORLEVEL. ERRORLEVEL остается равным нулю, независимо от того, успешно выполняется сценарий (-s: параметр) или нет. Перенаправление стандартной ошибки (2>) в «% ERRORFILE%» также не работает, так как этот файл всегда будет нулевым байтовым файлом (поскольку ftp.exe всегда возвращает ERROR_SUCCESS или 0), поэтому создается только пустой файл. Итак, командная строка:
ftp -i -s:"%FTPFILE%" >"%OUTPUTFILE%" 2>"%ERRORFILE%"
никогда не даст ожидаемых результатов. Если мы вынуждены использовать Microsoft FTP-клиент, лучше всего проанализировать% OUTPUTFILE% для определенных текстовых строк, указывающих на ошибку, или использовать другой FTP-клиент, отличный от MS (например, IPSWITCH WS_FTP), который обеспечивает лучшее отслеживание ошибок. Я продолжу с примерами кода того, как разобрать% OUTPUTFILE% через несколько часов, как только я закончу кодировать его методом грубой силы. Спасибо!
Следовать за
Смотрите мой второй пост ниже для примера интерактивного сеанса Microsoft FTP. Пример разбора следующий ...ОК, то, что следует, - это вариант поста Мартина S на stackoverflow.com здесь. Мое решение использует FINDSTR и отдельный текстовый файл, содержащий критерии поиска:
Создайте текстовый файл (FTP_ERR_SEARCH_CRITERIA.txt), содержащий следующие текстовые строки:
not connected
not found
failed
Вызовите следующую подпрограмму из вашего командного / командного файла:
::
::=============================================================================
:WIN_FTP_ERROR %1=%_SearchCriteria% %2=%_InputFile%
::=============================================================================
::
set _SearchCriteria=%1
set _InputFile=%2
set _tokens="tokens=*"
for /F %_tokens% %%G in ('findstr /I /G:%_SearchCriteria% %_InputFile%') do @echo "%%G"
exit /b
Вызов:
call :WIN_FTP_ERROR ".\FTP_ERR_SEARCH_CRITERIA.txt" %OUTPUTFILE%
Образец вывода Microsoft FTP
Продолжая, где я остановился ... Иногда лучший способ узнать, как что-то работает, - это проверить это самостоятельно, а не полагаться на множество дезинформации, найденной в Интернете. Так что вот так. В приведенном ниже примере показаны два разных файла: tst.txt и tst.tx (небольшая разница в названии, но одинаковая разница). Тст TXT- файл существует в то время как TST. ткс нет.
Пример Microsoft FTP (для ясности добавлен интервал):
ftp> put tst.txt
200 PORT command successful.
150 Opening ASCII mode data connection for tst.txt.
226 Transfer complete.
ftp: 44 bytes sent in 0.19Seconds 0.24Kbytes/sec.
ftp> put tst.tx
tst.tx: File not found
ftp> get tst.tx
200 PORT command successful.
550 tst.tx: The system cannot find the file specified.
ftp> get tst.txt
200 PORT command successful.
150 Opening ASCII mode data connection for tst.txt(44 bytes).
226 Transfer complete.
ftp: 44 bytes received in 0.00Seconds 44000.00Kbytes/sec.
Обратите внимание, как локальная файловая система и удаленная файловая система реагируют на приведенные выше команды:
для первого положенного тст. Команда txt (файл существует в локальной файловой системе), мы видим, что удаленный сервер отвечает, передавая файл.
для второго пут TST. Команда tx (файл tst.tx не существует ни в одной из систем). Мы видим, что локальная файловая система отвечает именем файла tst.tx и сообщением об ошибке File not found.
для третьего получить тст. Команда tx (снова файл tst.tx не существует), мы видим, что удаленная файловая система (фактически удаленный хост FTP) отвечает кодом ошибки FTP 550, именем файла tst.tx и сообщением об ошибке Системе не удается найти указанный файл ,
за четвертый и последний получить тст. Команда txt (файл теперь существует в удаленной системе), мы видим, что удаленная система отвечает успешной передачей.
Зачем все это объяснение? Это имеет значение, когда мы анализируем файл в предыдущем посте, чтобы увидеть, какие сообщения об ошибках возвращаются из MS ftp.exe.