in reply to QuickPerl: a step up from -e

Personally, I would use a good editor, one that allows for programmable macros. Many vi-clones and certainly emacs do. Here's a macro I use (using the editor vile): 
18 store-macro
   save-file
   shell-command &cat "/opt/perl/bin/perl -wc " $cfilname
~endm

[download]
It saves my current buffer, then runs perl -wc on the file, displaying the output. I can bind that to any keystroke I want. (Or, if I were kinky enough to use the mouse aware xvile, to a button or menu-item)

Parsing the output of perl -wc (even with Perl if you want to, many vi-clones can have a Perl compiler/interpreter linked in) and positioning the cursor on the line of the first error would be a not to hard, logical extension.

I certainly wouldn't want to cook up a Tk kludge, and edit in something else than my favourite editor.

-- Abigail

Replies are listed 'Best First'.
Re: Re: QuickPerl: a step up from -e
by John M. Dlugosz (Monsignor) on Jul 05, 2001 at 02:18 UTC
    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

[reply]
      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

[reply]
[d/l]
        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.

[reply]

In Section Seekers of Perl Wisdom