LanX has asked for the wisdom of the Perl Monks concerning the following question:

Hi

is there a more elegant way to achieve the following on windows?

perl -e "$|=1;for(1..100) { sleep 1;  warn time; print time,qq{\n} }" 2>&1 | perl -ne "$|=1;print"

This first script is printing time every second to STDOUT and STDERR.

If the output is connected to a Windows cmd.exe and any text was selected with the mouse, than the output will not only stop but the script will freeze and only continue after the selection was finished!

D:>perl -e "$|=1;for(1..100) { sleep 1; warn time; print time,qq{\n} +}" 1530361604 at -e line 1. 1530361604 1530361605 at -e line 1. 1530361605 # selecting text for some se +conds 1530361606 at -e line 1. # output resumes,last buffer +ed line 1530361622 # after freeze 1530361623 at -e line 1. 1530361623 1530361624 at -e line 1. 1530361624 1530361625 at -e line 1. 1530361625 Terminating on signal SIGINT(2)

( update for clarity: my problems is not that the output stops, but that the complete script stops running in the background.)

The behaviour in a linux terminal is different (much saner), the output might stop but the script will continue running in the background and the buffered output will appear after the selection.

My workaround is now piping the STDOUT and STDERR to a second Perl script which does the buffering without blocking the main script, but is not overly elegant...

Background information is that our provider changed the windows version and activated "QuickEdit mode" for consoles on default.

Now my colleagues are surprised to find out that their batch jobs freeze whenever someone does a simple click into a window which will "quickly" cause a selection ...

Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

PS: I'd rather prefer running the scripts with wperl and directing STDOUT and STDERR to a file. If a live display is needed I'd use a tail -f approach, like with powershells get-content File -wait . Alas changing old working patterns in a team isn't easy ...

PPS: deactivating quickEdit in the registry (which isn't trivial for political reasons) doesn't solve the underlying issue, since a text selection could be initiated anyway.

Replies are listed 'Best First'.
Re: [windows] Non-blockable output to cmd console during text selection?
by BrowserUk (Patriarch) on Jun 30, 2018 at 14:22 UTC
    Background information is that our provider changed the windows version and activated "QuickEdit mode" for consoles on default.

    You can disable quick-edit mode from within the program using Win32::Console::Mode().

    This may help.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
    In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit
      Thanks, I will try this out.

      But is it also possible to activate an input buffer which keeps the output without freezing the Perl script?

      Much like a Linux terminal does?

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

        Update: Actually, tee nul will work okay of you disable buffering on the output of your script:

        perl -le"$|++;print 'x'x80 while do{ 1 for 1..1e7;1}" | tee nul

        That'll allow the script to keep running whilst the console is in a select state, until the pipe fills, and then the script will again stall; but that would be the same on a linux console also I think.


        It already has an associated buffer called the console screen buffer, and you can create as many of these as you like, though only one can be active at any given time.

        But these are not 'simple' fifo-like stream buffers, but rather fully random access (by program and user) 2D arrays of characters and attributes. I'm not saying better or worse, just different.

        The simple way to provide the isolation you want is to put some other program in charge of the screen, an use a fifo between your script and that other program.

        In *nix terms, use a pipe: yourScript.pl | tee nul would probably do it, except now your script has to output 4k before anything shows up on screen at all.

        So, running this:

        perl -le"$|++;print 'x'x80 while do{ 1 for 1..1e7;1}" | perl -e"$|++; +print while <>"
        allows the first script to continue to run flat out, even whilst the second script which has control of the console buffer is blocked in a select state.

        (But disabling selection for the duration of the script is easier.)


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
        In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit