in reply to Re: QuickPerl: a step up from -e
in thread QuickPerl: a step up from -e

If you read my original post, you'd know why I wasn't satisfied with an editor command: lack of console environment. Editor is GUI. Unlike X, you don't have the console that started the graphical program still connected to stdout. Instead, the Win32 system has a somewhat different context. I've published a couple articles in the COBB Group journals on those differences and how programs can mix&match. Piping stdout to a pipe isn't right either, because Win32 doesn't have pseudoterminals and the program can sense that it's not really the console. The C RTL, for example, turns on buffering.

—John

Replies are listed 'Best First'.
Re: QuickPerl: a step up from -e
by Abigail (Deacon) on Jul 05, 2001 at 03:55 UTC
    Well, if you say you don't get console environment when run something from an editor on Windows, I believe you - but I'm very, very surprised your Tk solution does. After all, what that does is taking your code, putting it in a file, and executing it. Which is *exactly* what my macro does, except that it already finds the stuff to be run in a file. I don't know much about Windows, but I'd like to know which magic Windows performs that makes the system()ed program from Tk get a "console environment", while the program run from an editor doesn't.

    -- Abigail

      but I'd like to know which magic Windows performs that makes the system()ed program from Tk get a "console environment", while the program run from an editor doesn't

      Because Perl/Tk, although it shows windows and has an event loop, is still a Console-mode program: perl.exe. The variation wperl.exe is compiled as a GUI-mode program, and even if you write knowing there is no STDIN or STDOUT, there are still a few oddities that don't quite work right.

        Why not just use emacs? It has a shell mode, so you can edit your script in one "window" and run it in shell in the other. It works on both DOS and Unix/Linux (if memory serves DOS shell isn't nearly as nice as Unix, but it does work-- I'll have to double-check this at work tommorrow, and please forgive me if I mispeak). Plus you get all the added benefit of having any output saved in a buffer which is fully cut-and-paste-able. Not to mention the other zillion little things it does that are just plain handy.

        Disclaimer: I've been reading ORA's "Learning GNU Emacs" and I may not currently be enjoying a lot of objectivity in this area.
        Did I say anywhere you need to call wperl.exe from your editor macros? And even if I did, wouldn't you be able to grasp the concept of not copying the w?

        -- Abigail