Shell() or Windows API question

[gxdata]

I have a DOS or command console program that was written in FORTRAN, and
accepts piped input when run from Windows 2000 Pro command prompt (or
Windows 98 DOS prompt) -

INVERSE.EXE < INPUT.TXT
Running the above from DOS / command prompt works perfectly.

Also, this works from an Access XP code module -
RetVal = Shell("O:\Vincenty\inverse.exe", 1)
giving just the console interface and requiring manual input; but I need to
pipe in the values stored in a file INPUT.TXT (or - better - pass a string
direct from a routine written in Access Visual Basic).

I can't discover a way to achieve what I want from an Access subroutine. I
have tried Shell() with both direct and with various batch files -
RetVal = Shell("O:\Vincenty\inverse.exe < 1.TXT", 1)
or
RetVal = Shell("O:\Vincenty\inverse.exe < 1.TXT", 1)
and
RetVal = Shell("MyBatchFile1.BAT < INPUT.TXT", 1)
or
RetVal = Shell("MyBatchFile2.BAT", 1)

where the batch files are 1 - inverse.exe < %1 and 2 - inverse.exe <
INPUT.TXT

Everything run with Shell() from Access fails, when redirection (piped
inout) is specifdied - either directly or through a batch file. Note that
both of the batch files described above do work perfectly when run manually
from the DOS (command) prompt.

I think I need some Windows API functions, and fairly elaborate ones. I
would appreciate suggestions.

Ian Thomas
Perth, Australia

 

[RK]

Shell() cmd "my.bat" /c

 

[TC]

You don't want the redirection operator in the first line below: it's
already in the batch file:

RetVal = Shell("MyBatchFile1.BAT < INPUT.TXT", 1)
or
RetVal = Shell("MyBatchFile2.BAT", 1)
where the batch files are 1 - inverse.exe < %1
and 2 - inverse.exe < INPUT.TXT

I'm surprised that batchfile 2 doesn't work. Why should Shell() care what
the batch file does?

Are you providing the full pathname of the file in question? INPUT.TXT
doesn't look much. Try C:\MyFolder\INPUT.TXT or whatever.

What do you mean when you say that it "fails"? What is the actual error
you're getting?

HTH,
TC

 

[gxdata]

Thanks, TC -
The batch files are appropriate to the command strings used in the Shell().
Failure means I don't get a (black window) command console process in which
inverse.exe is running. The one case where it does work, is where there is
no redirection (either explicitly within the string within Shell(), or
within a batch file). It's the first shell() I described.
One possibility: I suspect inverse.exe is 16-bit - it's FORTAN-compiled, not
one of mine. Would this matter? I think not.

I haven't tried the suggestion by RK yet, but will do so soon.

ILT

 

[gxdata]

retval = Shell("CMD ""O:\Vincenty\B2.bat"" /C",1) - also fails to work

B2.BAT contains - inverse.exe < INPUT.TXT
and the files INVERSE.EXE and INPUT.TXT do exist in O:\Vincenty

ILT

 

[TC]

Thanks, TC -

The batch files are appropriate to the command strings used in the

Shell().

Not according to what you have shown!
You have shown this batchfile:
inverse.exe < %1
being called with this command:
MyBatchFile1.BAT < INPUT.TXT
It should be this command:

MyBatchFile1.BAT INPUT.TXT

Failure means I don't get a (black window) command console process in which
inverse.exe is running.

So there is no error from the Shell() command - it just fails silently? I
guess that means that it successfully started the command, and neither knows
nor cares what happened afterwards - eg. problems with the redirection.

The one case where it does work, is where there is
no redirection (either explicitly within the string within Shell(), or
within a batch file). It's the first shell() I described.

One possibility: I suspect inverse.exe is 16-bit - it's FORTAN-compiled, not
one of mine. Would this matter? I think not.

I don't know.

I haven't tried the suggestion by RK yet, but will do so soon.

Post back with result!

Cheers,
TC
(off for the day)

 

[gxdata]

Yes, you're right, TC.
I have now removed the superfluous < (first batch file has %1), but no
improvement.
The return value from Shell() was non-zero so the executable (inverse.exe)
is being run, I guess.
The command window doesn't remain, though - which means it's crashing. Doing
something like
inverse < nonexist.txt
at cmd prompt will give a termination with error ("The system cannot find
the file specified.")
I've tried it fully-pathed for the parameter file but still no success.

Thanks anyway.

ILT

 

[TC]

My last idea. Are you sure that the Access VBA Shell() statement can
successfully call >any< console-mode program? Pick some other console-mode
program that you know works, requires no parameters or piped input, &
displays a console window. If >that< doesn't work, perhaps VBA Shell() is
not the answer, & you need API calls (as you originally suspected) or some
other approach.

HTH,
TC
(REALLY off for the day now!)

 

[test]

Oops - you said before that it works fine without the piping.

Cheers,
TC

 

[test]

AHA! I just realized. Pipes are handled by the DOS command-line processor.
They are not part of the standard execution subsystem. So I'm sure that the
other respondent's answer, using cmd.exe and /c, or whatever it was, will be
the solution.

HTH,
TC
(ABSOLUTELY off for the day. I drove back, to post this!)

 

[gxdata]

TC

Yes, I got the answer in microsoft.public.vb.winapi newsgroup, but the batch
file will also work (caveat - see below) since it calls the command
processor anyway.
Piping input directly to the executable isn't valid, since it is the command
processor that does the piping / redirection.

Thank to both Salva and Bjorn (in microsoft.public.vb.winapi newsgroup).
What they suggested works, but see below.

Using a batch file works -

' First, explicity change app path to o:\vincenty\ ... else, the following
' or other solutions by Bjorn Holmgren / Salva Maiorano do not
work
' B1.BAT simply contains inverse.exe < %1

sCMD = "O:\Vincenty\B1.BAT INPUT.TXT"
retval = Shell(sCMD, vbNormalFocus)

It's pretty obvious, really - although I could fully path INPUT.TXT and
B1.BAT, the batch file I used does not have an explicit path to
inverse.exe - and even when it does, the output file that it creates
(totally under the control of the executable inverse.exe, and specified as
input by INPUT.TXT) will be written to the app.path directory.

Just not thinking straight today!

Thanks again for all the help.

Ian Thomas

 

[TC]

Glad it's sorted.

TC

TC

Yes, I got the answer in microsoft.public.vb.winapi newsgroup, but the batch
file will also work (caveat - see below) since it calls the command
processor anyway.
Piping input directly to the executable isn't valid, since it is the command
processor that does the piping / redirection.

Thank to both Salva and Bjorn (in microsoft.public.vb.winapi newsgroup).
What they suggested works, but see below.

Using a batch file works -

' First, explicity change app path to o:\vincenty\ ... else, the following
' or other solutions by Bjorn Holmgren / Salva Maiorano do not
work
' B1.BAT simply contains inverse.exe < %1

sCMD = "O:\Vincenty\B1.BAT INPUT.TXT"
retval = Shell(sCMD, vbNormalFocus)

It's pretty obvious, really - although I could fully path INPUT.TXT and
B1.BAT, the batch file I used does not have an explicit path to
inverse.exe - and even when it does, the output file that it creates
(totally under the control of the executable inverse.exe, and specified as
input by INPUT.TXT) will be written to the app.path directory.

Just not thinking straight today!

Thanks again for all the help.

Ian Thomas

will