in reply to cls and perl

I really think that it has something to do with the buffers because the system calls within the functions of FTP and Telnet work when executed in the cmd prompt. Do you think that when extract spawns the FTP/TELNET calls, a wait() call should be used?

To further clarify: if a 'cls' is called any time after the FTP/TELNET calls, the mainmenu does not freeze. After extract finishes, the following is called t(he freeze occurs at the $ans = <STDIN>;):
sub mmenu{ print "\nDo you wish to go back to the MAIN menu? [y/n] y\b"; $ans = <STDIN>; chomp($ans); if (($ans eq "y") || ($ans eq "")) { goto mainmenu; } else { exit 0; } }

Replies are listed 'Best First'.
Re^2: cls and perl
by JediWizard (Deacon) on Sep 23, 2004 at 15:34 UTC

    I don't see the "extract" function in the code you posted, so I can't quite guess what it is doing. The other external program calls you are making in the code you posted use system which will wait for the command invoked to finish before returning to the controll flow of your code. If you you think the probelm may lay in a buffer of some filehande, you should try turning on autoflush. If you are using a scalar or IO::Handle object as your filehandle use $fh->autofuch(1);. If you are using a barword file handle, or are concerned about STDOUT or STDIN you could try:

    select((select(STDOUT), $|=1)[0]); select((select(STDERR), $|=1)[0]);

    Hope this helps...

    May the Force be with you
Re^2: cls and perl
by DrWhy (Chaplain) on Sep 23, 2004 at 16:11 UTC
    Just a thought off the top of my head, because I'm not quite following the full flow of code that you are talking about...

    Is it possible that STDIN is getting closed or redirected by the telnet/sftp code? You could check for this by testing whether STDIN is open to a tty at the start of mmenu.

    if (-t STDIN) { # go on with normal operations } else { # complain and/or re-open to the tty }
    DrWhy "If God had meant for us to think for ourselves he would have given us brains. Oh, wait..."