Hi Alec:

I have tried your suggestion in a simple script. Running the script via
cron dumps $HOME as the path I want.

Also for browser from I what I just discovered from my Perl book is that I
can just use the following to get my paths from %ENV (nto sure why I never
saw this before

$ENV{'SITE_CGIROOT'}; (for cgi-bin)
$ENV{'SITE_HTMLROOT'}; (for base html)

As I want the script to work with both cron and browser I guess the $0
solution is what I need. Just tweaked it like below though as I normally
take off the trailing "/" with the path:

my $HOME = ($0 =~ /^(.*\/)/)[0];
my $CGI = ($HOME =~ /^(.*)\/$/)[0];

I dumped $0 on my Windows machine and it has the path. But the above does
not work as the path for windows is like this from my PC:

K:\somedir\simple.pl

So for WINDOWS this appears to work on my PC:

my $WINDOWS = ($0 =~ /^(.*\\)/)[0];

Cheers

> Hi Alec:
>
> My name is Louis. I've updated my mail folder for this account to
> display my name.
>
> I don't quite understand this statement. Is "$0" the script with full
> path when called either via browser or cron ?
>
> So this will only work on Linux OS but not Windows based Apache servers.
>
> Thanks again.
>
> Cheers.
>
>
>> Hello Unnamed Person,
>>
>> You might want to try:
>>
>>      my $HOME = ($0 =~ /^(.*\/)/)[0];
>>
>> This will set $HOME to the path of the executing script. Note that
>> this is not completely portable, though it works fairly reliably on
>> Linux.
>>
>> So if you put your Perl script in /var/www/cgi-bin (for example), you
>> could do this to get /var/www/htdocs:
>>
>>      my $HTDOCS = "$HOME../htdocs";
>>
>> Or whatever, etc. etc.
>>
>> Regards,
>> Alec
>>
>> On Tue, Nov 04, 2003 at 11:35:35AM +1100, [EMAIL PROTECTED]
>> wrote:
>>> Just a minor typo with attempt 2, the code is
>>>
>>> push(@INC, $cgibin);
>>>
>>> Thanks
>>>
>>> > Hi Sluggers:
>>> >
>>> > I have been looking at an efficient way to move away from having to
>>> constantly have paths specified in scripts repeatedly. So here is the
>>> full story in great detail so that I can hopefully get an
>>> informed decision. This is not a problem but merely looking for an
>>> efficient way to do this.
>>> >
>>> > When I write scripts (Perl) I normally specify the full paths to
>>> the
>>> base root directory (base html dir) and the path to cgi-bin
>>> specified. With these two paths I can access other scripts
>>> interfaces after pushing the path in @INC and use 'require', and also
>>> process text files etc ....
>>> >
>>> > Now I was normally specifying these two paths in all scripts at the
>>> top in the past. But recently have been thinking about moving away
>>> from this. So here are two things I did but is not quite to what I
>>> want to achieve but close.
>>> >
>>> > Attempt 1.
>>> > ==========> > I basically have a text file where I have these two
>>> full paths specified. The file is located in the same directory as
>>> all the scripts. If there are scripts in another directory, then in
>>> that directory I have a sim link to the file that holds the actual
>>> path data. Now in all scripts, I just do this before anything else to
>>> set the paths:
>>> >
>>> > my @paths;
>>> >
>>> > open (FILE, "path.dat") || die "error blah blah ...";
>>> >     while(<FILE>) {
>>> >         chomp;
>>> >         push @paths, $_;
>>> >     }
>>> > close (FILE);
>>> >
>>> > As I know the order of the paths in the file, I have these two
>>> below
>>> as globals:
>>> >
>>> > my $homedir = $paths[0];
>>> > my $cgibin = $paths[1];
>>> >
>>> > This work greats with browser called scripts, but I hit a problem
>>> with scripts that runs via cron. The problem with cron scripts is
>>> that it cannot open the "path.dat" file despite that it's in the same
>>> directory as the cron script itself. I think where cron
>>> executes (don't know where) it's not in reference with the same
>>> directory where the script and file is located, so cannot see it.
>>> >
>>> > So I moved away from this solution and went to attempt 2.
>>> >
>>> > Attempt 2.
>>> > ==========> > I create a 'path.pl' script where I specify $homedir,
>>> $cgibin, and other other common used stuff by all scripts via a
>>> routine called
>>> > "set_paths()". Then with "Exporter::Lite", I export these two
>>> variables and the others.
>>> >
>>> > In other scripts the problem is that I have to tell it from this
>>> 'path.pl' script is. So I am forced to have one path specified. i.e I
>>> have to define
>>> >
>>> > $cgibin = "/path_to_where_path.pl_is_located";
>>> >
>>> > Then I do this
>>> >
>>> > push($cgibin, @INC);
>>> > require 'path.pl';
>>> >
>>> > &set_paths();
>>> >
>>> > This now has all common stuff accessible. But I still have to
>>> specify one hardcoded path in all scripts which is no way as good as
>>> attempt one. With attempt 2 cron scripts also works fine.
>>> >
>>> > I have been looking at a way to have @INC permanently have the path
>>> to where this 'path.pl' is located so that all I need to do is just
>>> call "&set_paths()". I read about this from this url
>>> >
>>> > http://perl.apache.org/docs/1.0/guide/porting.html#_INC_and_mod_perl
>>> >
>>> > However I'm not sure what configuration file they are talking about
>>> and also what is this startup.pl script located. It also appears that
>>> only the server administrator can do this. Is this right ?
>>> >
>>> > So for now I am with attempt 2 as I can run cron and browser called
>>> scripts.
>>> >
>>> > If anyone have some thoughts or a better solution on this please
>>> share them with me.
>>> >
>>> > Cheers.
>>> >
>>> >
>>> > --
>>> > SLUG - Sydney Linux User's Group - http://slug.org.au/
>>> > More Info: http://lists.slug.org.au/listinfo/slug
>>>
>>>
>>>
>>> --
>>> SLUG - Sydney Linux User's Group - http://slug.org.au/
>>> More Info: http://lists.slug.org.au/listinfo/slug
>>
>> --
>> Evolution: Taking care of those too stupid to take care of themselves.
>
>
> --
> I'm always learning something new everyday. Thanks Sluggers.
>
>
> --
> SLUG - Sydney Linux User's Group - http://slug.org.au/
> More Info: http://lists.slug.org.au/listinfo/slug


-- 
I'm always learning something new everyday. Thanks Sluggers.


-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Reply via email to