jlongino has asked for the wisdom of the Perl Monks concerning the following question:
I've about reached the opinion that using Perl under Win98
is a lost cause. When I try do relatively simple tasks, my
computer freezes. For example, the following script:
use strict;
my @dmap = `map`;
my $mapsize = scalar @dmap;
foreach my $line (@dmap) {
print $line;
}
print "Number of lines in \@dmap: $mapsize\n\n";
It gives me the this message after about 10 seconds:
This program has performed an illegal operation
and will be terminated. Quit all programs, and then restart
your computer.
If the program consistently encounters
problems, click the Start button, then select Help,
Troubleshooting, and 'If you have trouble running MS-DOS
programs'.
Could someone please try this under Win NT/2000 and tell me
if it works or not? If a command runs at the DOS prompt, I
expect it to run when shelled from Perl. Is this asking
too much? BTW, I'm using Active State Perl 5.6.1
(MSWin32-x86-multi-thread).
I love Perl under Unix, but under Win98 it really stinks!
@a=split??,'just lose the ego and get involved!';
for(split??,'afqtw{|~'){print $a[ord($_)-97]}
Re: Perl on Win98 vs. Win/NT/2000?
by dws (Chancellor) on Sep 08, 2001 at 03:19 UTC
|
If a command runs at the DOS prompt, I expect it to run when shelled from Perl. Is this asking too much?
Sadly, the answer in some cases is Yes. I'm not sure of why this is.
I've been able to work around this in most cases by doing one of
system("map > temp");
open(M, "<temp") or die ...;
@dmap=<M>;
close(M);
open(M, "map|") or die ...;
@dmap=<M>;
close(M);
How does the latter case differ from backticks? Perhaps someone with Deep Knowledge will educate us.
(I'm assuming that you have a DOS executable named "map". I don't, but I've run into this problem with other programs.)
| [reply] [d/l] [select] |
|
Back in the olde dayes, of Windows 3.11 and Perl running under a DOS extender, and at least for a while afterwards, back-ticking in Perl did exactly what DOS did: it ran the source program, spooled the output to a temporary file until it ended, then started executing the target file, feeding it the contents of the spooled output.
This is how all std(in|out) DOS redirection worked. So by doing it explicitly in Perl, while more verbose, at least has the advantage of bringing it all out in the open, and you are less reliant on DOS jiggery-pokery.
AFAIK, this output-spooling behaviour is still the norm for Win98, but someone else may like to confirm.
--g r i n d e r
| [reply] |
(Ovid) Re: Perl on Win98 vs. Win/NT/2000?
by Ovid (Cardinal) on Sep 08, 2001 at 03:19 UTC
|
I use Perl on Win98 at home and I have absolutely no problems with it. As for using your code above, I have no idea what command "map" is supposed to be. It's not on my system and there's no point in trying to run the code as the backticks will capture no output.
As for your error message, there's not enough information to tell if it has anything to do with Perl. Can you run the 'map' command from the command line? If so, does it err out? Is there any chance that you have recently reinstalled Perl? ActiveState Perl 5.6.1 is a 600 series release and cannot be installed over a 500 series release. The 5xx release must be uninstalled prior to installing the 6xx.
Good luck.
Cheers,
Ovid
Vote for paco!
Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.
| [reply] |
|
First of all, let me say that it is not my intention to
come across sounding pompous. That type of attitude is
abhorrent to me. However, I do word things as carefully as
possible to avoid ambiguity and that sometimes may come
across as sounding snobbish.
So if it seems that way, apologies. I am rather frustrated
and this post is the result of at least ten revisions to
make it appear less so. I'm only disappointed in the
disparate platform behaviours.
I have virgin installs of ActiveState Perl 5.6.1 on
both my work and home Win98 SE systems. Apparently
backtick functionally is severely crippled under Win98
(I'm sure the OS is primarily to blame). Still, I
don't think it is unfair to expect similar functionality in
this respect from Perl on both Unix and Win98 platforms.
Unix users probably tend to use backticks more than Windows
users because there is a weatlh of useful Unix commands,
more so than with DOS.
Perhaps these two examples shed more light on the topic.
The next runs fine on a Solaris 8 system:
#!/usr/local/bin/perl
use strict;
my @ls = `ls`;
my $lsct = scalar(@ls);
foreach (@ls) {
print "line: ",$_;
}
print "\$lsct: $lsct\n\n";
Producing the following results:
line: hello.cgi
line: obsfu.pl
line: test.pl
line: test.pl~
$lsct: 4
OTHOH, the following reboots a Win98 system without even a
message:
use strict;
my @dirlines = `dir`;
my $dirsize = scalar @dirlines;
foreach (@dirlines) {
print "$_";
}
print "\$dirsize: $dirsize\n";
I hope that everyone can see that one should be able to
expect similar functionality from these examples.
Apparently "backticks" eq "instant reboot" under Win98.
I would certainly welcome tested backtick examples
from Win98 users that would lead me to believe otherwise.
Update: `command /c dir` behaves as badly.
@a=split??,'just lose the ego and get involved!';
for(split??,'afqtw{|~'){print $a[ord($_)-97]} | [reply] [d/l] [select] |
|
Volume in drive C is OVID
Volume Serial Number is 1A46-1A08
Directory of C:\WINDOWS\Desktop\Curtis' Stuff
. <DIR> 01-27-01 9:14a .
.. <DIR> 01-27-01 9:14a ..
WWW <DIR> 11-18-00 11:45a WWW
CGI_CO~1 <DIR> 09-30-00 2:31p cgi_course
ARCHIVE1 <DIR> 08-25-00 9:53a archive1
PERL <DIR> 08-26-00 11:27a Perl
TIDY <DIR> 10-15-00 5:33p tidy
DK BAT 39 12-10-99 8:38p dk.bat
...[snip]...
HTMLTO~1 PL 2,968 06-18-01 7:25p HTMLtoCGI.pl
WEIRD~1 HTM 1,504 06-18-01 7:20p weird.html
17 file(s) 161,721 bytes
9 dir(s) 510,001,152 bytes free
$dirsize: 33
I am using Win98 and ActiveState 5.6.0 on my home machine. Perhaps I'm lucky, I don't know, but Perl has never caused any problems on my box.
Cheers,
Ovid
Vote for paco!
Join the Perlmonks Setiathome Group or just click on the the link and check out our stats. | [reply] [d/l] |
Re: Perl on Win98 vs. Win/NT/2000?
by lemming (Priest) on Sep 08, 2001 at 04:13 UTC
|
Is this the map that comes with a novell client?
I've run across similar problems when running DOS programs
under 98. Especially if said DOS program was not careful
with it's memory management. One of the programs is not
playing nice. It could also be that the DOS program is
wanting more of a footprint than the shell is willing to
hand out after allocating for Perl. Are you running the most current Active State
build? Without knowing more of your problem, I'm afraid
conjecture is the only help you'll recieve at this time.
And just for the record, I'm running 98SE and haven't run
across any memory problems, but I haven't done many shell
calls either.
| [reply] |
Re: Perl on Win98 vs. Win/NT/2000? (boo)
by boo_radley (Parson) on Sep 08, 2001 at 03:14 UTC
|
are you sure you want those backticks in the @dmap assignment? Cause map isn't any program that comes with win98 (or NT/ 2000) that I can see, and the source of the illegal op may be from running it, not the perl script.
| [reply] |
|
The map command is a Novell written-for-DOS command. The
command when executed from the DOS prompt executes without
error and returns the expected results. See my reply to
Ovid about comparisons between ls and dir, which I feel
illustrates the point better.
@a=split??,'just lose the ego and get involved!';
for(split??,'afqtw{|~'){print $a[ord($_)-97]} | [reply] |
Re: Perl on Win98 vs. Win/NT/2000?
by Maclir (Curate) on Sep 08, 2001 at 06:31 UTC
|
As others have said, the use of backticks in a windows / dos environment doesn't do the same as it does in a Unix environment. Remember, one of the fundamental design decisions with Unix, going back 30 years, was that the system would be build of many small, single function "building blocks", that could be assembled and used easily. That is why we can pipe commands, and why shell functions always use STDIN, STDOUT, STDERR in a known manner.
When Perl calls a system function in a Unix environment, all of these things work as designed. However, what you are trying to do is to get the output from a novell command executing in a temporary Dos shell on a windows operating system. Not wanting to bag Novell or Microsoft here, you are stretching the envelope well beyond what it was originally intended.
As someone else suggested, call the command, redirecting its output to a temporary file, then open that file and process it in the standard file input process. At least that way you have a finer degree of control over what is happening.
| [reply] |
|
After determining that NAV 2000 was the likely culprit, I
have rerun the exact same "map" script posted originally.
The results of the Novell/DOS command map perl
script (with NAV 2000 disabled):
perl test.pl
Drives A,B,C,D,E map to a local disk.
Drive F: = USACSCMAIL01_SYS: \
----- Search Drives -----
S1: = Z:. [USACSCMAIL01_SYS: \PUBLIC]
S2: = C:\PROGRA~1\PERSON~1
S3: = C:\NOVELL\CLIENT32
S4: = C:\WINDOWS
S5: = C:\WINDOWS\COMMAND
S6: = C:\MSFORT41
S7: = C:\PCW302
S8: = C:\TP7\BIN
S9: = C:\MYFILES\GOODIES
S10: = C:\BATCH
S11: = C:\CLIPPER5\BIN
S12: = C:\PERL\BIN
S13: = C:\PROGRA~1\IBM\TRACEF~1
Number of lines in @dmap: 17
For those unfamiliar with the map command:
MAP General Help 4.13 (97081
+3)
----------------------------------------------------------------------
+--
Purpose: To assign a drive to a directory path.
Syntax: MAP [option | /VER] [search:=[drive:=]] | [drive:=] [path] [/
+W]
----------------------------------------------------------------------
+--
To: Use:
Insert a search drive. INS
Delete a drive mapping. DEL
Map the next available drive. N
Make the drive a root directory. R
Map a drive to a physical volume on a server. P
Change a regular drive to a search drive C
or a search drive to a regular drive.
Display version information /VER
Do not change master environment. /W
----------------------------------------------------------------------
+--
For example, to: Type:
Map the next available drive MAP N FS1/SYS:LOGIN
to the login directory on server FS1
Map drive W: as a search drive MAP S16:=W:=APPS:WP
to the WP directory
When used without any parameters (as in my example) map
displays all current drive mappings.
@a=split??,'just lose the ego and get involved!';
for(split??,'afqtw{|~'){print $a[ord($_)-97]} | [reply] [d/l] [select] |
Re: Perl on Win98 vs. Win/NT/2000?
by jlongino (Parson) on Sep 09, 2001 at 00:16 UTC
|
This thread has been a good lesson to me about playing the
blame game. Generally I'm very careful about jumping to
conclusions and laying blame without considerable
investigation but I certainly threw caution to the wind on
this one.
When I got up this morning I decided to run the
`dir` example again and my computer rebooted.
Last night, before reinstalling ActiveState, I had closed
all running programs under Win98 like a good Windows user.
I also remembered that no restart was required by the Setup
program. So the reinstallation was probably not necessary
at all.
I got to thinking about why I would be having similar
problems using the same software on two different machines
when other users weren't and then it occurred to me that
ActiveState and Win98 aren't the only things my two
computers have in common. I also have Norton Utilities
running on both.
Not wanting to unfairly assign any blame this time, let
me just say that when I disable Norton Anti Virus Perl
seems to work fine and leave it at that. Thanks to all
respondents to this thread.
@a=split??,'just lose the ego and get involved!';
for(split??,'afqtw{|~'){print $a[ord($_)-97]} | [reply] [d/l] |
|
Not wanting to unfairly assign any blame this time, let me just say that when I disable Norton Anti Virus Perl seems to work fine and leave it at that.
You've hit the nail on the head here with the Norton AntiVirus. I had no end of troubles with real-time virus protection when attempting to run scripts containing backticks, or trying to compile code. I fired off a message to Norton, and they replied that "developers are encouraged to disable virus protection before compiling programs."
As long as you remember to have the realtime protection disabled every time you run a script or compile software, and turn it back on when you've finished (how ludicrous is that?) you'll be fine...
ryddler
| [reply] |
Re: Perl on Win98 vs. Win/NT/2000?
by bjohnso (Sexton) on Sep 08, 2001 at 05:49 UTC
|
I was running in to lockup problems on 98 myself. Where WINOLDAPP would stop responding when running a perl script.
However, I reinstalled ActiveState and presto my problems were solved.
| [reply] |
|
Thanks for your reply. I first reran the installation
program and did a "repair" install with no success. Then I
ran Add/Remove Programs and uninstalled ActiveState,
reinstalled it, and the dir version posted above ran
perfectly. It seems that a buggy ActiveState installation
program is to blame.
An important test will come tomorrow since I
don't have "map" on my home computer. I'll un/reinstall
ActiveState at work tomorrow, try my first example
program and post an update regarding `map`
results. Thanks again, also to everyone else that replied.
@a=split??,'just lose the ego and get involved!';
for(split??,'afqtw{|~'){print $a[ord($_)-97]} | [reply] [d/l] |
|
I find that if I use the backtick in windows on less then vanilla commands to often, eventually I have to reinstall Perl. I have had to do that several times, so I avoid doing anything backtickish on Win32 systems.
| [reply] |
Re: Perl on Win98 vs. Win/NT/2000?
by Anonymous Monk on Sep 09, 2001 at 06:38 UTC
|
at work I've found similar problems. The big boss wanted a (somewhat) simple utility to work with text files, so I made up a perl script to do it. I wanted to avoid the whole issue about explaining how to run a script through the interpreter, so I just used perl2exe - which as far as I can tell, just drags the perl interpreter around with it (more or less). The problem is that I THOUROUGLY test my programs on my computer (and a couple others nearby) with no problems, but when someone else uses the programs on different machines, the computer freezes. Other than the fact that it makes me look like I don't know what I'm doing (programming wise) I find it very fustrating. And from what I can tell, it's all pointing to use of backticks. Guess the moral of the story is, never trust backticks on windows.
Anyone know if Shell works any better? | [reply] |
|
|