As you predicted cpanm . also failed because...
This program is blocked by group policy. For more information, contact your system administrator.
gmake: *** Makefile:524: blibdirs Error 1
| [reply] |
This program is blocked by group policy. For more information, contact your system administrator. gmake: *** [Makefile:524: blibdirs] Error 1
Presumably, you'll get the same message if you execute gmake -v.
My take on this is that when you (or cpan or cpanm) execute gmake.exe, it's this gmake.exe that has been doctored by the group Police that gets found.
But what happens if you set things up so that the correctly functioning gmake.exe that Strawberry provides gets found ?
You could find out by running something like C:\StrawberryPerl\c\bin\gmake -v, though I don't know if I've guessed the location of your Strawberry Perl installation correctly.
The .msi edition of Strawberry Perl that you already have *appends* its paths to the end of the PATH environment variable - which means that if there's already another gmake.exe in the PATH, then it's this other gmake.exe that gets loaded.
The "portable" editions *prepend* their paths to the beginning of the PATH environment variable - which means that if there's already another gmake.exe in the PATH, then it will not be used.
That's why I suggested using the "portable" edition, though you could also just rearrange the PATH yourself so that your existing Strawberry installation comes first.
(You can have both an msi and a "portable" edition installed - it doesn't have to be a case of just one or the other. In fact you can have as many portable editions installed as you like. I've got at least 15 of them.)
Anyway ... that's my take on it. It may not be correct as I don't really know what sort of weaponry your group Police are prepared to deploy. (Is my life in danger ?? ;-)
And marto's suggestion of trying to get your Police to soften their stance makes good practical sense.
Good luck.
Cheers,
Rob
| [reply]
[d/l]
[select] |
| [reply] |
You're working in a restrictive environment, engage with the sysadmins to get what you need, or ask for a suitable system upon which you can build the tools you need for distribution on other systems.
| [reply] |
microsoft products being what they are, TIMTOWTHI (There Is More Than One Way To Hack It) applies. I am sure you will find a way to bypass it. My favourite from this extensive list is to run it via rundll32.exe gmake.dll,main. (most likely you don't have gmake.dll but you can create it in another machine). Can windows be that dumb? Computer says maybe (<<-youtube link)
also running it via cmd.exe may be another loophole: cmd /K "C:\SomeFolder\MyApp.exe"
bw, bliako
p.s. TIMTOWTHU (There Is More Than One Way To Hack Undoubtedly) and that's written on stone.
| [reply]
[d/l]
[select] |
Such security policy limitations are often in place for very good reason. Circumventing such things may be technically possible however is almost always a bad idea, you could find yourself out of a job, or in legal trouble.
| [reply] |