Shell to Batch
sara li
bat file. But the bat file refuses to execute START or CALL commands.
I get the message "Bad Command or Filename."
The bat file works fine directly from the command prompt but not when
shelled. I am working around the problem by stuffing the keyboard with
the bat file name and a CHR$(13). This launches the bat file when the
program ends and it all works correctly but I really need to use shell,
instead. Any ideas?
Michael Mattias
news:hjiok.25503$1p1....@en-nntp-08.dc1.easynews.com...
You are either....
A. In the wrong directory when you issue the SHELL and are SHELLing an
unqualified or only partially-qualified filename
B. Trying to SHELL a file with spaces in the name.
C. SHELLing 'batfilename' intead of "CMD /[C|K] batfilename" (I never
could figure out when CMD is required, but I know sometimes it is).
Identify and correct.
--
Michael C. Mattias
Tal Systems Inc.
Racine WI
mmat...@talsystems.com
sara li
Here's the XYZ.BAT file:
@ECHO OFF
START C:\Progra~1\YCIII\YankClip.exe
START C:\Progra~1\WordWeb\wweb32.exe
START C:\Progra~1\TrayWi~1\TWizard.exe
CD C:\JAY\ADVANT
C:\JAY\ADVANT\CLEANUP.EXE
When I run it from the command prompt evertyhing works perfectly.
When I run it as a SHELL it produces "Bad Command or File Name" for all
the START lines.
I'm using the following Syntax in QB45:
BAT$="XYZ.BAT"
SHELL BAT$
At your suggestion I have also tried BAT$="CMD /C XYZ.BAT" and BAT$="CMD
/K XYZ.BAT" but neither solves the problem or even complicates it.
There are no syntax or path errors that I can see. The batch works
perfectly at the command prompt or by stuffing the keyboard with the bat
file name plus a CHR$(13) so that it will execute when the EXE
terminates. It just won't work with SHELL and adding CMD /C/K is not
solving it, either.
Here's another conundrum that has bothered me for many years and is
probably similar. I use a lot of BAT files and one of them is E.BAT
which simply executes the DOS command EXIT. But when QB45 is running
and I'm in the QB45 "DOS Shell" the E.BAT doesn't work. In fact, no BAT
files work in the QB45 "DOS Shell" environment.
Thanks for your help...
Todd Vargo
What is your OS and are you using CMD.EXE from that OS?
In Win9x/ME, START is an external command. To access it, START must be
available in your PATH (or the fully qualified filename must be used).
However, Win9x/ME uses COMMAND.COM not CMD.EXE. If you are using one of
these OSes, compare the output from PATH outside of QB45, then use SHELL
"PATH" to confirm the path is not different when QB45 is loaded.
In WinNT/2K/XP, START is an internal command so PATH should not be an issue
but if you are using a replacement command processor that does not have a
START command that could explain the problem.
--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)
sara li
You're right, Todd, the problem is the command processor. I'm using
Windows XP with 4NT as the command processor. I like 4NT for commands
like XCOPY but 4NT doesn't handle START when shelled and they don't have
a CMD or COMMAND prefix option. I can get around this by using CMD but
doing that runs XP's CMD.exe and that doesn't recognize 4NT's XCOPY
syntax.
To solve this I'll create two bat files. The one with XCOPY's will be
processed by 4NT and the second one will shell out with the CMD prefix
to force XP's CMD.exe to handle the START commands.
Thanks to you and Michael for your help in solving this mystery!
Michael Bednarek
microsoft.public.basic.dos:
In which version of 4NT is "XCOPY" an internal command? Not in mine
(6.01).
The following code executes just fine here (Win-5.1) in MS-QBasic 1.1
and in GW-BASIC Rev. 1.02:
BAT$ = "C:\PROGRA~1\4NT6\4NT.EXE /C C:\TEMP\XYZ.BAT"
SHELL BAT$
where XYZ.BAT is
Start notepad.exe
Start calc.exe
--
Michael Bednarek http://mbednarek.com/ "POST NO BILLS"
Michael Mattias
>
> To solve this I'll create two bat files. The one with XCOPY's will be
> processed by 4NT and the second one will shell out with the CMD prefix to
> force XP's CMD.exe to handle the START commands.
>
> Thanks to you and Michael for your help in solving this mystery!
?????
Why even bother messing around with BAT files and command processors???..
>>> Here's the XYZ.BAT file:
>>> @ECHO OFF
>>> START C:\Progra~1\YCIII\YankClip.exe
>>> START C:\Progra~1\WordWeb\wweb32.exe
>>> START C:\Progra~1\TrayWi~1\TWizard.exe
>>> CD C:\JAY\ADVANT
>>> C:\JAY\ADVANT\CLEANUP.EXE
Just SHELL these programs from your program (using CHDIR when necessary) !
And I have to believe instead of XCOPY you could write a QB45 procedure to
do whatever you are doing. (At the very least you SHOULD be able to do
that).
End of BAT/CMD issues! Regardless of operating system!!!
Just because you are using a 20th-century development product doesn't mean
you should program that way.
(Yes I know, old habits die hard).
sara li
That sounds like a nice solution but the problem ultimately returns to
long file names. The QB45 LIB routines from ProBas and Crescent for
finding files and file dates don't handle long file names. And using
the ~1 suffix abbreviation is useless if there is more than one file
with the same 6 characters. There are some nascent longfile name
routines kicking around but they are bulky, incomplete or difficult to
follow.
Michael Mattias
HUH?
If you can type the short file names into the batch file, you can sure as
heck type the short file names into your program code, or into a file used
by your program code!!!
eg instead of hard coding the program name put em in a file:
C:\Progra~1\YCIII\YankClip.exe
C:\Progra~1\WordWeb\wweb32.exe
C:\Progra~1\TrayWi~1\TWizard.exe
C:\JAY\ADVANT\CLEANUP.EXE
OPEN "progname.txt" for input as #33
WHILE NOT EOF(33)
LINE INPUT #33, p$
SHELL p$
WEND
CLOSE #33
MCM
Todd Vargo
Reading input is well and good but writing output to an 8.3 name in QB will
remove the LFN. If working with LFNs is of great concern or too bothersome
to work around, I suggest OP move to an LFN aware programming language.
Michael Mattias
news:ukOpi%23k$IHA...@TK2MSFTNGP06.phx.gbl...
> Reading input is well and good but writing output to an 8.3 name in QB
> will
> remove the LFN. If working with LFNs is of great concern or too bothersome
> to work around, I suggest OP move to an LFN aware programming language.
When you deal with QB45, you are dealing with short names anyway. Period.
Besides, you can SHELL a longname just fine, as long as you delimit any
filenames containing spaces with quotes.
I was primarily trying to point out that SHELLing a batch file to execute a
couple of programs is just inserting another layer of code where things can
go wrong.
For that matter, you seldom if ever *need* a batch/command file to do
anything, as QB contains just about every function you could want, and when
it doesn't you can do that thing where you call DOS or BIOS interrupts
directly from QB. (Yes, I have forgetten the name of QB's equivalent to
PowerBASIC's "CALL INTERRUPT")
MCM
ArarghMai...@not.at.arargh.com
<mmat...@talsystems.com> wrote:
<snip>
>For that matter, you seldom if ever *need* a batch/command file to do
>anything, as QB contains just about every function you could want, and when
>it doesn't you can do that thing where you call DOS or BIOS interrupts
>directly from QB. (Yes, I have forgetten the name of QB's equivalent to
>PowerBASIC's "CALL INTERRUPT")
>
From qb45 help:
CALL INTERRUPT - a statement that allows BASIC programs to perform
DOS system calls
Syntax
CALL INTERRUPT(interruptnum,inregs,outregs)
CALL INTERRUPTX(interruptnum,inregs,outregs)
_ interruptnum, an integer expression which has a value between
0 and 255, is a DOS interrupt number
_ inregs contains the register values before the interrupt is
performed
(see Details for how to declare a user-defined type which will
contain these register values)
_ outregs contains the register values after the interrupt
Also, from somewhere I once got a file called "longname.exe" sized
52,675 bytes which contains asm routines to access some of DOS 7s
interrupt based long file name routines.
--
ArarghMail808 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the extra stuff from the reply address.
Sjouke Burry
and then do a system call with the string
"ren dummy.fun ""extremely long and silly filename.putty"""??
ArarghMai...@not.at.arargh.com
<burrynu...@ppllaanneett.nnlll> wrote:
<snip>
>Whats the problem with writing to dummy.fun
>and then do a system call with the string
>"ren dummy.fun ""extremely long and silly filename.putty"""??
Well, mainly that for QB45 it should be:
shell "ren dummy.fun " + chr$(34) + "extremely long and silly
filename.putty" + chr$(34)
assuming I got all the quotes correct, all on one line.
MS 16-bit basics don't know about "" inside a string.
Todd Vargo
<ArarghMai...@NOT.AT.Arargh.com> wrote in message
news:l8e9a451dgcvi1q3d...@4ax.com...
> On Fri, 15 Aug 2008 00:06:06 +0200, Sjouke Burry
> <burrynu...@ppllaanneett.nnlll> wrote:
>
> <snip>
>
> >Whats the problem with writing to dummy.fun
> >and then do a system call with the string
> >"ren dummy.fun ""extremely long and silly filename.putty"""??
> Well, mainly that for QB45 it should be:
>
> shell "ren dummy.fun " + chr$(34) + "extremely long and silly
> filename.putty" + chr$(34)
>
> assuming I got all the quotes correct, all on one line.
>
> MS 16-bit basics don't know about "" inside a string.
Right, but to answer the "dumb" question, nothing is wrong with shelling to
rename, unless the OP considers that method one of the "nascent longfile
name routines kicking around but they are bulky, incomplete or difficult to
follow."
Please don't preach to the choir fellow enthusiasts.