I have a query with regards to exporting library path & include for Platypus variant caller. The htslib it requires and platypus are installed on the server and I don't have sudo permissions to change them.
I am trying the following code to export library & include for running the caller. Am i missing osmething because am not able to execute it?
Code:
#!usr/perl-w
use strict;
use warnings;
`export LIBRARY_PATH=/opt/htslib/lib/`;
`export LD_LIBRARY_PATH=/opt/htslib/lib/`;
`export INCLUDE_PATH=/opt/htslib/include/`;
system ("python /opt/Platypus_0.8.1/Platypus.py callVariants --help");
Any sort of help would be appreciated.
You're setting the env vars of freshly-made shells, not of the Perl process that is to parent python. For that, you need the following:
$ENV{LIBRARY_PATH} = '/opt/htslib/lib/';
$ENV{LD_LIBRARY_PATH} = '/opt/htslib/lib/';
$ENV{INCLUDE_PATH} = '/opt/htslib/include/';
The last line of your code is better written as follows, since it avoids a needless shell:
system("python", "/opt/Platypus_0.8.1/Platypus.py", "callVariants", "--help");
Related
Background
Inside a chsell script, I am invoking a subroutine from a perl module and saving its result to a variable in the following manner:
set result =`perl -M/some/hard/coded/path/lib.pm=theFunction -e 'theFunction( $A_VARIABLE_ARGUMENT )'`
Despite the fact that I explicitly specify the module, my script throws this error:
Module name required with -M option
Question
How do I invoke a hardcoded module with perl's -M option?
You cannot, as the -M option is translated to a use statement which takes only module names, not paths. However, you can add the path to be the first module search path using the -I option. Modules are searched relative to each search path by translating them like Foo::Bar -> Foo/Bar.pm.
perl -I/home/hard/coded/path -Mlib=theFunction
As a note, you should definitely not call your module or package lib, because this is an important core module (in fact, it's what -I is using here).
I try to configure my mySql config file with perl.
I use config::simple for doing this.
my code is:
#!/bin/perl
use Config::Simple;
$cfg = new Config::Simple('/etc/mysql/my.cnf');
$cfg->param('bind-address', '192.168.1.11');
$cfg->save();
the problem is that I get an error when a row only has a key and not an value to it. How do I fix this problem?
To extend simbabque's comment I would suggest using Config::MySQL to deal with MySQL config files.
Config::MySQL extends Config::INI to support reading and writing
MySQL-style configuration files. Although deceptively similar to
standard .INI files, they can include bare boolean options with no
value assignment and additional features like !include and
!includedir.
I have installed Mason module from cpan. Now i am executing my first program using mason template.
first_mason.mc
% my $name = "Mason";
Hello world! Welcome to <% $name %>.
first_mason.pl
#!/usr/local/bin/perl
use Mason;
my $mason = Mason->new(comp_root => '...');
print $mason->run('first_mason.mc')->output;
This throws an error as follows
first_mason.mc is not an absolute path at C:/Perl/site/lib/Mason/Request.pm line 256**
Note
I am placing both files in the path where mason is installed(to find an installation path ,i used perldoc -l Mason) and executed a program using perl first_mason.pl
There is no need to put your files in the directory where Mason is installed:
Perl should know where to find Mason when you import it with use (assuming your perl installation is correct).
Mason will know where to find the .mc file via the comp_root argument.
The component name needs to be specified as a path relative to comp_root, always beginning with /.
You need to leave out the .mc from the component name.
So, if you place the 2 files in your home directory, then the script should look like this:
#!/usr/local/bin/perl
use Mason;
my $mason = Mason->new(comp_root => $HOME_DIR); # where $HOME_DIR is `C:\User\your_name`
print $mason->run('/first_mason')->output;
From the documentation:
The component root and component paths
When you use Mason, you specify a component root that all component
files live under. Thereafter, any component will be referred to by its
virtual path relative to the root, rather than its full filename.
For example, if the component root is '/opt/web/comps', then the
component path '/foo/bar.mc' refers to the file
'/opt/web/comps/foo/bar.mc'.
#stevenl fully answers your question. Simply don't blindly copy the Synopsis from the Mason docs, need read the docs too. :) E.g. in the example code:
#!/usr/local/bin/perl
use Mason;
my $mason = Mason->new(comp_root => '...');
print $mason->run('/foo')->output;
you need replace
and the shebang line #!/usr/local/bin/perl with the real path to your perl interpreter
the '...' with the real path in the filesystem, where your component are, e.g.
comp_root => '/some/real/path/here/where/my/component/root/is'
However, I wrote this answer mainly with a reason: if you want use the Mason for the web-app development, check the Poet module too. It GREATLY simplifies the whole process, and you will not need care about many-many things. E.g. after installing the Poet you can simply:
poet new MyApp
myapp/bin/run.pl
and you will immediately get (without any configuration) an WORKING web-app, and you could access it in your browser at http://localhost:5000. Your component_root will be inside of the myapp directory as myapp/comps.
I am currently using ActiveState Perl 5.14 and the R project version 2.13.2. Within Perl I am using Statistics::R version 0.08. According to ActiveState the more recent versions of Statistics::R (through 0.24) failed to pass scrutiny and are therefore not available through the PPM.
History: I have been successfully using Perl to access R for some time to perform analysis. Now I want to generate JPEG images of the results of the analysis for easy visualization.
Here's the problem: I can generate the images successfully from within the R console. However, when I run the same commands through Perl I only get a blank image. My console code includes (simplified, of course):
x<-c(1,2,3,4,5)
y<-c(5,4,3,2,1)
jpeg("C:/temp.jpg")
plot(x,y)
dev.off()
And my Perl commands include (also simplified):
$R = Statistics::R->new();
$R->start_sharedR
$R->send("x<-c(1,2,3,4,5)");
$R->send("y<-c(5,4,3,2,1)");
$R->send('jpeg("C:/temp.jpg")');
$R->send("plot(x,y)");
$R->send("dev.off()");
Any suggestions? I know that there are other plotting options accessible to Perl. I have eliminated some (GD Graph) because X-axis data is not treated as numeric. I'd prefer to keep it in R if at all possible since I'm already interacting in that package for the analysis. Thanks!
Forget Statistics::R. Just use a system call. At least it's what I do!
my $path_to_r = "C:/Program Files/R/bin/Rscript.exe";
my $cmd = "x<-c(1,2,3,4,5);";
$cmd .= "y<-c(5,4,3,2,1);";
$cmd .= 'jpeg("C:/temp.jpg");';
$cmd .= "plot(x,y);";
$cmd .= "dev.off()";
system($path_to_r . " -e '" . $cmd . "'");
If your R script grows up a bit or if it takes input from the parameters, write it in a file and Rscript.exe this file.
It works fine for me with Statistics R::0.27, but not with 0.08, the only version I could find in Active perl's package manager. In order to install 0.27, I had to use cpan command line. Make test fails but make install was fine. Bit of a life-saver.
(By the way I'm a relative noob. Using cpan command line was pretty easy however.
Type i /Statistics-R/ from cpan command line, then
install FANGLY/Statistics-R-0.27.tar.gz (or whatever the relevant file is. I'm using a windows system so RSPerl annoyingly not an option for me. I note that latest Statistics::R version is dated March 2012 so perhaps some of the previously documented (piping?) problems have been solved. You may also need to install a 'maker'; in my case it was 'dmake', not 'nmake'. Pretty easy, you can get a version of make from M$ website and copy that + .err file into PERL\bin dir. But help on this is available elsewhere. Hope this helps!)
My hosted scripts have been moved and no longer work.
The specified CGI application
misbehaved by not returning a complete
set of HTTP headers.
I notice that someone at my host company has modified my scripts so that where I used to have
use lib 'd:/myorig/LIB';
I now have
use lib '//newhost/LIB';
Should this work?
I tried 1800 INFORMATION's suggestion and ran the minimal script of
#!perl -w
use lib '//whatever/lib';
print "success";
...which gave the same result.
Update: ysth's suggestion of FatalsToBrowser did indeed reveal more information. It looks like the path (added by someone from the hosting company) might be wrong.
Update2: The hosting company now says that these scripts, unchanged from the previous host mind, are throwing lots of syntax errors. "Since we cannot debug your scripts for you we suggest you contact the original programmer and ask them for help". <grinds teeth>
Partial Resolution: The hosting company finally realised they hadn't set permissions correctly. They still aren't right, and (aargh) they don't allow site owners to set folder permissionsn, not even on folders within their own sites.
I don't know if it should work or not, but my intuition is that it would be okay. However, the two use lib lines you posted are not equivalent.
# go to the 'd' drive and use the 'myorigLIB' directory on that drive
use lib 'd:/myorigLIB';
# go to the 'newhostLIB' server - no path is specified - this looks invalid to me
use lib '//newhostLIB';
Perhaps you need to specify the path to the share on the server? Also, you might need to look at permissions? Maybe the user the CGI is running as cannot access that network path?
Also, you could write a simple (non CGI) program to test your theory and just run it:
#!perl -w
use lib '//whatever/lib';
print "success";
Then just run that on the server if you can and see what happens.
No the path is incomplete it needs both a server name and a complete path. It is a bad practice as well because it requires that two machines be monitored rather than one for your application to function.
The specified CGI application misbehaved by not returning a complete set of HTTP headers.
That's a non-error. If you are lucky, your hosting company will make an error log available to you that will show the actual error that perl is dying with. If not,
consider using
use CGI::Carp "fatalsToBrowser";
for testing. (If you are paranoid (which is not a bad thing to be), you will refrain from leaving that enabled once you are done testing, since errors can commonly provide information about your code or even your database that may help a black hat exploit security holes.)
I know I ran into trouble trying to use mapped drives and unc paths from apache because the apache user was not allowed to use network drives. That was difficult to figure out -- but it's possible to do it. That may be a related problem.
#!perl -w
print "HTTP/1.0 200 OK\nContent-Type: text/plain\n\n";
my $path = "//whatever/lib";
print "\nExists ", -e $path;
print "\nDirectory ", -d $path;
print "\nReadable ", -r $path;
print "\nListing:\n";
print "\t$_\n" for glob "$path/*";