I need to be able to run a few simple Perl scripts off of an NTFS (win server 2003 R2) drive. Is there any way to install Perl on this network drive (Strawberry or ActiveState, Strawberry preferred for built in cpan module compiler) and be able to run the scripts with whatever real time mounting on machines that do not have have/need a Perl distribution installed?
So far not having much luck with any relevant documentation.
Yes, we do this all the time.
Install Perl on your fileshare. I prefer to do this from the Windows Server hosting the fileshare, but I don't think it's necessary. If you don't have Remote Desktop and Admin access to that server, you'll need 2 PC's, 1 for the install and 1 to test this out. You can't test this on the same PC/server that ran the install.
Run this Windows Registry script on the test PC:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.pl]
#="Perl Script"
[HKEY_CLASSES_ROOT\Perl Script]
#="Perl Script"
[HKEY_CLASSES_ROOT\Perl Script\DefaultIcon]
#="C:\\WINDOWS\\system32\\Icons\\ActivePerl.ico,0"
[HKEY_CLASSES_ROOT\Perl Script\shell]
#="Open"
[HKEY_CLASSES_ROOT\Perl Script\shell\Open]
#="Open"
[HKEY_CLASSES_ROOT\Perl Script\shell\Open\command]
#="\"Z:\\network-folder\\Perl\\bin\\perl.exe\" \"%1\" %*"
[HKEY_CLASSES_ROOT\Perl Script\shellex]
[HKEY_CLASSES_ROOT\Perl Script\shellex\DropHandler]
#="{86C86720-42A0-1069-A2E8-08002B30309D}"
You will need to change this:
"C:\\WINDOWS\\system32\\Icons\\ActivePerl.ico,0"
to a path (preferably on the PC, not the network!) of an icon to go with the .PL files. You can drop those 2 lines from the reg script if you don't want a custom icon.
More importantly, you will need to change this:
"Z:\\network-folder\\Perl\\bin\\perl.exe\"
to the path where you installed Perl.
The DropHandler portion of that script is explained in more detailed in this other post: How do I create drag-and-drop Strawberry Perl programs?
Hope that helps!
Related
A friend told me that Windows PowerShell doesn't have these Unix-style commands. Well, I tried and saw that I can in fact run these.
Now I'm wondering why is that. Could it be because I have installed NodeJs on this Windows machine?
If they are not by default usable in Windows PowerShell, is there a way to find out what exactly has brought them into use in this Windows installation?
Running Windows 8.1.
For those that are interested, based on the chosen answer, I found out that installing Git on this machine has brought those commands to use:
PS C:\Users\myusername> where.exe grep
C:\Users\myusername\AppData\Local\Programs\Git\usr\bin\grep.exe
PS C:\Users\myusername> where.exe less
C:\Users\myusername\AppData\Local\Programs\Git\usr\bin\less.exe
You can try this
where.exe find
where.exe less
where.exe grep
They'll return the path to the exe file if those tools exist on your PC. You can always run find because there's find.exe, although it's not Unix find but a tool for searching text. less and grep won't be available by default but if you have Cygwin, MSYS or Gnu32 installed then they'll be ready in path. Git on Windows runs on MSYS so unsurprisingly you can run less, grep or other Unix tools
Note that you need to use where.exe command instead of only where command like on cmd.exe because where on powershell has a different meaning
If you wonder why you can see them, you can run the Get-Command command, which will tell you where the files are being called from (also a great tool to find the underlying VBS scripts which get called when you run commands from time to time)
For instance, the LS command works in PowerShell, but it isn't actually the same binary used in Bash.
_>Get-Command ls
CommandType Name Version Source
----------- ---- ------- ------
Alias ls -> Get-ChildItem
We can see here that in this case, running LS is actually a PowerShell alias which calls the Cmdlet (that is to say, the native PowerShell command) of Get-ChildItem.
If you run this on the other commands you can determine why you see them. Maybe you install cygwin at some point, or installed Python / Ruby (some installers package Bash binaries).
I'm pretty new to powershell integration in Jenkins and my scripts won't run because (I believe) I need powershell to be executed in 64 bit. Running:
[Environment]::Is64BitProcess
in my execution sequence yields false an then a cmdlet that I use (Get-WindowsFeature) is shown as not recognized as a cmdlet, etc. Any way to execute 64 bit powershell scripts?
Thanks!
Environment
Jenkins on Windows (mine happens to run as a service)
plus Powershell plugin (for running Powershell scripts as "build steps")
Jenkins will typically call upon the correct version of powershell.exe. However, the executor/slave process must be running a 64-bit JRE so that PowerShell can also operate in 64-bit mode.
A simple tester project with the following Powershell script can show the above 32-bit vs 64-bit nature:
$env:Path # Path will have the right Powershell available
[intptr]::size # outputs: 4 = 32-bit, 8 = 64-bit
Stop-WebAppPool FOOBAR # fails when 32-bit, succeeds when 64-bit
Console output example (extra blank lines for clarity):
[Powershell Test] $ powershell.exe -NonInteractive -ExecutionPolicy ByPass "& 'C:\Windows\TEMP\hudson123456789.ps1'"
C:\Windows\system32;C:\Windows;C:\Windows\System32\WindowsPowerShell\v1.0\
4
Stop-WebAppPool : Retrieving the COM class factory for component with CLSID
{688EEEE5-6A7E-422F-B2E1-6AF00DC944A6} failed due to the following error:
80040154 Class not registered (Exception from HRESULT: 0x80040154
(REGDB_E_CLASSNOTREG)).
At C:\Windows\TEMP\hudson123456789.ps1:7 char:1
Solution
tl;dr... Install 64-bit JRE, and configure Jenkins to be 64-bit.
I used chocolatey to install a fairly recent JRE, via "Administrator" PowerShell:
First, install chocolatey:
iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))
Looked for the latest version available https://chocolatey.org/packages?q=java (chocolatey has multiple packages for the same thing, often not kept fully up to date).
Then, install JRE (using the one with the higher JRE number):
choco install -y javaruntime
Or:
choco install -y jre8
Finally, I edited my jenkins.xml configuration so that it would run using the 64-bit JRE instead of the built-in JRE.
Changed:
<executable>%BASE%\jre\bin\java</executable>
To (set the path as appropriate for your instance):
<executable>C:\Program Files\Java\jre1.8.0_66\bin\java</executable>
This one should be an "always fresh" symlink (handled by system updates) that ought to allow your Jenkins instance to survive Restart and Update events:
<executable>C:\ProgramData\Oracle\Java\javapath\java.exe</executable>
Then I restarted Jenkins. Powershell execution woke up to the might of 64-bits. Note: I am using a single Jenkins instance that does double duty as the "server" and "execution slave" at the same time. For fully autonomous slaves, I would suppose doing whatever to get the slave-agents processes in 64-bit mode would result in a similar success.
Full automation? According to the chocolatey "jre8" package documentation, using command line switches, it's even be possible to force fixed destination paths for JRE, and exclude 32-bit and/or 64-bit editions, if fully automated non-interactive steps are needed. https://chocolatey.org/packages/jre8
I am not familiar with Jenkins, but it seems like it's a 32 bit process itself.
Can you specify the location of the PowerShell executable? If so, try to use this path:
C:\Windows\SysNative\WindowsPowerShell\v1.0\powershell.exe
If you can't do that, then you might be able to do it in code in your "execution sequence" with Invoke-Command:
Invoke-Command -ComputerName . -ScriptBlock { [Environment]::Is64BitProcess }
All the code in the scriptblock will be run in a separate 64 bit process and the results will be serialized and returned.
Explanations
Paths
On a 32 bit Windows OS, the system folder is C:\Windows\System32.
On a 64 bit Windows OS, the 64 bit system folder is also C:\Windows\System32. But the system folder for 32 bit processes on a 64 bit Windows installation is in fact C:\Windows\SysWOW64.
For compatibility, a 32 bit process on a 64 bit OS will have any calls to C:\Windows\System32 transparently redirected to C:\Windows\SysWOW64, unbeknownst to the process.
To enable a 32 bit process to reference the real System32 on a 64 bit OS, you can you use C:\Windows\SysNative.
Since PowerShell has a 32 bit and a 64 bit version, and it lives inside the system folders, you need to use the above rules to reference the correct executable depending on whether you're calling it from a 64 or 32 bit process.
The typical scenario (you want to call the version of the same bitness) is easiest (just call powershell.exe or reference it via System32), but it gets hairy if you want to reference the other version.
Invoke-Command Method
The Invoke-Command cmdlet lets you run code, typically on another computer, but you can run it on the same computer as well. This will spawn a completely separate process, and any output gets serialized and sent back to the calling process.
The caveat to this method is that you must enable PowerShell remoting on the machine, via Enable-PSRemoting or Group Policy (shameless self plug).
The default profile (Microsoft.PowerShell) that you connect to on a 64 bit machine will be a 64 bit version of PowerShell, regardless of the OS of the caller.
Incidentally, if you wanted to use Invoke-Command to connect to a 32 bit version, you could do so by explicitly specifying the profile Microsoft.PowerShell32.
OK, so the answer was pretty simple, yet maddening all at once. Basically, the module(s) didn't exist in both of the Powershell paths (x86 and x64), so copying the modules over to the 32-bit powershell environment fixed the issue.
further suggestions:
check path of 32bit-JRE, remove path or uninstall 32bit-JRE --
also swapping path-position with 64bit-JRE might work
check path(s) of PowerShell, remove path of 32bit PowerShell
(..\SysWOW64\..) and add the other one to the path (..\System32\..)
This worked for me!
I've installed ActiveState Perl on my new Windows 10 PC. I've installed the same exact version of Perl on several of my own PC's, and it's installed on 100's of other users' PC's in my company. Same exact install, created by me.
This is the first time trying this on Windows 10. The basic actions of double-clicking a Perl script (*.pl) in Explorer cause a console window to open and Perl to run the script.
Also, in Windows Command Prompt, I can type perl.exe script.pl, and the script runs fine. But, when I just type script.pl, nothing happens. No output, no errors, no perl.exe processes visible in Task Manager.
The first time I ran a Perl script (from Windows Command Prompt, I believe, using just the script.pl syntax), Windows popped up a window asking me what program I wanted to use to open this file. Perl was the default, and I clicked OK.
I've never seen that window in Windows 7 or 8, so I'm thinking it's something specific to Windows 10, and that it's the thing that's somehow preventing me from just typing script.pl. Because, when launching script.pl, I'm requiring the file associations to pick the right program, but when I type perl.exe script.pl, perl.exe is being launched directly. But, that Windows 10 "pick your default program" thing is getting in the way when running from the command prompt by messing up the file associations.
Not 100% sure why it works from Explorer, though, but I'm pretty sure that I need to clear that default program thing. I removed the registry entry for .pl files under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts, but that didn't help.
This seems to be a more generic problem with Windows 10, or possibly just my installation of it, or a Group Policy I'm not aware of.
The following commands (run in a Admin command prompt) work fine in Windows 8.1 but not Windows 10:
assoc .foo=Foobar
ftype Foobar=C:\WINDOWS\system32\foo.bat %1
echo #echo off > foo.bat
echo echo The filename is %1 >> foo.bat
echo hi > foo.foo
foo.foo
The result should be the output:
The filename is C:\WINDOWS\system32\foo.foo
But Windows 10 does nothing. It seems to only allow built-in apps to be associated in this manner, and not BAT scripts of downloaded/installed EXEs.
Turns out that Microsoft reversed the polarity of a Registry setting in Windows 10, and this is biting other Perl programmers too. The solutions is to set HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\InheritConsoleHandles to "0".
MSDN post here: https://social.msdn.microsoft.com/Forums/en-US/f19d740d-21c8-4dc2-a9ab-d5c0527e932b/nasty-file-association-regression-bug-in-windows-10-console
Make sure your PATHEXT environment variable has .pl in it.
I have installed ActivePerl 5.14.2 on a Windows 32 bit machine running XP. My problem is that I'm trying to install a few modules with PPM and it's not working out.
According to ActiveState's website, all you need to do to install a module from their repository is "ppm install module name" , example: http://code.activestate.com/ppm/Template-Toolkit/
Every time I try this or any other module I get: "No Perl script found in input"
Even when I do just "ppm" I get the same message, even though the GUI should run.
When I run PPM with a GUI from the start menu I get this error: "Failed 500 Can't connect to ppm4.activestate.com:8080 (connect: timeout)”
I though that it might be my connection, so using cmd.exe I used the set HTTP_PROXY command and then tried ppm install, but still no luck. So is there any way I can get these modules installed?
Any advice is appreciated !!
Invoke the cpan prompt from your command prompt. Go to cmd and simply type cpan. If you successfully enter cpan prompt them there is probably no issues with your Perl installation. To install a module from cpan prompt just use
cpan>install Module::Name
Screenshot below shows command to install module Net::Stomp
If the above does not work, check if your FTP data and connection ports needs to be added to the Windows firewall exceptions (Ports 20 (FTP Command port) and 21 (FTP Data port)).
Alternatively (if you don't want to add port 20 21 to exception), you can go to the cpan prompt and use an ftp_proxy by
cpan> o conf ftp_proxy http://your.ftpproxy.com
and then issue install command. Or you can update your ../CPAN/config.pm file to make permanent changes to the ftp_proxy parameter.
The next step would be to try set the FTP_PASSIVE mode to 1. By default the libnetcfg configuration for this is set to 0. To change this find libnetcfg.bat file (should be somewhere C:\Perl\bin), open the file in an editor and replace
ftp_int_passive 0
to
ftp_int_passive 1
Again, looking at you r timeout error it seems that your network is blocking you from accessing the CPAN ftp mirrors, this would happen mostly if you are inside a corporate VPN. The solution to this can only be proxy servers.
I'm trying to install a custom build software on Windows Server 2008R2, 2008 and 2003. The software needs the "Desktop-Experience" feature from Windows to be installed.
I know I can check with servermanagercmd.exe (even though it's kind of cumbersome) in 2003 and 2008 - unfortunately, this does no longer work in 2008R2 (64bit) from inside an NSIS installer - it does work if I just run the command. Called from the installer, I'm getting a "servermanagercmd.exe is not recognized as an internal or external command, operable program or batch file."-error, even if I'm setting the working directory to c:\windows\system32 (yes, on a 64 bit machine, but there's no servermanagercmd.exe in sysWOW64).
Here's the line of code inside NSIS:
nsExec::ExecToStack 'servermanagercmd.exe -query | findstr "Desktop-Experience"'
In 2008R2, I thought the situation would actually improve, as PowerShell is now installed by default. However, when trying to get the information, I need to first load the ServerManager module inside PowerShell - but this module is not available for reading for Trusted Installer . So I'm facing the same situation again: If I'm running my powershell command from a command line, it works, but not from inside the NSIS installer.
Again, here's the line of code inside NSIS:
nsExec::ExecToStack 'powershell.exe "& "Import-Module ServerManager"'
The three(!) (double)quotation marks are actually correct.
So, does anybody know of a way to check whether Desktop-Experience is installed (and install it if not) in Windows Server 2008R2 from inside an NSIS installer? The solution does not need to work on Server2003 or 2008, because the string parsing from servermanagercmd.exe works there.
Are you using the macros in x64.nsh to turn off WOW64 redirection? (Or use "$windir\sysnative\servermanagercmd.exe")