Front page | perl.perl5.porters | Postings from September 2001

## [perlhelp] some notes on windows problems

Thread Next
From:
Jarkko Hietaniemi
Date:
September 28, 2001 07:17
Subject:
[perlhelp] some notes on windows problems
Message ID:
20010928171718.B11113@alpha.hut.fi
FYI: some notes on problems regarding perldoc/perlhelp/scripting in
general on windows systems from *name withheld*.

<snip>

Here's some hints for MSWin32 problems that might reappear in perlman:

I'm now dimly recalling at least some of what I had to change in old
perldoc.bat.  First off, using $$to generate a reasonably unique tempfilespec doesn't work nicely under MSWin, because: C:\WINDOWS\Desktop\perlhelp>perl -e "print$$"
482355
C:\WINDOWS\Desktop\perlhelp>perl -e "print $$" 482355 C:\WINDOWS\Desktop\perlhelp>perl -e "print$$"
482355
C:\WINDOWS\Desktop\perlhelp>perl -e "print $$" 482355 C:\WINDOWS\Desktop\perlhelp>perl -e "print$$"
482355
C:\WINDOWS\Desktop\perlhelp>perl -e "print $$" 482355 Open another command.com window and you get: C:\WINDOWS\Desktop\perlhelp>perl -e "print$$"
317351
C:\WINDOWS\Desktop\perlhelp>perl -e "print $$" 317351 C:\WINDOWS\Desktop\perlhelp>perl -e "print$$"
317351
C:\WINDOWS\Desktop\perlhelp>perl -e "print $$" 317351 C:\WINDOWS\Desktop\perlhelp>perl -e "print$$"
317351

And, even weirder, go back to the first (still open) window where we were
getting 482355, and type:
C:\WINDOWS\Desktop\perlhelp>perl -e "print $$" 317351 C:\WINDOWS\Desktop\perlhelp>perl -e "print$$"
317351
C:\WINDOWS\Desktop\perlhelp>perl -e "print $$" 317351 So I just made perldoc use int rand 100000 until it found a not-already-taken filespec. (BTW, that$$ behavior is under 5.6.1, AS build 628.)

But there are graver problems, which I think have to do with the fact that
redirection under MSWin is basically different from Unix redirection,
notably when .bat files are involved.  And under MSWin, perldoc is a bat file.

First off, I think it's the case that if you call a batch file (like
perldoc.bat) that calls perl.exe on a perl program which tries to call
system() (or ?) on a program that doesn't exist, you get a horrible
system lockup that you can recover from only with a hard reboot.
Or maybe you have to be doing "nonexistent_program | foo" or "foo |
nonexistent_program".  I can't remember exactly how to get this problem to
apprear, but I dimly remember that it was like "perldoc -f foo", but never
like "perl -S perldoc.bat -f foo".  If you get reports of hangups under
MSWin, that's the first thing to look for.  This /may/ have been a Perl
problem that can be fixed, or has been fixed.    I'd cook you up a test
case to produce this bug, but it took me hours just to isolate the bug,
since when the bug appears, it takes me a long time to reboot the system,
watch the filesystem check itself, etc.
My solution to this was to eliminate all cases where perldoc calls
nonexistent programs -- I think it was trying to call "pod2man --lax $file |$opt_n -man" in some cases, where $opt_n is by default nroff, which won't exist under MSWin. Second off, you can't redirect output from a .bat file. This seems to be a basic MSDOS problem. See: C:\WINDOWS\Desktop\perlhelp>ver Windows 98 [Version 4.10.2222] C:\WINDOWS\Desktop\perlhelp>type test1.bat @echo off echo foo perl -e "print$^T"
echo bar

C:\WINDOWS\Desktop\perlhelp>test1.bat > foo.txt
foo
1001669260bar

Note that output wasn't redirected!  And the new foo.txt is empty:

C:\WINDOWS\Desktop\perlhelp>dir foo.txt

Volume in drive C is TURMERIC
Volume Serial Number is 0F56-18F7
Directory of C:\WINDOWS\Desktop\perlhelp

foo      txt             0  09-28-2001  3:27a foo.txt
1 file(s)              0 bytes
0 dir(s)          803.58 MB free

So that, plus just basic interface design (i.e., more.com is bone stupid,
besides not being a GUI), led me to think that behavior of perldoc under
MSWin should not be to pipe to more.com, but instead to pipe output to a
temp file, and open that temp file in a text editor, like write.exe (which
kicks open wordpad under MSWin98 -- not sure what it does under MSWin95).
Or start.exe, which just opens the file with whatever application is
associated with that extension.  One or both of these might need to be
called as:
commandname "c:\foo\bar baz\quux.txt"
instead of
commandname "c:/foo/bar baz/quux.txt"
or of
commandname c:/foo/bar baz/quux.txt

These problems with redirection may cause trouble, since perlman.pm seems
to use it a lot.  But that's just my impression from skimming the code.  I
think that most (all?) cases of perlman using redirection could be redone
to just load the appropriate module and call its &main, for cases where
that other program would be a Perl program (i.e., pod2text or whatever).
But I think that would involve a significant rewrite of, well, lots of
things in perlman.pm.

</snip>

--
\$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen


Thread Next

nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About