wScript.Shell Problems

I am in the process of building a script to FTP files to another
location. What i am curious to know is how can i dump what is being
sent displayed in the comand window to a text file. Here is my code.
And you will see that i am not getting anywhere.

The two variables being sent to the Function just contain FTP Commands
and the OutputFileName such as
strCMD = "PUT test.txt rmdirectory/test.txt" & vbCrLf
oFile = "C:\output.txt"

Function FTP( strCMD, oFile )
Dim objFSO
Dim strFile, objTempFldr, objFile, objRegExp
Dim objShell, WSX, ReturnCode, Output, strLog, strErrorLog
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set oFileFSO = objFSO.OpenTextFile(oFile,2,True)
set objTempFldr = objFSO.GetSpecialFolder( 2 )
strFile = objFSO.GetTempName
strFile = objTempFldr & "\" & left(strFile,Len(strFile)-4) & ".ftp"

if not objFSO.FileExists( strFile ) then objFSO.CreateTextFile(
strFile )
Set objFile = objFSO.OpenTextFile( strFile, 2, True )

objFile.WriteLine( strUser )
objFile.WriteLine( strPass )
objFile.WriteLine( Mode )

objFile.WriteLine( strCMD )
objFile.WriteLine( "bye" )
objFile.Close()


Set objShell = WScript.CreateObject("WScript.Shell")

objShell.Run "cmd /c " & COMMAND_FTP & strFile & " " & strHost,1,TRUE
set objFSO = nothing
End If

Nico
Tue Jul 11 20:13:07 CDT 2006

Guess i should give you all the code. Thanks in advance
'//Start FTP-Files.vbs
Const COMMAND_FTP = "ftp.exe -i -s:"
CONST strHost = "localHose" 'Host Server
CONST strUser = "ftpUsername" 'User Name
CONST strPass = "ftpUserPass" 'Password
CONST strMode = "ascii" 'Mode (ascii/binary)

FTP("DIR")

Function FTP( strCMD, oFile )
Dim objFSO
Dim strFile, objTempFldr, objFile, objRegExp
Dim objShell, WSX, ReturnCode, Output, strLog, strErrorLog
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set oFileFSO = objFSO.OpenTextFile(oFile,2,True)
set objTempFldr = objFSO.GetSpecialFolder( 2 )
strFile = objFSO.GetTempName
strFile = objTempFldr & "\" & left(strFile,Len(strFile)-4) & ".ftp"

if not objFSO.FileExists( strFile ) then objFSO.CreateTextFile(
strFile )
Set objFile = objFSO.OpenTextFile( strFile, 2, True )

objFile.WriteLine( strUser )
objFile.WriteLine( strPass )
objFile.WriteLine( Mode )

objFile.WriteLine( strCMD )
objFile.WriteLine( "bye" )
objFile.Close()


Set objShell = WScript.CreateObject("WScript.Shell")

SET WSX = objShell.Run "cmd /c " & COMMAND_FTP & strFile & " " &
strHost,1,TRUE
strErrorLog = objTempFldr.Path & "ftpErrors.txt"
strLog = objTempFldr.Path & "ftpLog.txt"

Set objFile = objFSO.OpenTextFile( strErrorLog, 2, True )
objFile.Write( ReturnCode.ReadAll() )
objFile.Close()

Set objFile = objFSO.OpenTextFile( strLog, 2, True )
objFile.Write( Output.ReadAll() )
objFile.Close()

set objFSO = nothing

Set objRegExp = New RegExp
objRegExp.IgnoreCase = True

objRegExp.Pattern = "not connected|invalid command|error"
If (objRegExp.Test( Output.ReadAll ) = True ) or (objRegExp.Test(
ReturnCode.ReadAll ) ) Then
FTP = False
Else
FTP = True
End If
Set objRegExp = nothing
End Function
'//End

joseomjr
Tue Jul 11 20:25:56 CDT 2006

You could get what is being displayed in the cmd window by adding
something like:
>> c:\output.txt to the end of your objshell.run
objshell.run yourcommands >> c:\output.txt, 1, true

try this in a cmd prompt.
ipconfig >> c:\output.txt

you'll see the output is sent to that text file directly.

the other way would be to use the exec method and retrieve the
information. an example from the Microsoft site:
Set objShell = CreateObject("WScript.Shell")
Set objWshScriptExec = objShell.Exec("ipconfig /all") 'your command
would go here
Set objStdOut = objWshScriptExec.StdOut

While Not objStdOut.AtEndOfStream
strLine = objStdOut.ReadLine
If InStr(strLine,"Physical Address") Then
WScript.Echo strLine
End If
Wend

If you ask me, the first method would be the quickest an easiest.

Nico VanHaaster wrote:
> Guess i should give you all the code. Thanks in advance
> '//Start FTP-Files.vbs
> Const COMMAND_FTP = "ftp.exe -i -s:"
> CONST strHost = "localHose" 'Host Server
> CONST strUser = "ftpUsername" 'User Name
> CONST strPass = "ftpUserPass" 'Password
> CONST strMode = "ascii" 'Mode (ascii/binary)
>
> FTP("DIR")
>
> Function FTP( strCMD, oFile )
> Dim objFSO
> Dim strFile, objTempFldr, objFile, objRegExp
> Dim objShell, WSX, ReturnCode, Output, strLog, strErrorLog
> Set objFSO = CreateObject("Scripting.FileSystemObject")
> Set oFileFSO = objFSO.OpenTextFile(oFile,2,True)
> set objTempFldr = objFSO.GetSpecialFolder( 2 )
> strFile = objFSO.GetTempName
> strFile = objTempFldr & "\" & left(strFile,Len(strFile)-4) & ".ftp"
>
> if not objFSO.FileExists( strFile ) then objFSO.CreateTextFile(
> strFile )
> Set objFile = objFSO.OpenTextFile( strFile, 2, True )
>
> objFile.WriteLine( strUser )
> objFile.WriteLine( strPass )
> objFile.WriteLine( Mode )
>
> objFile.WriteLine( strCMD )
> objFile.WriteLine( "bye" )
> objFile.Close()
>
>
> Set objShell = WScript.CreateObject("WScript.Shell")
>
> SET WSX = objShell.Run "cmd /c " & COMMAND_FTP & strFile & " " &
> strHost,1,TRUE
> strErrorLog = objTempFldr.Path & "ftpErrors.txt"
> strLog = objTempFldr.Path & "ftpLog.txt"
>
> Set objFile = objFSO.OpenTextFile( strErrorLog, 2, True )
> objFile.Write( ReturnCode.ReadAll() )
> objFile.Close()
>
> Set objFile = objFSO.OpenTextFile( strLog, 2, True )
> objFile.Write( Output.ReadAll() )
> objFile.Close()
>
> set objFSO = nothing
>
> Set objRegExp = New RegExp
> objRegExp.IgnoreCase = True
>
> objRegExp.Pattern = "not connected|invalid command|error"
> If (objRegExp.Test( Output.ReadAll ) = True ) or (objRegExp.Test(
> ReturnCode.ReadAll ) ) Then
> FTP = False
> Else
> FTP = True
> End If
> Set objRegExp = nothing
> End Function
> '//End

Tom
Wed Jul 12 07:30:36 CDT 2006

Unfortunately, your first approach to redirecting the output implies a
flaw. Redirection is not supported by the mechanisim that the Run
method invokes. It is only supported by the command processor (best
invoked with the COMSPEC environment variable). Therefore, unless the
string provided by the variable "yourcommand" starts with a reference
to the command processor, the subsequent Run statement will fail.

There is also a potential pitfall in the second approach as well. I
don't think it applies here, but it has often caused heartburn for
those trying to automate a certain console based zip archiving program.
Specifically, both text buffers associated with the StdOut and the
StdErr property can become full, thereby blocking proper execution of
the program invoked by the Exec procedure. Therefore, I caution that
it is a good practice to implement processing of both the StdOut and
StdErr interfaces to the Exec method. Failing to empty the StdErr
buffer has tripped up more than a few hapless scripters. (There is
also the annoyance of the command console window that is instaniated by
the Exec statement, though this can be avoided with a fancy recursive
call. Torgeir Bakken (MVP) showed me that trick a long time ago - see:
http://groups.google.com/group/microsoft.public.scripting.wsh/browse_frm/thread/eb38318877ec3fec)

Tom Lavedas
=============
http://members.cox.net/tglbatch/wsh

joseomjr@gmail.com wrote:
> You could get what is being displayed in the cmd window by adding
> something like:
> >> c:\output.txt to the end of your objshell.run
> objshell.run yourcommands >> c:\output.txt, 1, true
>
> try this in a cmd prompt.
> ipconfig >> c:\output.txt
>
> you'll see the output is sent to that text file directly.
>
> the other way would be to use the exec method and retrieve the
> information. an example from the Microsoft site:
> Set objShell = CreateObject("WScript.Shell")
> Set objWshScriptExec = objShell.Exec("ipconfig /all") 'your command
> would go here
> Set objStdOut = objWshScriptExec.StdOut
>
> While Not objStdOut.AtEndOfStream
> strLine = objStdOut.ReadLine
> If InStr(strLine,"Physical Address") Then
> WScript.Echo strLine
> End If
> Wend
>
> If you ask me, the first method would be the quickest an easiest.
>
> Nico VanHaaster wrote:
> > Guess i should give you all the code. Thanks in advance
> > '//Start FTP-Files.vbs
> > Const COMMAND_FTP = "ftp.exe -i -s:"
> > CONST strHost = "localHose" 'Host Server
> > CONST strUser = "ftpUsername" 'User Name
> > CONST strPass = "ftpUserPass" 'Password
> > CONST strMode = "ascii" 'Mode (ascii/binary)
> >
> > FTP("DIR")
> >
> > Function FTP( strCMD, oFile )
> > Dim objFSO
> > Dim strFile, objTempFldr, objFile, objRegExp
> > Dim objShell, WSX, ReturnCode, Output, strLog, strErrorLog
> > Set objFSO = CreateObject("Scripting.FileSystemObject")
> > Set oFileFSO = objFSO.OpenTextFile(oFile,2,True)
> > set objTempFldr = objFSO.GetSpecialFolder( 2 )
> > strFile = objFSO.GetTempName
> > strFile = objTempFldr & "\" & left(strFile,Len(strFile)-4) & ".ftp"
> >
> > if not objFSO.FileExists( strFile ) then objFSO.CreateTextFile(
> > strFile )
> > Set objFile = objFSO.OpenTextFile( strFile, 2, True )
> >
> > objFile.WriteLine( strUser )
> > objFile.WriteLine( strPass )
> > objFile.WriteLine( Mode )
> >
> > objFile.WriteLine( strCMD )
> > objFile.WriteLine( "bye" )
> > objFile.Close()
> >
> >
> > Set objShell = WScript.CreateObject("WScript.Shell")
> >
> > SET WSX = objShell.Run "cmd /c " & COMMAND_FTP & strFile & " " &
> > strHost,1,TRUE
> > strErrorLog = objTempFldr.Path & "ftpErrors.txt"
> > strLog = objTempFldr.Path & "ftpLog.txt"
> >
> > Set objFile = objFSO.OpenTextFile( strErrorLog, 2, True )
> > objFile.Write( ReturnCode.ReadAll() )
> > objFile.Close()
> >
> > Set objFile = objFSO.OpenTextFile( strLog, 2, True )
> > objFile.Write( Output.ReadAll() )
> > objFile.Close()
> >
> > set objFSO = nothing
> >
> > Set objRegExp = New RegExp
> > objRegExp.IgnoreCase = True
> >
> > objRegExp.Pattern = "not connected|invalid command|error"
> > If (objRegExp.Test( Output.ReadAll ) = True ) or (objRegExp.Test(
> > ReturnCode.ReadAll ) ) Then
> > FTP = False
> > Else
> > FTP = True
> > End If
> > Set objRegExp = nothing
> > End Function
> > '//End

Nico
Wed Jul 12 12:13:35 CDT 2006

I would agree with your statements and using the EXEC command has
worked well for me in the past to upload single files and I could
utilize the stdOut & stdErr commands.

Here is why i went to the RUN command, it is my understanding that the
EXEC command does not allow for the BOOLEAN indicating wether the
script should wait for the current command to be finished before moving
to the next line of the script.

I have considered creating a wscript.sleep command that sleeps for a
calculated time based on the file size.

Csaba
Wed Jul 12 13:50:22 CDT 2006

Tom Lavedas wrote:
> Unfortunately, your first approach to redirecting the output implies a
> flaw. Redirection is not supported by the mechanisim that the Run
> method invokes. It is only supported by the command processor (best
> invoked with the COMSPEC environment variable). Therefore, unless the
> string provided by the variable "yourcommand" starts with a reference
> to the command processor, the subsequent Run statement will fail.
>
> There is also a potential pitfall in the second approach as well. I
> don't think it applies here, but it has often caused heartburn for
> those trying to automate a certain console based zip archiving program.
> Specifically, both text buffers associated with the StdOut and the
> StdErr property can become full, thereby blocking proper execution of
> the program invoked by the Exec procedure. Therefore, I caution that
> it is a good practice to implement processing of both the StdOut and
> StdErr interfaces to the Exec method. Failing to empty the StdErr
> buffer has tripped up more than a few hapless scripters. (There is
> also the annoyance of the command console window that is instaniated by
> the Exec statement, though this can be avoided with a fancy recursive
> call. Torgeir Bakken (MVP) showed me that trick a long time ago - see:
> http://groups.google.com/group/microsoft.public.scripting.wsh/browse_frm/thread/eb38318877ec3fec)

And for some historical perspective on it, see
http://groups.google.com/group/microsoft.public.scripting.vbscript/browse_frm/thread/54d3df2e29211bad/

Csaba Gabor from New York

Tom
Wed Jul 12 20:55:58 CDT 2006

You are right that Exec does not have a boolean to cause it to wait for
the completion of the underlying process. Rather, it provides a Status
property which can be interrogated in a wait loop to determine whether
the process is still running. I say it is more versatile in that it
will allow coding of a watchdog to terminate the underlying process,
should the need arise. Not needed all the time, but it can come in
handy some times.

Having said that, I generally use the Run method with redirection when
I want access to the full output of a console process for subsequent
data extraction or error detection. However, the Exec procedure is
much better at automating a console process that may need its hand held
as it operates - say for input or to branch depending on a response or
error. I have played with automating the ftp client this way, though
I've never been completely successful with it. I stopped tinkering. A
static control script is generally sufficient and I don't do anything
with ftp that can't be done pretty easily with a one-off set of
keystrokes or via XPs instrumentation of ftp access in explorer.

Be warned however, that even console programs sometimes slip the bonds
of the Run waiting for its termination. They do this by launching a
new thread (disconnected child process) and closing the original one
that the Run executed. Your bWaitonReturn is satisfied, but the actual
guts of the procedure you launched is still churning away. Install
programs used to be notorious for this. I don't play with them much
and haven't followed this group too closely lately, so I don't know if
that's still true.

Tom Lavedas

Nico VanHaaster wrote:
> I would agree with your statements and using the EXEC command has
> worked well for me in the past to upload single files and I could
> utilize the stdOut & stdErr commands.
>
> Here is why i went to the RUN command, it is my understanding that the
> EXEC command does not allow for the BOOLEAN indicating wether the
> script should wait for the current command to be finished before moving
> to the next line of the script.
>
> I have considered creating a wscript.sleep command that sleeps for a
> calculated time based on the file size.