Unrecognized character \x90 at line..
I am getting above error while executing perlcode.exe, But when it is executed as Perl (i.e perlcode.pl) it works like a charm. And, I am surprised I haven't seen any such error in Google. Any help appreciated.
The input file is a LaTeX file which may or may not have Unicode.
Why is .pl working, but .exe is not working?
What is meant by the ERROR: Unrecognized character \x90 at line..?
Note that use utf8; is used in the Perl script.
I had this problem when I wasn't thinking straight. I had compiled the .pl file with perl2exe but was running the command
perl c:\tmp\myexe.exe
Obviously you don't need to have perl at the start - just run the exe
To change the perl code to an .exe file, you'll need to compile it. If you are saying that the pl code works allright, but the exe not, maybe that it's the issue.
One of the options is to use pp to do it. You can find it here.
its a typo mistake which has been made in a batch file while calling exe.
Related
I call the program myfoo.pl, my first line is #!/usr/bin/perl.
When run from command line myfoo.pl I get command not found.
again when run using perl myfoo.pl it runs and completes. Not all my perl programs have this problem some run just using (path)/source.pl I ran head -1 myfoo.pl and got a print of my first line. no indication of problems.
Looking at the limited information you gave, I would say you are probably missing permission executable on the file myfoo.pl. To which the solution is to do
chmod +x myfoo.pl
It could also be a path to binary problem, that the perl binary is not located in /usr/bin/perl. In which case you need to figure out where it is, with which perl or where perl.
I suppose it could also be that the file myfoo.pl is not in your current directory, which it needs to be. Because of path settings, you also may have to execute it with
$ ./myfoo.pl
Because . is part of your path variable.
It is impossible to say for sure, because you are not answering questions, however. So when you eventually get around to answering questions, we may have more answers.
I am trying to run a Perl script as a CGI script. When I run the perl script from cmd line, it runs perfectly well, but it shows the following error when I run it from my browser.
Storable object version 1.012 does not match $Storable::VERSION 1.010 at
C:/Perl/lib/DynaLoader.pm line 225.
Compilation failed in require at C:/Perl/site/lib/AsiaXMLUtils.pm line 20.
BEGIN failed--compilation aborted at C:/Perl/site/lib/AsiaXMLUtils.pm line 20
The perl script concerned has basically been designed to queue some job to a remote software.
In case it rings a bell, Line 20 in the mentioned file is :
use Storable qw(&retrieve &store);
Here are the things I have done :
I have checked the following pages on how to troubleshoot your CGI
script but haven't got around the problem.
I have checked that the perl versions are the same for my PC as well
that used for the software I am sending the script too. I guess had
that been a problem, I wouldn't have been able to run the script
from the commnad line either.
I have run a simple Perl CGI (hello world) script using the same basic html code, so I guess that means I am not putting the cgi files (or accessing them) at the wrong places.
I am running a deadline for finishing this task, and thought should ask what approach I should take to solve such a problem. I am new to Perl. Any cues to what I should read to get around the problem will be greatly appreciated. I cannot share the code anyways, since much of it is proprietary.
Storable is an XS module, which means that it has both C code in Storable.dll (or Storable.so on Unix) and Perl code in Storable.pm. That error indicates that the version of Storable.dll ("Storable object version 1.012") does not match Storable.pm ("$Storable::VERSION 1.010"). If you can run the script from the command line, that means that your webserver is either using a different version of Perl, or #INC is different, or possibly you have an extra Storable.dll in your webserver's directory.
Try to use nstore instead of store. This way, your file will be crossplatform.
Also, try to reinstall the Store module.
Here is how I was able to solve the issue, which btw wouldn't have been possible without the valuable inputs of Miguel Prz and cjm.
Regarding the Storable Module : After reading both the answers, I noticed that my pc had two versions of
Perl. I removed one of them. This got me around the "Storable object
version 1.012 does not match $Storable::VERSION" error. Sounds pretty lame, I know. But I thought I should let you know anyways. But then
I ran into another set of problems. This :
Can't locate
AJE/Constants.pm in #INC (#INC contains: C:/Perl/lib
C:/Perl/site/lib .)
From comparing with the #INC of the perl environment from the
command line (for which I found this SO post very useful), I
noticed that the #INC that my web server was using (consisting of only 2 directories as shown above) did not include
many of the directories in the #INC of the command line perl environment. This is where cjm's words came back to me! I then used use lib to add those files in my
perl script and that solved the problem!
Thank you for all the help!
I want to profile my Perl code by using Devel::DProf.
when I am running the profiler like
perl5.8 -d:DProf abc.pl # default version of Perl in my PC (Solaris) is 5.003
then it produces the tmon.out file in the current directory, but when I run
dprofpp
then it is not undertanding the command and giving error like command not found.
I know Devel::DProf - a DEPRECATED Perl code profiler, and should use Devel::NYTProf but just want to know why it is giving such an error, may be I am missing something.
How can I solve this?
Find out where you installed dprofpp and ensure that the directory is in your PATH, or call it with the full path.
I was sent a perl script over mail and asked to run it .I placed it on my local drive as is but when I tried to run the script it shows me
/usr/bin/perl^M: bad interpreter: No such file or directory
I checked and usr/bin/ does have perl in there .I am not sure what is wrong.I checked a bit and looks like I am missing some spaces or something ..I tried adding those at the end of
usr/bin/perl and at the end of the file but that didnt help either.
I even tried to use dos2unix
dos2unix oldfile newfile
'dos2unix' not found.This is on MacOSX.
Might I also mention that I am sshing into my mac using my windows machine at home.
You're on the right track. Your script has DOS style newlines at the end, which is not supported by your kernel.
The solution is to use something to convert the DOS newlines to Unix style. dos2unix would presumably work if you had it, so use something else equivalent.
In the absence of dos2unix, you can use tr (on Mac OS X) to strip the DOS / Windows new-lines:
tr -d '\r' < old.pl > new.pl
This will solve the "bad interpreter" issue.
"Can't locate Gpu.pm in #INC" is a different issue. Either you don't have Gpu.pm installed on your Mac (or whichever computer on which you are running this, I'm confused by your comments) or it's not in your include path. I don't who what that script is or what it does. A quick look on http://search.cpan.org/ revealed nothing.
If you can get that Perl module (presumably from whoever supplied oldfile), you'll have to ensure it is in #INC.
Do this in vim:
:%s/^M//g
save the file and try running it again
execute: vim
when vim opens go to command mode by hitting the escape key .... at the command prompt (:) type: %s/^M//g. This will remove all "^M" characters from the file.
dos2unix in Perl:
perl -pi -e 'tr/\r//d' file.txt
Maybe it's dumbest question in the world, but I seriously have problems with it and could use help. I am trying to run perl script on linux. It's a simple text editing script, nothing fancy. I googled for it and I found that I had to chmod +x it and then just run myscript.pl in the console. Since it's supposed to modify a text file I did myscript.pl > myfile.txt after chmoding it
But it doesn't work. I get: bash: perl myscript.pl: command not found
Unless myscript.pl is in your path you will need to specify the current directory.
$ ./myscript.pl
You can check if the current directory is in your path with $ echo $PATH. If you're frequently using this script you can put it in the path by moving it to a directory that's part of your path, usually ~/bin.
Or by adding the current directory to the $PATH environment variable. Check the documentation for your shell for instructions.
Can you post the first few lines of your script?
Specifically, if you have #!/usr/bin/perl are there any typos on that line, extra spaces, etc.?
Also do a ls /usr/bin/perl (or whatever is on that line) to make sure it's actually there.
It doesn't look like perl is installed on your Linux machine. Do you get the same thing when you try this: # perl -e 'print "hi";' ?
As Chirael said, it sounds like your shebang line (the directive at the top of the file, that tells the shell how to run the script) is invalid somehow. You can bypass the shebang line entirely by invoking your script as:
perl myscript.pl > myfile.txt
You also don't need to set the script's executable bit, as with this method of invocation, you are only reading the script, not executing it (from the shell's perspective).
According to this thread, it could be from different representation of the new line.
Have you written the script on a windows box and copied over to your linux box?
What is your text editor?
I had the same issue, and traced it to DOS line endings (^M). Running dos2unix on the .pl file fixed the issue.
Please use,
./myperl.pl > outfile.txt
to give the current directory path
thanks