vbscript does .exec("ftp"), then hangs while accessing stdout and stderr

vbscript does .exec("ftp"), then hangs while accessing stdout and stderr

Post by MLevi » Thu, 29 Sep 2005 22:15:50


I am trying to write a vbscript ftp crawler. Using wscript.shell .run,
I can run ftp with some pre-generated script. If I want to go
recursively into folders, I should repeat running ftp again and again
and again.

I was wondering, if I can indeed control the ftp through wscript.shell
.exec, printing ftp commands and reading ftp responses through stdout
and stdin.

With some simulated CMD script (prints ftp messages, waits for inputs)
this works -- my script grabs what execed prints and submits some test
words into it.

But when I try to run the real ftp.exe, either directly, or through
comspec /c, or through some CMD script, there is always the same

When accessing stdout or stderr AtEndOfStream property, or reading from
them, cscript stops and waits forever. I mean, I can not even check for
AtEndOfStream, because this check never ends!

An example, the following script, running as cscript //nologo test1.vbs

Dim oWSH, oExec
Dim oStdout, oStdin
Dim sInput, cInput
Dim sRead

Set oWSH = CreateObject ("WScript.Shell")

WScript.Echo "Start"
Set oExec = oWSH.Exec ("ftp.exe")
'Set oExec = oWSH.Exec ("%COMSPEC% /c %WINDIR%\System32\ftp.exe")
'Set oExec = oWSH.Exec ("test.cmd")
Set oStdout = oExec.StdOut
Set oStdin = oExec.StdIn
WScript.Echo "Started"

' Work until FTP.EXE works
Do While oExec.Status = 0
WScript.Echo "Debug . :" & "Do a check ..."
WScript.Echo "Debug 0 :" & oExec.Status
'WScript.Echo "Debug 1a:" & oStdout.Read (1)
WScript.Echo "Debug 1b:" & oStdout.AtEndOfStream
WScript.Echo "Debug 2 :" & oExec.StdErr.AtEndOfStream
WScript.Echo "Debug 3 :" & oStdin.AtEndOfStream
WScript.Echo "Debug 4 :" & "done"

' Some olgic is skipped

WScript.Echo "Debug 5 :" & "Waiting"
WScript.Sleep 500

provides the following output:
Debug . :Do a check ...
Debug 0 :0

and waiting forever then.

Do you have any suggestions, what could be a problem with FTP.EXE when
ran through .exec ?

The same [mis]behavior is noted on Windows XP SP2, and on Windows 2000
Server with latest SP.


vbscript does .exec("ftp"), then hangs while accessing stdout and stderr

Post by learne » Fri, 30 Sep 2005 05:02:28

ake a look here: and try to use the -s option
(be sure to have quit as last line in your ftp cmd file)
C:\>ftp -help

Transfers files to and from a computer running an FTP server service
(sometimes called a daemon). Ftp can be used interactively.

FTP [-v] [-d] [-i] [-n] [-g] [-s:filename] [-a] [-w:windowsize] [-A] [host]

-v Suppresses display of remote server responses.
-n Suppresses auto-login upon initial connection.
-i Turns off interactive prompting during multiple file
-d Enables debugging.
-g Disables filename globbing (see GLOB command).
-s:filename Specifies a text file containing FTP commands; the
commands will automatically run after FTP starts.
-a Use any local interface when binding data connection.
-A login as anonymous.
-w:buffersize Overrides the default transfer buffer size of 4096.
host Specifies the host name or IP address of the remote
host to connect to.

- mget and mput commands take y/n/q for yes/no/quit.
- Use Control-C to abort commands.

I would do run the ftp from script with syntax like this in your run cmd
ftp -s:inpCmd > sometempoutFile
then parse the sometempoutFile and generate another inputCmd file to run
ftp, and so on
"MLevin" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...


vbscript does .exec("ftp"), then hangs while accessing stdout and stderr

Post by MLevi » Fri, 30 Sep 2005 05:16:52


I know the trick with the pre-generated command file. And it is how I
currently do things.

By my whole idea was to run the ftp.exe only once, and to pass the
commands into it right from the script. Without any commands file,
without any results file. Just read what ftp sends to output and write
commands to its' input.

Say, if you replace ftp.exe with cmd.exe, the sample script works! That
is the whole problem -- ftp.exe is behaving quite not how all other
stdin/stdout related terminal applications.