in reply to Recovering From Win32::Console

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


Replies are listed 'Best First'.
Re: Re: Recovering From Win32::Console
by marinersk (Priest) on Jun 05, 2003 at 22:20 UTC
    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]

In Section Seekers of Perl Wisdom