Testing App

[Mike Trader]

I am trying to test a console display / console text retrieve
code and would very much appreciate it if someone could make
me a small dos app that simply reflects the COMMAND$ it was sent
in a console screen before quitting. Thats it. no frills
I am shelling it from my PBwin app and working with it from
there.
Perhaps you could use
http://www.transferbigfiles.com/

or similar to send it to yourself and then paste the link here.


------------------
Kind Regards
Mike

[Paul Dixon]

Mike,
something like this?

'PB3.5 program
print "Command$=";command$

You can get the compiled version from http://www.axol-electronics.com/command.exe

Or do you need it to wait before it quits?

Paul.

------------------

[Michael Mattias]

16 bits, outputs the command line?
batch file:

rem Showcmd.bat
echo %1

[Michael Mattias]

Just one caution...

Using PB for MS-DOS, PRINT does not put data on the screen the same way as does STDOUT.

Depending on how your application is coded (conveniently not shown) that could make a big difference.

[Mike Trader]

Paul,
Thx for that.

I am using it like this:

    AllocConsole  
    SHELL PBWinDir+"\command.exe " + "Compiling: "+BasFileName,  1 ' Shell Initial Display 

' a lot more code and a few other things like UPX get shelled
' All Console text is visible in one console

    FreeConsole

The console does not go away.
If I do not use it, UPX info will appear and then the console will
go away.



------------------
Kind Regards
Mike

[Michael Mattias]

If the idea is to get the output of all the shelled programs in one place, why not just redirect the STDOUT of those child processes to the same file? (console or disk)

That assumes all the child processes (" a lot more code and a few other things like UPX get shelled") use STDOUT (i.e., are not PB/DOS using PRINT), but that has got to beat the heck out of screen-scraping.

Lots of redirection examples here.

For that matter you could do it to a file with command-line redirection:

  SHELL "cmd.exe /C  Programname1 options >Myoutputfile.txt"  ' start output

  SHELL "cmd.exe /C  Programname2 options >>Myoutputfile.txt"  ' append to it

  SHELL "cmd.exe /C  Programname3 options >>Myoutputfile.txt"  ' append to it some more
 ...
 ...
  SHELL "Notepad.exe  myoutputfile.txt"  ' look at it.

?????

[Mike Trader]

Michael,
I did not know you could do that!

That would be fine except, the operation of all these pre/post compile
processes takes time. The console window is an ideal way to see
waht is going on as it is going on.
UPX, PEcompact, Code Obfuscation apps all create a console window
so I thought i would just follow thier lead.

I suppose it would be possible to monitor the text file and pull
text out of it to display in a GUI as operations progress, but
the main problem I am having is that nothing ends up in this file.

No matter which app i shell to, no text appears in the file!?




------------------
Kind Regards
Mike

[Michael Mattias]

Command-line redirection only works for output to STDOUT or STDERR or input from STDIN. If the child application is not sending to stdout or stderr, well, then it ain't going to work.

Note that it might be sending to stderr, you can redirect that with "2>stderrfilename"

eg

Shell "CMD.exe /C appname options 1>stdoutfilename 2>stderrfilename"

I don't think the two files can be the same name in this case. You'll have to test.

[Michael Mattias]

>No matter which app i shell to, no text appears in the file!?

Show failing code.

Also don't have that file open by another application. Some editors will actually hold the file open meaning the write will fail. Notepad and Ultra-Edit are both OK, they only opens the current file to save when you ask.

[Tom Tallardy]

[[I suppose it would be possible to monitor the text file and pull
text out of it to display in a GUI as operations progress, but
the main problem I am having is that nothing ends up in this file.]]

hmmm, if you have the file open (for monitoring?), neither > nor >> is going to work . . .

you could open & read the file _between_ shells, but it mustn't be open by another process during the shell redirect.

------------------

[Michael Mattias]

> hmmm, if you have the file open (for monitoring?),
> neither > nor >> is going to work

File monitoring does not require the file be open. (Monitoring reads the directory).
However, code in use for said monitoring not shown.

[Michael Mattias]

Well, if you want the STDOUT of your child processes echoed back to your parent program in real time, you can redirect it in the child to a handle representing the write-side of a pipe in the called program. (You read the read-side in the callER)

I know I have not posted any code to do this (I've only played with it), but I am pretty sure I saw a demo of this here once.



[This message has been edited by Michael Mattias (edited July 18, 2007).]