I am asking something a little obsolete. I retrieved one of my project written back more than 10 years ago, when I was a student, but unfortunately I could only retrieve the executable.
I am trying to decompile it, but I really cannot recall the Perl version at the time, I remember only that I used PerlApp, and Perl was ActiveState Perl.
If you want, no problem updating the 500 kb executable, I am not gelous of my kid-me-work, I just whish I could see how moron of a programmer I was :)
Thanks in advance
Matteo
Related
This question already has answers here:
Are there Perl GUI builders, especially for WxPerl?
(7 answers)
Closed 9 years ago.
Can anyone suggest me a easy to use Perl language IDE with GUI designing support for Ubuntu.
Take a look at the EPIC plugin for Eclipse. I've used that a few times, and if you like Eclipse, it's very nice.
If you never used Eclipse before, you need to download Eclipse, install it, and then install the EPIC plugin.
Komodo is one of the nicest IDEs for Perl, works with Linux, and is now on sale for only $245!
Gabor Szabo, one of the big Perl mucki-mucks, created Padre. I have never used it, but if Szabo was involved, it's probably pretty good.
I personally use VIM. Yes, it's not an IDE, but it does syntax highlighting, and you can reference the Perldoc by pressing K over a keyword or module name. VIM isn't as easy to use as an IDE, but I find editing in VIM much faster than most IDEs.
ANSWERED: Basically, it can be done with no major side-effects if you compiled your own perl and you did it the same way your OS did. While it isn't a recommended practice, I've been able to run like this for more then a month. I would conclude it is relatively safe to do if you know what you are doing.
We came to the conclusion at work today that we needed to upgrade perl to 5.10.0
CentOS 5.x comes with perl 5.8.8.
We determined that the effort involved in maintaining scripts with #!/usr/bin/perl was futile.
According to some install stuff on CPAN and other places, it isn't a 'good' idea to replace the OS's version of perl. I already updated the link in /usr/bin/. So my question is, how bad is it really to replace /usr/bin/perl?
I've not noticed any adverse effects in our systems yet, but I'm prepared to correct the link (back to 5.8.8) as soon as there is a problem.
I'm worried that there may be some modules in the CentOS standard distro that aren't included in CPAN's source 5.10.0. I'm still trying to figure out what those modules might be.
Thanks in advance.
In my experience, the best practice is to compile your entire stack (Perl, Apache, ImageMagick, ...) from source yourself. That gives you complete control over which versions of everything are used and when everything gets upgraded.
Replacing /usr/bin/perl with one you compiled is a crap shoot. The OS might be using /usr/bin/perl as part of its maintenance or init scripts so changing it could brick your server or cause strange failures.
So ignore the system Perl, build your own, and fix your scripts to refer to your version of Perl.
Generally newer versions of Perl5 attempt to maintain backward compatibility with older versions. But that's not 100% assured. For example, a script that depends on an undefined behavior in Perl 5.8.8 (which shouldn't happen but sometimes does), that behavior may be different under 5.10.0. Nevertheless, it's usually fairly safe to assume that a script written for Perl 5.8.8 will run under 5.10.0 assuming there are no other factors involved.
But there usually are other factors (modules, byte compatibility for XS code, and so on). The list of possible gotchas is huge. That doesn't mean that any one of them will snag you on this go-around, but there is potential for problems.
If you've already got an upgraded Perl in /usr/local/bin, go ahead and use it. But don't dismantle or upgrade the old /usr/bin/ version. It's only a small chunk of hard drive (very small by today's standards).
By the way, a lot of people speak highly of perlbrew (App::Perlbrew on CPAN) as a tool to help maintain multiple versions of Perl.
Well, if you do decide to change the location of where Perl is installed, that is completely up to you and where you prefer it to be. But, keep in mind that any scripts that exist with a shebang line pointing to #!/usr/bin/perl will possibly break.
My recommendation would be that after you have installed it, create a soft link in /usr/bin/perl pointing to the executable for the new version of Perl that you installed. Just a thought. Its a work around to avoid breaking anything.
Creating the link above would certainly help to avoid the possibility of 'bricking your server' as #Mu pointed out.
Regards,
Jeff
This question already has answers here:
Closed 11 years ago.
Possible Duplicates:
How can I obfuscate my Perl script to make it difficult to reverse engineer?
Is there a good obfuscater for Perl code?
Have some Perl code I'd like to resell, but don't want the code to be viewable, just executable.
Is there a way to "secure" the code and if so, what would be the requirements to do this, risks related to it in terms of how easy it'd be to reverse engineer and possible effects on run-time.
There is no sure-fire way. A determined attacker can always find some version of the source.
That said, Acme::Bleach makes it more difficult.
The first time you run a program under use Acme::Bleach, the module removes all the unsightly printable characters from your source file. The code continues to work exactly as it did before, but now it looks like this:
use Acme::Bleach;
The only way to do this is to compile it to machine code, unfortunately this isn't possible for perl. See Edit
You could alternately obfuscate the code to protect it, although its not too difficult to de-obfuscate the code. Check out http://www.stunnix.com/prod/po/overview.shtml or google for "perl code obfuscator" for some more information on hiding your code.
Edit: It appears I'm wrong, see comments for perl compilers that will make machine code. (Should be as safe as distributing a C program)
I'm playing around with Rakudo Perl 6 lately and was searching for a project similar to CPAN. I found CPAN 6, but I think there is no Perl 6 code yet.
So I'm looking for some alternative that does not necessarily aim to be a long term solution, but is capable of maintaining modules and is written in Perl 6.
As Rakudo development goes it might be possible to create more complex Perl 6 code soon.
Your first stop for Perl 6 modules should be https://modules.raku.org/.
Modules should be installed with zef.
Markov owns cpan6.org and worked on-and-off for some years on it. Most people I've talked don't regard this project well for various reasons. Most existing Perl 6 code lives at modules.raku.org, formerly proto.perl.org.
There's been talk on cpan-workers to simply extend the archive structure in some canonical way to make it more suitable for other languages, a solution arrived 7 years later.
The new hotness is zef. This will query modules available on the Perl 6 website. It comes with the latest version of Rakudo * and is very simple to use.
As of today, March 2018, zef is the preferred way of installing Perl 6 modules and it taps two different repositories, the list of modules in modules.perl.org and, effectively, CPAN, which will eventually become the only place for Perl 6 modules.
I need to create a Zip archive after filtering the list of files I want to include. Preferably I'd like the module to work in both Windows and Linux.
Since I need to filter the list of files, I don't really want to to use an external program. I'd rather not introduce external dependencies either so I can compile the script into a single executable on Windows (using ActiveState PDK).
What I already tried
Until now I've used Archive::Zip found on CPAN but it has a major bug on Windows machine that use non-ASCII filenames: the filenames get corrupted in the archive as they don't get translated into unicode.
There is a bug report filed for that but it hasn't been updated in over 10 months and in the module documentation the developer is rather unhelpful (of the "fix your computer or get rid of Windows" kind).
Update:
Thanks to the clarifications from brian and Alan Haggai Alavi it seems that enough love is being put in Archive::Zip to get these bugs out soon and finally have a fully functioning zip module in Windows.
Although the module documentation says some stupid things about Windows, the current maintainer is Adam Kennedy, the same guy who brought you Strawberry Perl. He's definitely not anti-Windows. He released a version October, so they are working on it. There's also an open grant from The Perl Foundation to fix Archive::Extract bugs.The bug you mention, RT 35334: Filename Encoding by Archive::Zip, maybe just needs someone to show it some love. That could be you. People solve the problems that bother them, so maybe nobody interested in the module needs this just yet.
The module has had problems, and I've been following its progress since I use it in a couple projects. It has gotten a lot better recently and can certainly use some love. Sometimes open source means helping to fix the problems that you encounter. I know this doesn't help you solve your problem immediately, but that's how I think you're going to get this done aside from system() calls.
The above said bug has been solved very lately by the addition of Unicode filename support under Windows. A release featuring the fix will be available in CPAN within a week.
You could try the standard-distribution Archive::Extract. It may not be any better than Archive::Zip, but the documentation says that, if there are problems, it goes under the hood to try to use command-line tools on your system to unzip the file. This is probably most robust on Unix, but Windows has a zip archive utility, and it should be accessible via the command line. Plus, Archive::Extract can handle many other types of compression (theoretically).
Of course, it may turn out that Archive::Extract simply figures out what kind of compression the file uses and then passes it to the appropriate other library, which might be Archive::Zip.
You might also try IO::Uncompress::Unzip and it's counterpart, IO::Compress::Zip, for just unzipping, reading, and rezipping. If absolutely necessary. Again, I don't know how much better these will work, but they are all part of the standard library.