Absolute Path errors
Νίκος
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.
use...@davidfilmer.com
> 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.
--
The best way to get a good answer is to ask a good question.
David Filmer (http://DavidFilmer.com)
Νίκος
Ο/Η use...@DavidFilmer.com έγραψε:
> On Apr 9, 2:33 pm, "Νίκος" <hacke...@gmail.com> wrote:
>
> > 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.
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 )))),
use...@davidfilmer.com
> 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).
use...@davidfilmer.com
> 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.
Νίκος
Ο/Η use...@DavidFilmer.com έγραψε:
> On Apr 9, 2:59 pm, "Νίκος" <hacke...@gmail.com> wrote:
>
> > 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).
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
>> 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.
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, why cant it fid the files based on that ( /
>=3D "d:\www )
"/ 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.
>I dotn see why.
Because "this is I/O which is serviced directly by the operating
system".
>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=3D>'lime'}, a( {href=3D>'/cgi-bin/show.pl?
>name=3Dshowlog'}, h1( {class=3D>'lime'}, $host )))),
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".
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,
Νίκος
Ο/Η Michele Dondi έγραψε:
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 έγραψε:
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
>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?
Well, I'm by far not an expert in these matters but I can hardly see
how the webserver could actually serve files without... err... well...
opening them.
Michele Dondi
>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?
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.
Νίκος
Ο/Η Michele Dondi έγραψε:
> On 10 Apr 2007 03:55:10 -0700, "?????" <hack...@gmail.com> wrote:
>
> >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?
>
> 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 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
What effect does the latter operation create?
Νίκος
Ο/Η Michele Dondi έγραψε:
> On 10 Apr 2007 13:13:39 -0700, "?????" <hack...@gmail.com> wrote:
>
> >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
>
> 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.
Michele Dondi
>> >i only deleted the idnex.html file pointing to index.pl, that all and
>> >i set DirectoryIndex index.html cgi-bin/index.pl
>>
>> 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.
Well, and when cgi-bin/index.pl is executed, what do you think that
its cwd will be?
skieros
Ο/Η Michele Dondi έγραψε:
> On 10 Apr 2007 14:27:29 -0700, "?????" <hack...@gmail.com> wrote:
>
> >> >i only deleted the idnex.html file pointing to index.pl, that all and
> >> >i set DirectoryIndex index.html cgi-bin/index.pl
> >>
> >> 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.
>
> 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.
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
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.
>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!
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.
>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.
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."
skieros
Ο/Η Michele Dondi έγραψε:
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......
Michele Dondi
>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 =3D> cgi-bin/index.pl
>
>dam how did that redirection worked made apache open() files with just
>relative paths......
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.
José Luis Pérez Diez
> 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
>
I don't know how you redirected index.html, of Apache document root, to
,Apache current directory, cgi-bin/index.pl and what Apache select as
current directory for cgi-bin/index.pl to run.
> dam how did that redirection worked made apache open() files with just
> relative paths......
>
I don't cannot parse this last sentence
What happens in both cases can be known if index.pl informs of it's
current work directory
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.....
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.
Michele Dondi
>So although the path were relative Apache can locate them and Perl
>open() them with the use of the OS. No?!
I think you are still confusing URLs and paths. URLs are designed to
look somewhat like paths. This allows for easily transforming them, in
some cases, into actual paths. Think of the webserver as of an
interface: on the one side of it you have URLs, on the other one,
paths. There's no rule a priori that maps exactly one URL to a given
path and vice versa. 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.
Michele Dondi
>> 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.....
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.
skieros
Ο/Η Michele Dondi έγραψε:
> On 13 Apr 2007 02:00:24 -0700, "skieros" <niko...@gmail.com> 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?!
Peter J. Holzer
> 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.
Oh, it's perfectly reasonable - for a specific server in Poland :-).
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | h...@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
skieros
> On 2007-04-12 09:56, Michele Dondi <bik.m...@tiscalinet.it> wrote:
>
> > In particular the URL you expect for it does NOT make any sense, for
>
> Oh, it's perfectly reasonable - for a specific server in Poland :-).
how come? :)
Michele Dondi
>> Oh, it's perfectly reasonable - for a specific server in Poland :-).
>
>how come? :)
The tld for Poland is pl and index.pl is a valid hostname. It even
actually exists:
kirk:~ [19:05:27]$ host index.pl
index.pl has address 195.116.236.13
index.pl mail is handled by 40 alterratp.interkom.pl.
index.pl mail is handled by 10 mx.interkom.net.pl.
index.pl mail is handled by 10 mx.interkom.pl.
Tad McClellan
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
--
Tad McClellan SGML consulting
ta...@augustmail.com Perl programming
Fort Worth, Texas
skieros
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?
Michele Dondi
>Now that iam hosting my webpage on freehostia.com command like open
>FILE, "D:/www/data/text/tips.txt" or die $!;
Huh?!?
>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?
I'm most certainly *not* the best one to answer your question, but
use...@DavidFilmer.com 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.
skieros
> On 16 Apr 2007 05:40:05 -0700, "skieros" <niko...@gmail.com> wrote:
>
> >Now that iam hosting my webpage on freehostia.com command like open
> >FILE, "D:/www/data/text/tips.txt" or die $!;
>
> Huh?!?
>
> >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?
>
> I'm most certainly *not* the best one to answer your question, but
>
> use...@DavidFilmer.com 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 ?!
Michele Dondi
>> I'm most certainly *not* the best one to answer your question, but
>>
>> use...@DavidFilmer.com 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?
Did you try? What happened?
>open FILE, "$ENV{'DOCUMENT_ROOT'}www/data/text/tips.txt" or die $!;
Well, if 'www' is (one of) your document root(s) anyway, as seems
probable, then you don't want that in the path.
>my @files = glob "$ENV{'DOCUMENT_ROOT'}/data/text/*.txt";
To put it simply and briefly: I don't know. But as a side note, if you
really want to be picky, you may use File::Spec(::Functions)'s
catfile().
skieros
> On 16 Apr 2007 08:49:59 -0700, "skieros" <nikos1...@gmail.com> wrote:
>
> >> I'm most certainly *not* the best one to answer your question, but
>
> >> use...@DavidFilmer.com 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?
>
> Did you try? What happened?
>
> >open FILE, "$ENV{'DOCUMENT_ROOT'}www/data/text/tips.txt" or die $!;
>
> Well, if 'www' is (one of) your document root(s) anyway, as seems
> probable, then you don't want that in the path.
>
> >my @files = glob "$ENV{'DOCUMENT_ROOT'}/data/text/*.txt";
>
> To put it simply and briefly: I don't know. But as a side note, if you
> really want to be picky, you may use File::Spec(::Functions)'s
> catfile().
well here what hey responded me on free hostia.
Hello,
I am truly sorry to disappoint you but Access and Error logs service
in not available at this time. Our administrators are working to
enable it as soon as possible.
Best Regards,
Bob
and heer what i answered them:
2007-04-16 18:19:18 by nikkou6 to Technical Support
Well that really sucks!
Any other free hosting provider provides access to both of them.
Otherwise people will not know what wrong with their scripts.
But i guess thats all a trick to get us to pay for your hosting isnt?
So ill never be abel to see the access an s error logs.
Any other goog hostinf plans gys?
ill try the document root env var now in my localhost and tell you if
it works.
Michele Dondi
>> >Indeed but will something like this likely to work?
>>
>> Did you try? What happened?
>>
>> >open FILE, "$ENV{'DOCUMENT_ROOT'}www/data/text/tips.txt" or die $!;
>>
>> Well, if 'www' is (one of) your document root(s) anyway, as seems
>> probable, then you don't want that in the path.
>>
>> >my @files = glob "$ENV{'DOCUMENT_ROOT'}/data/text/*.txt";
>>
>> To put it simply and briefly: I don't know. But as a side note, if you
>> really want to be picky, you may use File::Spec(::Functions)'s
>> catfile().
>
>well here what hey responded me on free hostia.
>
>Hello,
>
>I am truly sorry to disappoint you but Access and Error logs service
>in not available at this time. Our administrators are working to
>enable it as soon as possible.
I'm sorry for you, honestly. But... the relevance of this should be?
use...@davidfilmer.com
> 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";
Here's an easy way for you to answer your own question. Cut-and-paste
this tiny little program into a file:
#!/usr/bin/perl
print "Content-type: text/plain\n\n";
printf "%-25s => %s\n", $_, $ENV{$_} for sort keys %ENV;
__END__
Save it with some name (perhaps env.cgi) in your cgi-bin, chmod it to
be executable, and now run it from a browser (http://yourdomain.com/
cgi-bin/env.cgi).
It will show you the webserver environment in which your Perl programs
are running (note that the output in a browser is COMPLETELY different
than the output you get if you run the program from a shell). Note
the value for DOCUMENT_ROOT (and note that it does not have a trailing
slash, so your first example could not work, but your second example
might work, depending on if the concatenation is valid).
--
The best way to get a good answer is to ask a good question.
David Filmer (http://DavidFilmer.com)
Tad McClellan
Scott Bryce
> skieros <niko...@gmail.com> wrote:
>
>
>
>>Any other goog hostinf plans gys?
>
>
>
> Huh?
I'm guessing that he is looking for a web host. That would be a question
for another newsgroup. Perhaps alt.www.webmaster?
Jürgen Exner
> But i guess thats all a trick to get us to pay for your hosting isnt?
> So ill never be abel to see the access an s error logs.
^^^ ^^^^ ^^^^
> Any other goog hostinf plans gys?
^^^^^^^^^^^^^^^^^^^^^^
> ill try the document root env var now in my localhost and tell you if
^^^
> it works.
Your postings are exceedingly difficult to read. While I understand that
English may not be your first language or that you may suffer from any
number of reading/writing impairments unfortunately that doesn't make your
articles any easier to decipher for the rest of us.
Luckily there is a very easy way to eliminate at least a large chunk of
misspellings and typos: just run your text through a spell checker before
hitting the send button. It won't resolve 100% of issues, but probably catch
90% or so and that would be a VERY MAJOR improvement.
jue
skieros
I never uses a spell checker before, but ill try it if you tell me
one, iam posting this through browser on grous.google.is there an
online check before i hit send maybe? that would be very convinient
Well sorry for my posts but ysterday i accidentally spit all coffe to
keyboard anbd wasnt even be able to hist space button. keyborad typed
also on its own ue to stickness.
All worked!! it ried it myself before eeing your ansers.
my @tips;
open FILE, "<$ENV{'DOCUMENT_ROOT'}/data/text/tips.txt" or die $!;
@tips = <FILE>;
close FILE;
works fine!
and also
my @files = glob "$ENV{'DOCUMENT_ROOT'}/data/text/*.txt"; #worked fine
and also this!
#===============================================================================
my $db = ( $ENV{'SERVER_NAME'} !~ /freehostia/ )
? DBI->connect('DBI:mysql:nikos_db', 'root', '********',
{RaiseError=>1})
: DBI->connect('DBI:mysql:nikkou6_db:mysql3.freehostia.com',
'nikkou6_db', '********', {RaiseError=>1});
#===============================================================================
#========================= CREATE DATABASE AND TABLES
==========================
my $dbname='nikos_db' if( $ENV{'SERVER_NAME'} !~ /freehostia/ ) or my
$dbname='nikkou6_db';
$db->do( "DROP DATABASE IF EXISTS $dbname" );
$db->do( "CREATE DATABASE $dbname" );
$db->do( "USE $dbname" );
EVERYTHING WORKED!
FUNNY THING WAS THAT I HAD TO copy/paste <space> and other chars as
well and delete everythign the keyboard wrote by it self!!