Re: Shell to Command
From: Jean (Jean_at_NoSpam.com)
Date: 10/25/04
- Next message: Jean: "Re: Shell to Command"
- Previous message: Rick Rothstein: "Re: Shell to Command"
- In reply to: Rick Rothstein: "Re: Shell to Command"
- Next in thread: Peter Huang: "Re: Shell to Command"
- Reply: Peter Huang: "Re: Shell to Command"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 25 Oct 2004 07:41:05 -0700
I currently enclose the path in quotes but that doesn't correct the problem.
The problem seems to be that the folder names are too long. If I first use
the ShortPath property when initializing the pathname variable, everything
works fine.
Here is the actual code I am using:
sAppPath = App.Path
sOutputName = "\Temp\ftpLog.txt"
sInputName = "\OCB.ftp"
sCom = Environ("ComSpec") 'get ComSpec environment variable
sIP = GetDeviceIP(sAppPath) 'get device IP from config file
Set fs = CreateObject("Scripting.FileSystemObject")
Set fldr = fs.GetFolder(sAppPath)
sShortPath = fldr.ShortPath
sCmdLine = "ftp -i -s:""" & sShortPath & sInputName & """ " & sIP &
" > """ & sShortPath & sOutputName & """"
dReturn = Shell(sCom & " /c " & sCmdLine, vbHide)
"Rick Rothstein" wrote:
> > 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: Rick Rothstein: "Re: Shell to Command"
- In reply to: Rick Rothstein: "Re: Shell to Command"
- Next in thread: Peter Huang: "Re: Shell to Command"
- Reply: Peter Huang: "Re: Shell to Command"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
