No recent polls found
Think about Loose Coupling | |
PerlMonks |
bart has asked for the wisdom of the Perl Monks concerning the following question:
I'd like to use the standard DOS box, that perl displays when running a perl script on my Windows box, for my normal output, and I'd like to add another DOS box, for my STDERR, for info/error messages, without interfering with my normal output.
I didn't find anything on CPAN, the docs of Win32::Console say:
A process cannot be associated with more than one console, so this method will fail if there is already an allocated console.
Perhaps somebody here has done this before? If so, can you share your recipe?
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: Open a second DOS window
by Thelonius (Priest) on Oct 08, 2003 at 18:29 UTC | |
You can start that program independently or you could have the main program start it as below (in which case you would want to take out the outer while loop (replace while with if)): Note that there's an awkward sleep() here to wait an undetermined time for the listener to start. This race condition could be fixed, but it might be simpler to just run the showerr program independently first. | [reply] [d/l] [select] |
by Thelonius (Priest) on Oct 08, 2003 at 19:47 UTC | |
| [reply] [d/l] |
Re: Open a second DOS window
by benn (Vicar) on Oct 08, 2003 at 18:36 UTC | |
...though this only works on later Windows versions - 2000 upwards, I believe. For earlier versions, you could try one of the various DOS redirect utilities available. HTH, Ben. | [reply] [d/l] [select] |
Re: Open a second DOS window
by castaway (Parson) on Oct 08, 2003 at 18:41 UTC | |
Personally I prefer log files for that.. less hassle :) C. | [reply] |
by hartwig (Sexton) on Oct 09, 2003 at 13:32 UTC | |
| [reply] |
Re: Open a second DOS window
by vek (Prior) on Oct 09, 2003 at 15:03 UTC | |
I agree with some of the other suggestions that logging to a file is probably a better way to go. Redirecting STDERR would be a good start, then as you progress further and want to log all kinds of things (as I'm sure you will in time) try Log::Log4perl. I've started using it instead of our home grown logging system and I like it a lot. Of course it might be total overkill for what you're attempting here though :-)
--
vek
--
| [reply] |
Re: Open a second DOS window (a working possibility)
by bart (Canon) on Oct 09, 2003 at 22:35 UTC | |
One problem I see is with the console window title bars. The second console gets a nice title "perl", but the original program gets a pretty ugly title, consisting of the whole command line bar the pipe symbol, of the program it just started. It actually appears on the wrong console window. Oh well. Now it's just a matter of building a tiny module that does whatever needs to be done. In the meantime, you can play with this:
Update (24 hours later): Oh, damn. Though it works well on Win98, today I've had a chance to try and run it on XP, and it doesn't work there, at all. Perhaps it's a difference between the start executables on both platforms, or else, between the command line interpreters — command.exe vs. cmd.exe. I'll have to try and use BrowserUK's version, using Windows::Console and avoiding start completely. It works on Win98, and hopefully, it'll work on XP, too. And onb anything in between. | [reply] [d/l] |
by BrowserUk (Patriarch) on Oct 09, 2003 at 23:26 UTC | |
Try this
Name that as Errcon.pl and then do
You'll need to use ^Break to end the progam. Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham"Think for yourself!" - Abigail | [reply] [d/l] [select] |
Re: Open a second DOS window
by jonadab (Parson) on Oct 09, 2003 at 19:37 UTC | |
It is possible to accomplish what you want, but not straightforwardly. The problem is that DOS does not have any such concept as STDERR, at least not in anything like the Unix sense of that term. Traditionally, DOS software does not print error messages to the console unless they are fatal and the program is bailing back out to the prompt immediately, in which case there was (think DOS here, not a command box window on Windows, which is intended as a compatibility measure only) no point whatsoever in being able to redirect that output, since it would typically be one sentence long and the user would be getting a prompt. (Remember that DOS was not intended to be Unix, to run on university computers where people were developing software and doing research; it was intended to sell to businesses for things like spreadsheets.) For more verbose error messages in the DOS world, you either explain it onscreen in a fashion that is integrated with the rest of your app (think: text-based dialog box) or else you write it to a log file. For these hysterical raisins, DOS did not have a redirectable STDERR, which leads to your current problem. All C libraries for DOS and for Windows face this issue: do we want to support compiling Unix software that assumes it can just write willy nilly to STDERR, and if so how? The usual approach is to make STDERR synonymous with the console, which is IMO absolutely the wrong way to do it. (What the C libraries probably should have done, back in the eighties, is point it to C:\STDERR.LOG, but it's far too late for that now. What C libraries IMO should be fixed to do now is show these messages in a window available by clicking an icon in the system tray -- but nobody listens to me.) What just about all C libraries do, as I said, is map it to the non-redirectable console. (The console is not by its nature intended to be redirectable; it is not in any sense a stream. The BIOS calls that most C libraries use for writing to it can just as well be used to draw text-based pulldown menus and dialog boxes; they support absolute positioning and that sort of jazz, rather more like ncurses than STDERR on Unix.) As a result, the C library's standard error stream is largely useless on DOS -- and also on Win32 by extension. My advice is, don't use it, in Perl or any other language, if your code needs to support Windows. However, Windows 95 and later come with some facilities like multitasking that will allow you to fake it, particularly since in Perl it is possible to close off STDERR and open it pointing to something else (something _other_ than the C library's concept of STDERR), such as a pipe or log file. This is what you should do.
| [reply] [d/l] |