Re: Shell to Command
From: Rick Rothstein (rickNOSPAMnews_at_NOSPAMcomcast.net)
Date: 10/25/04
- Next message: Jean: "Re: Shell to Command"
- Previous message: news.microsoft.com: "cancel form and variables in data environment"
- In reply to: Jean: "Shell to Command"
- Next in thread: Jean: "Re: Shell to Command"
- Reply: Jean: "Re: Shell to Command"
- Reply: Jean: "Re: Shell to Command"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 25 Oct 2004 10:19:02 -0400
> I have a VB6 program that shells to the dos prompt then opens an ftp
session
> to an IP address (obtained from a text file) and reads ftp commands
from
> another text file. The ftp session transfers a file from the remote
device to
> the local pc. The output is then redirected to another text file which
will
> be searched to determine the results of the file transfer. Below is a
portion
> of my code:
>
> dReturn = Shell(Environ("ComSpec") & " /c ftp "ftp -i -s:" & <input
file> &
> " " & <IP address> & " > " & <output file>, vbHide)
>
> I am developing this program on Win2000. For some reason the shell
function
> requires short path names for the location of the ftp command input
file and
> the redirected output file. Any idea why it requires short pathnames?
If I
> manually start a dos session and type in the command line ftp, it will
work
> with long path names. Am I missing something in the shell function?
>
> This program will be used on Win98, WinNt 4.0, Win2000, and WinXP.
Does the
> Shell function work differently on each OS?
The following is a compilation of several posts I've given in the past
regarding the Shell command. Your question is addressed in the part
where I discuss encasing filenames in quotemarks; the remainder is for
your consideration.
Rick -MVP
You can use the Shell command. To execute internal DOS command (Dir,
Copy, etc. as well as redirection of screen output), the command
processor must be specified (using the Environ$ function and "comspec"
as its argument returns the correct command processor path on NT and
non-NT systems) . Specifying the command processor is safe & generic and
will work with non-internal commands also. That syntax, using an XCopy
command as an example is:
Shell Environ$("comspec") & " /c xcopy """ & _
Source & """ """ & Destination & """ " & Option, vbHide
You set the Source and Desination (string variables) to the appropriate
paths and the Option (string variable), if any, which can be found by
opening an MSDOS Prompt window and typing xcopy /?. (Note: You can type
/? after any DOS command at a DOS prompt to list the available options
for that command.) One more example would be to list all the files in a
directory including subdirectories and subdirectories of subdirectories
and all of their files.
CommandLine = "dir """ & FileSpec & _
""" /s/b > """ & RedirectTo & """"
Shell Environ$("comspec") & " /c " & CommandLine, vbHide
Here, the output of a Dir command is redirected to a file-path you
specify in the RedirectTo (string variable). The /s/b are options to the
Dir command that tell it to recurse throught its subdirectories and not
to include header or summary information.
I used a variable for the file name so that I could more easily explain
the benefit of encasing it in quotemarks. If you redirect to a file that
has spaces in its name, or if there are spaces in the path specification
itself, then the filename *must* be quoted to protect the spaces from
DOS's desire to use them as delimiters. (That's what all those
quotemarks in the Shell statement are for.) If the filename doesn't have
spaces in it, the quotes aren't necessary BUT they don't hurt either.
Hence, the above will work with either.
As for your PING question, something like the following should work:
strIP = "4.17.23.1"
Shell Environ$("comspec") & " /c ping " & _
strIP & " > """ & RedirectFile & """", vbHide
Although you didn't specify it in your original post, I assume you want
to use vbHide for the optional 2nd parameter to Shell. This hides the
DOS window so that your user doesn't see it. If you want the DOS window
to remain visible, you would use the vbNormalFocus BUT you must use a /k
instead of a /c for the command processor argument. Basically, the /c
tells the command processor "here comes a command and, when its finished
executing, close the DOS shell it is running in" whereas the /k also
tells the command processor that a command follows, but it instructs it
to leave the DOS session running.
The above assumes you do NOT have to wait for this file to be completely
written before your code continues executing. If you have to work with
this file right after it is created, consider one of these (which makes
your program wait until the DOS process is finished):
MICROSOFT 'S OFFICIAL WAY
========================
See this link
http://support.microsoft.com/support/kb/articles/Q129/7/96.asp
Note: This method doesn't use Shell -- it uses CreateProcessA.
FAST AND DIRTY METHOD (WORKS ALMOST ALL THE TIME)
=================================================
Paste these lines in the (General)(Declarations) section of the form
where the Shell is being called (or remove the Private keywords and put
them in a BAS module if more than one form will use them):
Private Declare Function OpenProcess _
Lib "kernel32" _
(ByVal dwDesiredAccess As Long, _
ByVal bInheritHandle As Long, _
ByVal dwProcessId As Long) As Long
Private Declare Function CloseHandle _
Lib "kernel32" _
(ByVal hObject As Long) As Long
Private Declare Function WaitForSingleObject _
Lib "kernel32" _
(ByVal hHandle As Long, _
ByVal dwMilliseconds As Long) As Long
Call your Shell command in this form with the appropriate Shell
arguments placed in the parentheses:
PID = Shell( <<Put Shell Arguments Here>> )
And finally, paste the following IMMEDIATELY after the PID=Shell
statement above (making sure to handle the possible error where
indicated; i.e. stop the code from falling through to your other
commands if the Shell failed):
If PID = 0 Then
'
'Handle Error, Shell Didn't Work
'
Else
hProcess = OpenProcess(&H100000, True, PID)
WaitForSingleObject hProcess, -1
CloseHandle hProcess
End If
- Next message: Jean: "Re: Shell to Command"
- Previous message: news.microsoft.com: "cancel form and variables in data environment"
- In reply to: Jean: "Shell to Command"
- Next in thread: Jean: "Re: Shell to Command"
- Reply: Jean: "Re: Shell to Command"
- Reply: Jean: "Re: Shell to Command"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|