Hello Horseradish,
Based on your question, I will assume you are familiar with software
development but a novice with using Perl. As a result, each statement
will be explained in some detail. If this is still unclear or if this
does not meet your needs - be sure to ask for clarification of the
answer.
Getting from
print "$content".html;
to something like
$content .= ".html"
open(INFILE, $content);
while (<INFILE>) {
print $_;
}
can be somewhat confusing. However, this can be derived with the
resources listed below. First, i suggest you review
http://www.perldoc.com/perl5.8.0/pod/perlintro.html#Files-and-I-O
which has an excellent summary of the basic capabilities of Perl. This
URL will take you directly to the Files and I/O section, but I suggest
you review the rest of the page when you get a chance.
To access a file, you must first "open" it. The first statement shown
appends ".html" to the string provided in $content. The second
statement will then open that file, creating the "file handle"
<INFILE> to reference later in the code.
This code above does not check to see if the file exists - if you need
to add error handling, check the examples in
http://www.perldoc.com/perl5.8.0/pod/func/open.html
which has a number of examples with "or die" phrases added to generate
a meaningful error message. I would try the simple version first and
add the error handling as you gain confidence in using Perl.
The while clause
while (<INFILE>) {
print $_;
}
is a compromise between simplicity and efficiency. Each line of
<INFILE> is loaded into $_, the "default variable" each time you go
through the while loop. The print statement within the loop will then
print each line read from <INFILE>. The loop terminates when the end
of file is reached. There are other ways to do this that appear to be
simpler - but they can consume a lot of memory.
Note that with this structure, you can make minor (or major) changes
to the lines read from <INFILE> within the loop. For example, if you
want to nest include files - there is an incomplete example in the
open reference
http://www.perldoc.com/perl5.8.0/pod/func/open.html
about half way down - look for "sub process" if you are interested.
Replace the line with "whatever" with the print statement.
Unless you want to manipulate the $content file, that should be all
you need. The input file will be closed automatically when you open
another file or when Perl exits.
To find this and related information, I suggest search phrases such
as:
perl language manual
perl input output file
perl cgi file
perl cgi tutorial
or add / replace a few phrases to get focused on other topics.
Good luck with your site. If you need additional information related
to this question or some part of the answer is still unclear - don't
hesitate to ask for clarification.
--Maniac |
Request for Answer Clarification by
horseradish-ga
on
09 Sep 2003 16:19 PDT
Thank you so much for this full answer. I'm afraid I just haven't had
a second to try this out but will do with the next 24 hours and will
get back to you asap. Sorry for the delay!
|
Clarification of Answer by
maniac-ga
on
09 Sep 2003 16:58 PDT
Hello Horseradish,
Glad to help.
Don't rush - it is better understand how this works and get it right
instead of stabbing in the dark over and over again. When you get time
to work on it and something is not quite right, don't hesitate to ask
for a clarification.
--Maniac
|
Request for Answer Clarification by
horseradish-ga
on
10 Sep 2003 14:07 PDT
Whee-hee it WORKS! It's so great when it comes together isn't it?
Thanks very much. Though you did try to trick me by leaving a
semicolon off the end of the first line :-)
Just one last little thing, if you don't mind. This line :
$content .= ".html";
causes the perl script to look for $content within the cgi-bin. I'd be
really grateful if you could advise on the correct syntax for adding a
slash to the front so it looks outside the cgi-bin. I tried this:
$content = "/."$content".html";
but that didn't work.
Thanks so much for your help. Not only does it work but I understand
how it works too. Brilliant!
|
Clarification of Answer by
maniac-ga
on
10 Sep 2003 16:00 PDT
Hello Horseradish,
Hmm. Making the string
$content=="main"
converted to
$content=="/main.html"
is pretty straight forward. Using
http://www.perldoc.com/perl5.8.0/pod/perlintro.html#Builtin-operators-and-functions
and scrolling down to the description of built in operator and
functions (string concatenation is the period (.) operator) leads me
to try
$content = "/".$content.".html";
or
$content = "/".$content;
$content .= ".html";
The first is really close to what you had in your request for
clarification. The second makes a minimal change to what was already
provided. Either should work.
As a side note - if you are using a Unix (or Linux) system, you should
be able to test simple examples like this using a command line like
perl -e 'print "/"."main".".html\n";'
which prints
/main.html
on my machine (and more helpfully prints no error messages).
As a final note - this *may* not work the way you expect - that can
depend upon your web server set up. For example, on some systems you
can put the web server into a "jail" or "chroot" environment where it
cannot access files outside of a limited area. In that case, "/" may
refer to the top of the web server directory and not the "/" of the
overall system. Keep this in mind when you test these changes.
--Maniac
|
Request for Answer Clarification by
horseradish-ga
on
11 Sep 2003 05:30 PDT
Well that all makes sense, and it certainly works in getting the
correct value into the $content - as I tested it with a print
statement as you advised. However, when I run it, it doesn't pull the
page in any more. In fact when I view the source of the resulting page
I find that the code stops altogether at the point where the other doc
was meant to be pulled in, there's no closing body or html tags even.
I tried to locate something to check the perl script. I'm running OSX
on a Mac and apparently it come with something but I've no idea what
that is or how to run it.
Apologies for keeping this going on, would really appreciate any
further advice you'd care to share.
This is what I have:
$content = "/".$content.".html";
print $content; <!--this DOES print the correct value-->
open(INFILE, $content) or die "Can't open file: $!";
while (<INFILE>) {
print $_;
}
You can see it in (non) action at
http://www.redjam.com/cgi-bin/templatex.cgi?content=home2
You can see the simpler version, that calls the doc from within the
cgi folder, working at
http://www.redjam.com/cgi-bin/templatey.cgi?content=home
THANK YOU!!
Thanks very much
|
Clarification of Answer by
maniac-ga
on
11 Sep 2003 06:59 PDT
Hello Horseradish,
This problem gets back to where "/" is. The root directory (/) on a
Unix system (including Mac OS X) is at the top of the tree of
directories. For example, on my Mac OS X system I have directories
like...
/ - the root directory
/etc/httpd - a directory containing configuration files for the web
server
/usr/bin - a directory containing a number of system utility
programs
/Users/maniac - my "home directory" when I log into the system
/Volumes/A/Users/maniac - an old home directory on another disk
named A
and so on. The root directory is also not the same as your desktop
directory - that is somewhere else and is stored on a per user basis.
When you use
/main.html
as a file name, that refers to a file named main.html in the root
directory. This is not necessarily the top level directory of the web
server defined in the configuration file, usually at
/etc/httpd/httpd.conf
or
/etc/httpd/conf/httpd.conf
That is why I made the "final note" in the last clarification. The
string you may need to use would be something like
/var/www/html/main.html
if the "DocumentRoot" directory in the httpd configuration file has
the web pages stored there.
--Maniac
|
Request for Answer Clarification by
horseradish-ga
on
11 Sep 2003 07:39 PDT
Sorry, I should have mentioned, I also tried
$content = "http://www.mysite.com/files/".$content.".html";
which correctly assigns the full URL of the page to $content, but that
causes the same problem - with the html code cutting off at that
point. It should definitely work with the full URL like this shouldn't
it?
Thanks again :-)
|
Clarification of Answer by
maniac-ga
on
11 Sep 2003 11:12 PDT
Hello Horseradish,
In short - no. The longer reason is that Perl does not use URL's in
file I/O. Perl uses the filenames supported by the operating system
(in this case Unix) to open a file.
I'll be back in front of my machine at home within 6 hours. Let me
check out the default install locations for Apache and get back with
what should be the correct location to store the "main.html" file and
the pathname for that location to put into the perl script. I'll also
do a little research to see if there is some environment variable
defined when the cgi script is run so you can get the "right answer"
without hard coding it.
--Maniac
|
Request for Answer Clarification by
horseradish-ga
on
11 Sep 2003 14:39 PDT
Ohhh I see! Thanks for taking the time to clarify this for me.
When I log in to ftp, I get four directories:
cgi, files, logs, web. All my web pages for this project are stored in
web/new/
but I don't need to put 'web' in the URL - it seems to be the default
and I can get to them by http://www.mysite.com/new/page.html
Does this help at all?
It's very kind of you to go this extra distance for me on this, and
your help is really much appreciated. Thank you once again :-)
|
Clarification of Answer by
maniac-ga
on
11 Sep 2003 15:44 PDT
Hello Horseradish,
OK. It appears the default location for web pages on a Mac OS X system
is
/Library/WebServer/Documents
If I look in that folder using the finder I see a list of files
including about 30 versions of index.html (by language), a pair of
"Powered by Mac OS X" images and a few miscellaneous items.
So - if you drop your web pages there, the generated path should be
something like
/Library/WebServices/Documents/main.html
in the Perl script.
If this work - you should be able to fix the script to use absolute
paths to get to the files you need. If not, please try one of the
search methods listed below.
As to how I figured this out, I did the following.
[1] Started a "Terminal" application (using the finder, go to Mac HD
-> Applications -> Utilities -> Terminal).
You should get output like.
Last login: Sun Aug 31 18:42:16 on console
Welcome to Darwin!
[Maniacs-Computer:~] maniac%
with the computer name and your user name replaced by the appropriate
values.
[2] Enter
more /etc/httpd/httpd.conf
"more" is a program which will show the file contents a page at a
time. Use the space key (or arrow keys) to go through the file until
you see a line starting with DocumentRoot. It is a little over a third
of the way into this file.
On my system, the line reads
DocumentRoot "/Library/WebServer/Documents"
which is the value I indicated above. Enter the letter "q" to quit
more.
Now, there is another method that you can use to find the file. You
can search for the file by name. From that same terminal window, you
can enter
find / -name "main.html" -print
which will run a Unix utility named "find" to walk through each
directory, searching for files with that name and printing them out.
You may get a number of "permission denied" messages - just ignore
them. The correct output will look like the string you need to use in
Perl to open the file. On my system I have one at:
/Volumes/B/Previous System Folder/Help/MacTelnet Help/main.html
but I doubt that is where your files would be.
You could also use the finder "Find" command, but the format is
graphical in form which would have to be translated into the "slash
form" used by Unix.
--Maniac
|
Request for Answer Clarification by
horseradish-ga
on
12 Sep 2003 01:16 PDT
OK I'm perhaps getting a little lost here... why would I need to know
where the page was on my Mac OS X system? Surely the cgi isn't meant
to look for the file on my own computer - instead it's looking for it
on the server?
Is it because it works the same way in Mac OS X as in the Unix on the
server? So whatever the path is on my computer, it should be the same
for when it's uploaded?
Sorry, and thanks again... :-)
|
Clarification of Answer by
maniac-ga
on
12 Sep 2003 04:52 PDT
Hello Horseradish,
Ah - now it becomes a little more clear. It was the clarification
request that said...
I tried to locate something to check the perl script. I'm running
OSX on a Mac and apparently it come with something but I've no
idea what that is or how to run it.
led me to believe your web server was on a Mac but this last request
says
...Unix on the server.
Perhaps you could say what type of Unix system you are using and the
name of the web server software (Apache?).
There are some slight variations depending on the type of Unix system,
but the commands / directory locations on a "Unix server" are
generally the same. For example,
- the web server configuration file is still likely
/etc/httpd/httpd.conf
- utilities such as find and more should still work, though you would
need to login on the server to search the server's files (not your
Mac's files).
The web server files may be in
/var/httpd
or a similar location. I would still suggest reviewing the contents of
httpd.conf or using
find / -name "main.html" -print
to locate where you are uploading the web pages onto the server.
--Maniac
|
Request for Answer Clarification by
horseradish-ga
on
12 Sep 2003 06:21 PDT
Yes, sorry I wondered if we were heading down the wrong path
(literally) there!
Just to clarify - I don't run the server, it's a regular service I pay
for from a company called xo.com. They run Solaris on Unix.
I will see if I can get any of the other bits to work, though I will
need to log on to the server, as you say. Can I do that from the
Terminal app too?
I'm so sorry, I thought this 'little thing' would be very simple,
seems it's actually the most difficult part of the question! Will make
sure you get 5 stars and a tip :-)
|
Clarification of Answer by
maniac-ga
on
12 Sep 2003 11:19 PDT
Hello Horseradish,
OK - a managed service. That may make part of the answer easier but
maybe not. I checked XO's on line help - that was not very helpful -
apparently you need a username / password to access the interesting
parts. Their search appears to be broken as well [sigh].
I suggest you call (or email) their customer support staff to find out
the path to be used by cgi-bin scripts to access the top level
directory of your web pages?
The answer to this may also be buried in one of the example scripts
they say they make available - I can't be sure.
Either way you would not have to guess and that would remove the need
to login to the server.
With respect to logging into the server, you would need a "shell
account" (I am not sure you have one) on the server. Depending on the
set up, you could bring up the Terminal application and then
ssh -l "your username here" "server host name here"
and enter your password to get access to the shell on the server.
"ssh" stands for "secure shell" which sends all the data encrypted and
has some other safety measures to prevent disclosure of sensitive data
(such as passwords). You could then run the find command and review
other information as needed.
--Maniac
|
,
0 Comments
)