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

I've written a Perlprogram which accepts a password at a DOSprompt on a Win32platform, and so to control TTY ECHOI've used Win32::Console. That worked great. But when the console control object goes out of scope, all inputs are immediate and blank (i.e., $geninp = <STDIN>;doesn't wait for actual keyboard input, it merely exits and $geninpis either blank or undef; I haven't tested to see specifically which).

I've worked around the problem by using ourinstead of my to define the console control object scalar, but this doesn't feel like a graceful solution. Namespace pollution, anyone?

I've tried to use the Win32::Console::free()and similar methods to get it to release the object more gracefully in hopes it would return console behavior to its default, but the results are the same as simply letting the object go out of scope -- default behavior is not reinstated and the results are unusuable.

I'm curious if this is a one-way street; in other words, once you start using Win32::Consoleto do console work, are you simply stuck with it until the end of the script?

Anyone with Win32::Consoleexperience out there have any insight to share on the matter?

Replies are listed 'Best First'.
Re: Recovering From Win32::Console
by BrowserUk (Patriarch) on Jun 05, 2003 at 21:43 UTC

    I don't quite follow what the problem you are having with Win32::Console is, the code and an error message is usually easier to follow than a wordy description.

    However, if the only use you are making of Win32::Console is to disable echo for password input, then I strongly recommend you grab Term::ReadKey. Inputing a password then becomes: 

    use Term::ReadKey;

...
ReadMode(2);
my $password = <STDIN>;
ReadMode(0);

    [download]

    The added bonus is that it takes care of platform dependancies under the covers, should portability ever be a requirement.

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller


[reply]
[d/l]
      I wondered about the need for a code snipppet.

      Term::ReadKeywouldn't load on my system. Something about missing terminators or something.

      Anyway, here's the code:

      Read more... (2 kB)

      If you change the "my $cnsbuf;"to "our $cnsbuf;"the wild-n-crazy console problem will go away.

[reply]
[d/l]
[select]

        I think what your doing is fraught with problems. Using console IO and stdio on the same handle is much like using sysread and friends alongside <READ> on the same filehandle; it may work some of the time, but the interaction between the two modes of operation will eventualy conflict and produce undefined (and possibly undefinable) results. That's not to say you couldn't make it work, but your unlikely to get much support doing so.

        The Console api's allow a process to effectively have multiple consoles. When you create a new console specifying one of the standard handles, you are effectively tying that handle to the Console api's. As you haven't specified any modes, you are getting

        GENERIC_READ | GENERIC_WRITE | FILE_SHARE_READ | FILE_SHARE_WRITE by default.

        Once you so tie the handle to a console, unless you take steps to untie it, when the console handle goes out of scope, the handle is effectively thrown away (read:closed), hence why making the handle global with our delays the onset of the problem.

        I really think that unless you intend using the Console Api's for all your terminal IO, then you would save yourself a lot of grief by solving your problems with Term::ReadKey. Mixing API's the way you are is only likely to lead to more frustration.

        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller


[reply]
[d/l]
Re: Recovering From Win32::Console
by guha (Priest) on Jun 06, 2003 at 13:52 UTC

    A few days ago I found the node masking password entry, revisiting it today due to your question it seems the author has recently updated the node.

    Some luck for you :)

    HTH
[reply]

Back to Seekers of Perl Wisdom