Absolute Path errors

Í

Íßêïò

Tonigth i chnages the scheme of my perl webpage

instead of having index.html redirect to cgi-bin\index.pl

i set in httpd.conf DirectoryIndex index.html cgi-bin/index.pl

but all links to other ple scripts inside my index.pl not workign any
more cause thye y were relative.

Then i changed them alla links to files an folders to absolute
startinf with a leading / (d:\www which is my DocumentRoor)

Now script can work but

but statements like :

my @files = glob "/data/text/*.txt";

and

my @tips;
open FILE, "/data/text/tips.txt" or die $!;
@tips = <FILE>;
close FILE;

arent opening files or loading them into arrays.

The paths though to files ae correct.

I just dont see the error.
 
U

usenet

open FILE, "/data/text/tips.txt" or die $!;

This is I/O which is serviced directly by the operating system, not
the webserver. You must specify the full path as known by the OS
(including the path to your document root, if that's where the stuff
is), not a full or relative path as known only to your webserver.
 
Í

Íßêïò

Ï/Ç (e-mail address removed) Ýãñáøå:
This is I/O which is serviced directly by the operating system, not
the webserver. You must specify the full path as known by the OS
(including the path to your document root, if that's where the stuff
is), not a full or relative path as known only to your webserver.

But why? The Webserver is supposed to identify both relative and
absolute paths.

/ stands for DocumentRoot, why cant it fid the files based on that ( /
= "d:\www )

I dotn see why.

nd also hw come it wont open files or load arrasy with files but be
able to perform the following line ?
the following line is also an absolute path based on document root and
it does work!

Tr( td( {class=>'lime'}, a( {href=>'/cgi-bin/show.pl?
name=showlog'}, h1( {class=>'lime'}, $host )))),
 
U

usenet

But why? The Webserver is supposed to identify both relative and
absolute paths.

I'll say it again: the webserver is NOT servicing your file I/O.
This is being serviced directly by the operating system.

If you have a link to a document and the client clicks on the link,
the webserver will service the request and go looking for the document
(and THEN your document root matters).

But the webserver is not involved when you do file I/O directly inside
your Perl program. It does not matter that the webserver initiated the
Perl program. Perl knows nothing about your webserver (and Perl has
no idea your webserver invoked the program), and your webserver is not
involved in anything that happens inside your Perl program (your Perl
program is a 'black box' as far as your webserver is concerned).

This is why you can invoke a Perl CGI from a commandline and it will
work just as if you launched it from a browser (you can even pass HTML
parameters to the Perl program). You don't even need to have a
webserver *installed* for your Perl CGI's to work perfectly - you can
write, run, and debug Perl CGI programs on ANY machine (even without a
webserver, and which has no concept of a 'document root') and then
upload them to your webserver (lots of folks do that).
 
U

usenet

Perl knows nothing about your webserver (and Perl has
no idea your webserver invoked the program)

I should mention, though - even though Perl knows nothing about your
webserver, your webserver will set certain environment variables prior
to invoking the Perl program. These don't affect the behavior of Perl
in any way, but you have access to them and you may use them if you
wish.

Some webservers will set $ENV{'DOCUMENT_ROOT'} which you may use
within your Perl program. But you must explicitly code this; Perl
will not make any use of this variable unless you specifically code it
yourself.
 
Í

Íßêïò

Ï/Ç (e-mail address removed) Ýãñáøå:
I'll say it again: the webserver is NOT servicing your file I/O.
This is being serviced directly by the operating system.

If you have a link to a document and the client clicks on the link,
the webserver will service the request and go looking for the document
(and THEN your document root matters).

But the webserver is not involved when you do file I/O directly inside
your Perl program. It does not matter that the webserver initiated the
Perl program. Perl knows nothing about your webserver (and Perl has
no idea your webserver invoked the program), and your webserver is not
involved in anything that happens inside your Perl program (your Perl
program is a 'black box' as far as your webserver is concerned).

So basically youa re saying that linking fro one cgi to another is
handled by the web server but opening/writing is handled by the OS.
ok.

But is nt it strange but the same commands used to work without full
hdd paths in the past, until yesterday which i deleted the index.html
that was pointing to index.pl?

How come then the webserver was able to handle those I/O requests and
executed the properly?

i had it like this: cleint request => index.html (d:\www) => index.pl
(d:\www\cgi-bin) and it was working ok.

Things changes when i deleted the redirection filer and set
DirectoryIndex index.html cgi-bin/index.pl
 
Í

Íßêïò

Ï/Ç Michele Dondi Ýãñáøå:
Because "this is I/O which is serviced directly by the operating
system".

Webserver ne OS. If you feel like that and have the expertise to, then
go write a kernel extention that will allow you to have a closer
interaction between them. But I don't think there's much a need for
such a thing around...


"/ stands for DocumentRoot" for the webserver. Thus IT (i.e. the
webserver) CAN "find the files based on that". The OS can't, because
it's NOT the webserver.


Because "this is I/O which is serviced directly by the operating
system".


This "line does work" because the only I/O handled by the OS amounts
to printing some strings. These strings will eventually reach one's
browser (a client) and the latter will issue a suitable GET to the
webserver, and IT (i.e. the webserver, now) CAN "find the files based
on that".

i see. so the webserver can only redirect to files and link to them,
in general only find them based on DocumentRoor but not open them or
wite to them in the same manner. only the os can do that cause I/O is
specifically designed to be performed by the OS. Aapche only find
files, not open them right?
 
Í

Íßêïò

Ï/Ç Michele Dondi Ýãñáøå:
Because "this is I/O which is serviced directly by the operating
system".

Webserver ne OS. If you feel like that and have the expertise to, then
go write a kernel extention that will allow you to have a closer
interaction between them. But I don't think there's much a need for
such a thing around...


"/ stands for DocumentRoot" for the webserver. Thus IT (i.e. the
webserver) CAN "find the files based on that". The OS can't, because
it's NOT the webserver.


Because "this is I/O which is serviced directly by the operating
system".


This "line does work" because the only I/O handled by the OS amounts
to printing some strings. These strings will eventually reach one's
browser (a client) and the latter will issue a suitable GET to the
webserver, and IT (i.e. the webserver, now) CAN "find the files based
on that".

Yes but when i used to sue the index.html pointing to index.pl all
paths i ahd were relative and all I/O functions like fillign an @array
with files or opening files used to work with, could be opened and
edited without me having to descrivr the full hdd locations.

How was that possible back then?
 
Í

Íßêïò

Ï/Ç Michele Dondi Ýãñáøå:
Apparently there was a 1 to 1 mapping between local paths and urls
that gave you the impression you could *generally* use them in a
completely intechangeable manner, which is not the case.

What do you mean by 1 to 1 mapping and what made ti change now?!

i only deleted the idnex.html file pointing to index.pl, that all and
i set DirectoryIndex index.html cgi-bin/index.pl
 
Í

Íßêïò

Ï/Ç Michele Dondi Ýãñáøå:
What effect does the latter operation create?

When a user asks for a webserver directory apache sees iftf there is
an index.html file there first, if its not it serves cgi-bin/index.pl
if it cant find it then it gives a dirr index.
 
S

skieros

Ï/Ç Michele Dondi Ýãñáøå:
Well, and when cgi-bin/index.pl is executed, what do you think that
its cwd will be?

it will be cgi-bin

when index.pl is executed and it passes form data to show.pl print
$ENV{HTTP_REFERRER} which i use in show.pl will say http://localhost
instead of http://index.pl, and i still dotn get that!

index.pl send form data to show.pl so the referes should be index.pl
not document root.

why ti beaves like that? before that i had the index.html redirection
it uses to work ok.
 
S

skieros

Ï/Ç Michele Dondi Ýãñáøå:
Ok, now the answer is staring in front of you: if you open() a file
with a relative path, that will be relative to cgi-bin, NOT its parent
directory.


You're still confusing two things that stay on opposite sides of a
wall, that have traits resembling each other, but which are in fact
completely different things. $ENV{HTTP_REFERRER} is a networking,
http-related, thing and a priori it has nothing to do with your local
filesystem.

In particular the URL you expect for it does NOT make any sense, for
http://index.pl is not a reasonable URL in any way.


I'll try to explain again in my own words, which may be technically
inexact for as I said I'm not an expert in these matters: the
webserver has some rules to map some URLS it gets requested into files
to serve or programs to execute, which will spit out some valid
content to serve. The CGI protocol establishes the communication
between the webserver itself and the called program, but the latter is
not aware in any way of the tricks the former performs. Well, to be
fair, as someone explained, actually the webserbver passes along info
that *can be used* to understand them, but you have to do so yourself:
it's NOT an authomatic thing. (And personally I fail to see why/how it
could.)

I know it is frustrating not to understand the real reason behind
something that puzzles you, but if you still don't get it, I recommend
not to worry and for the time being to just accept it along the lines
of "because it's like that, period."

thanks ill just try to forget about it.....

i can understand it now as explained and why ti works with abosulte
hhd path but fail to see how it *used to work* back then when i
redirected from /index.html => cgi-bin/index.pl

dam how did that redirection worked made apache open() files with just
relative paths......
 
S

skieros

Ï/Ç Michele Dondi Ýãñáøå:
One last (really, eh!) try: it's Perl, not apache that does the
open()s and previously by a pure chance the relative urls were
corresponding to the correct relative paths. But generally this is in
fact a circumstance.

Yes it is Perl that handle the open() requests as by its turn it gives
the open() requests to OS to control and handle
but its Apache that locates its files(only locates and handle links)
that is in fact residing to a subdir of the webserver's DocumentRoot.

So although the path were relative Apache can locate them and Perl
open() them with the use of the OS. No?!

If you want tou can answer, i know i tired you with this matter.....
 
S

skieros

Ο/Η José Luis Pérez Diez έγÏαψε:
What happens in both cases can be known if index.pl informs of it's
current work directory

Yes, maybe...

Because i cannot else explain how Apache could locate all files for
opening with the redirection method and after removed the redirection
it couldnt.....

If it could in the first place it can locate them and i can use them
with relative apth only.
 
S

skieros

Ï/Ç Michele Dondi Ýãñáøå:
On 13 Apr 2007 02:00:24 -0700, "skieros" <[email protected]> wrote:
When a given URL points to a page that is
actually dinamically generated by a program it *can happen* that an
URL relative to that base URL can also be used *verbatim* as a
relative path with respect to that particular program. This is exactly
what you had in the first case. But it's *not* generally the case.

I am beginning to see the ligt now... le tme see....

look my index.html that si residing ti d:\www (DocumentRoot)

<html>
<body>
<script language=javascript>
location.href='/cgi-bin/index.pl'
</script>
</body>
</html>

As cou can see it redirect to index.pl inside cgi-bin

What you mean is that all relative paths i though that its cwd was /
and not /cgi-bin because of the index.html that run first and then
gave control to index.pl?!
 
T

Tad McClellan

skieros said:
how come? :)


perl -MWWW::Mechanize -e "print WWW::Mechanize->new->head('http://index.pl')->as_string"

HTTP/1.1 200 OK
Connection: close
Date: Sun, 15 Apr 2007 19:30:24 GMT
Accept-Ranges: bytes
ETag: "1399f-38-848e3c80"
Server: Apache/2.0.47 (Debian GNU/Linux) mod_ssl/2.0.47 OpenSSL/0.9.6c
Content-Length: 56
Content-Type: text/html
Last-Modified: Tue, 27 Jul 2004 14:00:02 GMT
Client-Date: Sun, 15 Apr 2007 20:30:19 GMT
Client-Peer: 195.116.236.13:80
Client-Response-Num: 1
 
S

skieros

Yes, maybe...
Because i cannot else explain how Apache could locate all files for
opening with the redirection method and after removed the redirection
it couldnt.....

To put it briefly: COINCIDENCE!
If it could in the first place it can locate them and i can use them
with relative apth only.

You can still use relative paths, provided you massage them a little
as duly explained by another poster. That would only require a
negligible amount of effort.

Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

Now that iam hosting my webpage on freehostia.com command like open
FILE, "D:/www/data/text/tips.txt" or die $!;

So, i will eb definately be needing a way to oepn those files not in
absolute hdd way but soemthing like open FILE, /data/text/tips.txt or
die $!;

How will i be abel to accomplish that?
 
S

skieros

I'm most certainly *not* the best one to answer your question, but

(e-mail address removed) wrote:

: Some webservers will set $ENV{'DOCUMENT_ROOT'} which you may use
: within your Perl program. But you must explicitly code this; Perl
: will not make any use of this variable unless you specifically code it
: yourself.

That may just be what you want/need.

Indeed but will something like this likely to work?


open FILE, "$ENV{'DOCUMENT_ROOT'}www/data/text/tips.txt" or die $!;

or

my @files = glob "$ENV{'DOCUMENT_ROOT'}/data/text/*.txt";

I mean if its for openign a link/pointing current script to another
perl file this will work fine but what about when tryign to open a
file for reading/writing ?!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top