But is that true for all OS’s and platforms? Like someone already said, it doesn’t work on the Mac. The Perl interpreter itself might change / to : before calling the OS, but what about real /’s in file names, like «notes from 4/27/99»? What about :’s in the file name?
A solid program should always use the native path separator and do so uniformly and consistantly.
If that’s not handy, Perl 6 will reportetly offer uniform URL support, so you can use file:// notation on files on any OS, with %xx for funny chars and / for seperators. There might also be a module that deals with paths as a collection of nodes and abstracts the actual syntax.
And just because the OS takes / as an alias, or Perl translates for you behind the scenes, what happens to individual programs you invoke? In the COMMAND.COM shell, the / will parse wrong, as we saw on a recient posting. A program might get confused if / and \ are mixed in the same string. Who knows? you’re at the mercy of whoever wrote that program!
—John
[reply]
CGI Re: Paths in Perl by andye (Curate) on Sep 05, 2001 at 17:51 UTC
‘course, there’s a different issue if you’re writing a CGI script which accepts a file upload.
Assuming you want to extract the filename from the pathname, I’ve been known to use something along the lines of this: but if anyone has a better solution then I’d be interested to hear it.
Windows paths in perl
Divakar has asked for the wisdom of the Perl Monks concerning the following question:
How can we find perl installed path in windows? in unix, we give «which perl», «whereis perl». do we have same kind in windows?
Comment on perl installed path in windows?
Replies are listed ‘Best First’.
Re: perl installed path in windows? by Corion (Pope) on Nov 23, 2011 at 14:29 UTC
[reply] [d/l] [select]
Re: perl installed path in windows? by BrowserUk (Pope) on Nov 23, 2011 at 16:08 UTC
As Corion indicated, for perl, all you need is:
In general, you could use the following simple .cmd file:
Which I call pf.cmd (for PathFinder), and use it like this:
[reply] [d/l] [select]
Re: perl installed path in windows? by raybies (Chaplain) on Nov 23, 2011 at 14:48 UTC
I always just echo %PATH% and look for it in there. But I don’t generally use the install path the way i do in linux, in windows, I’ll invoke my scripts using «perl perlscript.pl (command-line-args)» in windows commandline.
[reply]
Re: perl installed path in windows? by MVS (Monk) on Nov 24, 2011 at 04:24 UTC
You could also install File::Which, which includes a Perl-based version of ‘which’ called ‘pwhich’:
Windows paths in perl
Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:
hey, I use activestate perl 5.8 and i have two versions of it installed i think on the same computer.
one located in C:\Perl and the other located in D:\Perl.
I’m not sure why two of the same versions were installed, (im not the admin, but i have access). perhaps it could be because one version of it is 5.6 and the other is 5.8.
How can I tell what path my scripts are using for perl? Is there something on Windows where I can check environmental variables for perl?
Replies are listed ‘Best First’.
Re: find path to perl on windows by Corion (Pope) on Aug 05, 2005 at 09:04 UTC
The easiest way to find out which Perl is being used is to ask Perl:
This will tell you which Perl the OS finds first. You can also check $^X from within your Perl scripts and restart your script under a different Perl, but that is somewhat fragile.
[reply] [d/l]
Re: find path to perl on windows by davorg (Chancellor) on Aug 05, 2005 at 09:05 UTC
Look at the value in $^X. See perlvar for more details.
«The first rule of Perl club is you do not talk about Perl club.» — Chip Salzenberg
[reply]
Re: find path to perl on windows by inman (Curate) on Aug 05, 2005 at 09:24 UTC
The Perl executable that is executed by default will be determined by your system path (type path at the command prompt to see what it is). The path is searched in order to find executables etc. that are not specifically identified.
If you need to change the version of Perl used then you (or the administrator) will need to change the path environment variable.
perl.exe is also associated with the .pl file extension. You will want to verify that this association points to the correct version of perl. Save a perl script with the code mentioned previously ( print $^X) and run it using the perl executable perl test.pl and by just entering the name of the file.
Since you mention environment variables — there are a number that can be associated with Perl. Type ‘set’ to view the environment. Variables that start with perl may influence the behaviour of perl on your machine.
Look at perlrun for more details.
[reply] [d/l] [select]
Re: find path to perl on windows by furry_marmot (Pilgrim) on Aug 05, 2005 at 16:13 UTC
I had this problem with ActiveState Perl when I actually did install Perl in D:\Perl, and then later in C:\Perl. Their installer apparently doesn’t clean up the registry when you uninstall. The upshot, if I remember correctly, was that it sometimes thought it was installed on C:, and sometimes on D:. Or, rather, the executable knew where it was, but the configuration was screwed up and sometimes modules or the PDK got installed in the wrong place if I wasn’t paying attention.
If you want to fix the problem permanently, first uninstall Perl and any add-on programs such as the PDK, then physically remove all Perl directories you can find. Then use regedit to track down and remove all references to ActiveState in the registry. After that, things should be normal.
Do I need the Perl bin directory in the PATH to run perl programs (on Windows)?
Traditionally, I would just have C:\perl\bin in my PATH variable, but due to version conflicts I would like to keep different perl versions at locations C:\Perl-versionXY\bin and just execute my Perl scripts via directly invoking C:\Perl-. \bin\perl.exe theScript.pl .
This is actually to be run under an automated system, where we already directly invoke C:\perl\bin\perl.exe for all perl scripts. (But C:\perl\bin is also in the PATH.)
To facilitate different Perl versions side-by-side, I’d like to remove C-perl-bin from the PATH to make sure we don’t ever see side effects from any Perl related PATH settings.
Is this supposed to work? What about modules that require additional DLL files (like LibXML, that requires the LibXML.dll in the bin directory of perl)??
I’ll be using Strawberry Perl portable for the side by side versions. (Who’s readme file mentions some PATH settings, but doesn’t mention which is used for what.)
2 Answers 2
Provided that all the DLLs are in the same directory as the executable, it should work normally. If there is only one entry for Perl in the path, then the DLLs must be in the same directory as the executable (or are being found using some explicit logic) so you should be OK. When an executable loads a DLL, the first place searched is the directory containing the executable.
If you do run into trouble, one option would be to create a command file for each version. You could give these different names, like perl58.cmd, perl514.cmd, etc., put them all in a single directory, and put that directory on the path. In each command file, add the corresponding Perl directory to the path and then launch Perl with the command-line arguments:
Note use of the setlocal command so that the change to the path is not exported back to the command line window you’re running the command file from.
I would caution that if you do not have the Perl bin directory on the PATH, and anything that you executes attempts to invoke program that lives in the bin dir without providing an explicit path (bad practice, but that doesn’t stop it from happening) then you get failure, and depending on how that failure is handled, could manifest in problems that are subtle and hard to debug.
How to change @INC to find Perl modules in non-standard locations
Prev Next
When using modules that are not installed in the standard directories of Perl, we need to change @INC so perl will be able to find them. There are several ways to do that solving different use-cases.
We are going to see a use-case and a solution, but if you have arrived to this page, I wonder, do you really have a special case, or do you just need to install the Perl module?
Loading your private Perl module
You have a script and have just started to move some parts of it, out to a new module called My::Module . You saved the module to /home/foobar/code/My/Module.pm .
Your perl script now starts like this:
When you run the script you get a friendly error message like this:
Perl cannot find your module.
Upgrading a Perl module
On a system you are thinking to upgrade a module that came from CPAN. You don’t want to install it in the standard location yet. First you’d like to put it in some private directory, try it, and install to the system only once you are sure it works well.
In this case too you «install» the module in a private directory, e.g. in /home/foobar/code and somehow you’d like to convince perl to find that version of the module, and not the one that was installed in the system.
The use statement
When perl encounters use My::Module; it goes over the elements of the built-in @INC array that contains directory names. In each directory it checks if there is a subdirectory called «My» and if in that subdirectory there is a file called «Module.pm».
The first such file it encounters will be loaded into memory.
If it does not find the file you get the above error messages.
@INC is defined when perl is compiled and it is embedded in the binary code. You cannot change that, unless you recompile perl. Not something we would do every day.
Luckily the @INC array can be changed in several ways when we execute a script. We’ll see these solutions and discuss when each one of them is appropriate to use.
PERLLIB and PERL5LIB
You can define the PERL5LIB environment variable (though PERLLIB works the same way, I’d recommend using PERL5LIB over PERLLIB as that makes it clear it is related to Perl 5) the same way you can define the PATH environment variable. Every directory listed in this variable will be added to the beginning of @INC .
On Linux/Unix when using Bash, you would write
You can add this to the
/.bashrc to make it always available when you log-in.
On Windows you can set the same in the cmd command window by typing
For a more long term solution follow these steps:
Right-click My Computer and click Properties.
In the System Properties window, click on the Advanced tab.
In the Advanced section, click the Environment Variables button.
In the Environment Variables window in the «User variables for Foo Bar» section click on New and type in the following:
Variable name: PERL5LIB
Variable value: c:\path\to\dir
Then click OK 3 times. Windows that you open after this will already know about the new variable. Type this in the command window, to see the newly set value:
This will add the private /home/foobar/code directory (or c:\path\to\dir directory) to the beginning of @INC for every script that is executed in the same environment.
In taint mode, that will be explained in a separate post, the PERLLIB and PERL5LIB environment variables are ignored.
use lib
Adding a use lib statement to the script will add the directory to @INC for that specific script. Regardless who and in what environment runs it.
You just have to make sure to have the use lib statement before trying to load the module:
One note here. I saw several companies where use lib statements were added to the modules so they will be able to load their dependencies. I don’t think this is good. I think the right place to change @INC is the main script or even better, outside the script such as in the two other solutions.
-I on the command line
(That’s a capital i)
The last solution is the most temporary solution. Add a -I /home/foobar/code flag to perl when running the script.
perl -I /home/foobar/code script.pl
This will add /home/foobar/code to the beginning of @INC for this specific execution of the script.
So which one to use?
If you would like to just test a newer version of a module, I’d recommend the command line flag: perl -I /path/to/lib .
If you are installing lots of modules in a private directory then I’d probably use PERL5LIB though we’ll also see local::lib that does this for you.
use lib is used in two cases:
When you have a fixed, but not standard company-wide environment in which you put modules in a common standard location.
When you are developing an application and you’d like to make sure the script always picks up the modules relative to their own location. We’ll discuss this in another post.
