Hey All. Sorry for this broad/general question, but my schedules are very tight nowadays and maybe somebody can save me the time of researching this question. QUESTION: What’s the deal with Windows 10 Pro 64-bit and trying to run ActivePERL 5.26 (or 5.28)? The last time I installed a working version of ActivePERL was in 2017 (5.??) on a Win 7 PC. Everything worked fine on that build, and on the build before that (2010)… [and on the build that I had before that (2004)].
Now that I have finally upgraded to Win 10 64x and installed ActivePERL 5.26, I can’t seem to get much of ANYTHING to work well. Is there a short answer to that? Is it a Win 64x security thing?
The download build goes OK.
I try to run some scripts and nothing is working as it should.
Term::ReadKey seems to be a part of this package, but that ain’t working as it expected either (does not read key press)
Even reading arrays doesn’t seem to be happening for simple scalar assignments??
I installed as “Administrator”.
I checked/changed permissions on any/all folders that PERL resides in, uses, or writes to.
I know that at some point I’ll have to try to find the time to sit down and look at this thing, but for now any suggestions are appreciated.
Thanks much.
MISC. NOTE: I’ve got a good number of scripts that are in the 600-line to 1000-lines of code range. So, line-by-line deconstructing this thing would be a monster (nightmare) task.
Hi John,
Not sure if you saw this but our newest Perl, is Perl 5.32. It represents a radical departure for us where it’s only delivered via our package manager State Tool. But I know it works great on Win 64. If you’re not afraid of the command line you might want to give it a try. More information here https://www.activestate.com/perl-532/. Sometime next year we’ll be reintroducing installers.
As ActivePeERL 5.26 or 5.28 in general those are know to work but hard to say without seeing specific error messages.
Term::ReadKey could very well be a Window specific issue. If you have any further information feel free to post it here.
Reading arrays, highly doubtful that it’s broken in our build or we would have heard about that for now. But then again I’m not a Perl expert, but I do work with tons of them. Feel free to post some sample Perl code and we can at least verify if it’s suppose to work or not.
Thanks for the note, Scott. I was figuring that somebody might chime in with a word that Win 64x is finicky, just like it can be with so many other things. All of my previous ActivePERL installations installed and worked right out of the bag without a hitch. That’s “one of” the reasons I waited this long to change to Win 64x. (I think that the first install that I used of ActiveState was in 2004?.. possibly it was at the previous job in 2001??)
One of the issues I ran into right away with Win64x is that the system takes ownership of some folders. “I” was the one who copied the scripts to a folder in the first place, and then Windows wouldn’t let “me” edit “my” own scripts. That, and Windows seems to be even more active with the security thing (to prevent malware), so there might be some permissions issues with running code all willy-nilly in various folders around the PC.
I’ll make some time to look at it. It’s personal home PC use, so not super critical that I get it up and running immediately. Since this new PC is all still a relatively new install, I may go ahead and look at 5.32 and the State Tool. Thanks.
That’s great! Glad to hear you’ve been with us for so long!
You’re spot on. In general, most issues we encounter on Windows is either related to newer security/antimalware protections or path related issues from library authors whose primary OS is linux. The security issues can be tricky as they don’t always fail in obvious ways. Being that we’ve had 5.26 and 5.28 out for so long I expect that’s the culprit.
5.32 is a good choice because that’s where the lion share of our development effort is going these days so you’ll find us more responsive to issue there. Best of luck and keep me posted on your progress, feedback like yours will help us make it less finicky so always appreciated!
Just for posterity, here is an example of one of the problems I’m having. I reduced the following snipet of code all the way down to a text book example with just 7 lines of code - and it still doesn’t run properly. This short ‘readkey’ has been working on my Win 7 machine for the past 10 years without a problem. When I run the script below (on Win 10 64x now), initially it would not read a key press at all. But now, when I run the script, Windows will fork a Perl process, open the window, but just will sit there blank (instead of ‘print’-ing to the screen the word “Selection”. ‘After’ I press the letter “r” for example, it will at least read the key input now (“r”), and ‘then’ it will print
“SelectionThe key pressed was: r”
I’ve seen that happen before, but never with just a few lines of test code. I don’t remember what caused it before; whether a sub-process was being forked in a situation with an array or something… I don’t remember. (I don’t recall it being a standard I/O thing of some sort though, or a local variable issue.)
I supposed I can go back to ‘standard in’ for now to avoid the readkey issue. Now, onto line by line debug/testing for the array issue. Hey… I tried… to put off switching to Win 10 for as long as possible. Maybe I’ll try my old Win 95 machine.
OK, HERE’S A QUESTION…an even BETTER QUESTION:
WHAT ON EARTH MIGHT HAPPEN IF I RUN
ActivePerl-5.10.0.1004-MSWin32-x86-287188
on my Win 10 64x ???
ActivePERL has been pretty resilient all these years that I’ve used it, so I figure “what the hay”… I’ll install the last version that worked for me for all of those years. AND IT WORKS!!! Everything in all of my scripts (so far) is working now!!!
(yeah, but, yeah… I’ll be keeping plenty of backups on hand - in case this thing is not designed to run on x64 and yields unexpected results.)
John, that issue in your mini test script could be a print buffer problem. Perl may not print anything to screen until it has a full buffer or the script ends. You could try including \n in your prints i.e.
print “Selection\n”
which may flush the buffer or include the line
$|++;
Before any print statements. Which should turn on autoflush.
I found this issue when Perl updated at one point so the functionality probably changed, can’t remember when though, but was a couple of years ago at least
Issues with old versions are most often with the installers not understanding User folder layout changes in newer versions of Windows. x86 on x64 issues can come up when there are two versions of a service, and the 64 bit service is targeted by the x86 code instead of the 32-bit equivalent. The main issue with that Perl would be it’s age, and the age of everything that went into building it.
This problem seems to be lasting… (but I can’t go back to an older version, I’m just beginning)
The package mentionned there is not installed and can’t be, it seems.
If I type
state install Term-ReadKey
it doesn’t install (while other modules/packages I needed such as Email-Simple installed well)
Maybe there’s another equivalent package (with minimum need to edit the script)?
Your problem may be procedural. I don’t see that you have a working/forked copy of any project on our servers. If you’re trying to add a module, the install command will need to be able to build that module in the master copy of the online project you are linked to. If you are only linked to one of our read-only projects, the install command can’t make the changes on the project and will fail.
When something fails from the command line, the best thing to do is go online to the copy of the project you are working from, and inspect what happens when that module is added to the project. If you’re working only on Windows, it’s probably a good idea to remove all the other platforms from your forked copy of the project. Get it to just what you need, and it will be both faster and more reliable when you interact via the State Tool command line.
I didn’t formally “create a project”, just added packages after installing Active State from there (at that moment, the latest 5.36 standard version for Windows 10).
It’s
Public
Only members of this organization can modify it, but anyone can view and install this runtime.
So I was quite surprised that you couldn’t see anything - but one can guess it’s because it’s just a “build”.
The packages I successfully installed from the command line are shown when I display my account (I updated indeed the online version with
state push
as I saw explained)
I found that package Term::ReadKey doesn’t exist here on Active State site but… TermReadKey does (I hope it’s quite the same and think this difference may imply a slight and feasible rewriting of the script(s))!!
Note: research on this site finds it only if you type the entire name (i.e. a research with Term doesn’t show it)
I could install this in a build and update my local build with
state pull
Not tested yet though so not sure it finally works as it should.
Provisional conclusion: it seems to be “simply” a problem with the exact name of the package…
(my answer seems lost so I type a shorter one)
Thank you for answering and
I just have a “build” that I maintained up to date between the online and local versions.
I found that Term::ReadKey doesn’t exist but TermReadKey does!
(Research finds it only by typing the whole name, i.e./e.g. “Term” doesn’t bring this answer…) It seems to be a problem with the exact name of the package.
Probably, people need to edit slighly the scripts using it.
I’ve not tested yet if scripts work but it looks better now.