Difference between a .cgi file and a .pl file?
DS
Can I convert a .pl to a .cgi?
Thanks
Dirk
fvi...@my-deja.com
The difference between a .cgi and .pl file is really not the issue you
are probably facing. .cgi and .pl are simply file extensions that tell
your web server how to deal with that particular file. On almost all web
servers there is a "cgi-bin" directory. The web server treats all files
in this directory as executables. Web servers can also be configured to
recognize files as executables even when they are not in the "cgi-bin"
directory. When this option is turned on the default for the server is
to treat files ending in .cgi as executables. This however can be
extended to include .pl or .exe or .bucky for all the server cares. It
just wants to know what to try to execute. Making that file executable
is up to you. And yes you can simply change the name of a file from
something.pl to somthing.cgi. This will only cause problems if the
executable itself or other resources expect to find it named something.pl
In article <vjmc5.94$L5....@typhoon.kc.rr.com>,
Sent via Deja.com http://www.deja.com/
Before you buy.
Joe Kline
DS wrote:
> What is the diference betweeen a .pl file and a .cgi file?
> Can I convert a .pl to a .cgi?
Depends upon how your web-server is configured (whether it uses file
extension and/or specific dirs for CGI files).
As for converting them...depends. Do they have the proper format to
support CGI protocols?
--
Joe Kline
It takes a lot of brains to enjoy satire, humor, and wit;
but none to be offended by them. ---The Midnight Skulker
Bart Lateur
>What is the diference betweeen a .pl file and a .cgi file?
>Can I convert a .pl to a .cgi?
If in Perl, both are the same. It depends on the servcer configuration
whether they are truely interchangable.
But a CGI script can be written in one of many languages. So a .cgi file
needn't actually have been written in Perl.
--
Bart.
Hero
the extensions...then you decide the extension, so to convert the file,
just change the extension...
DS wrote:
> What is the diference betweeen a .pl file and a .cgi file?
> Can I convert a .pl to a .cgi?
>
> Thanks
> Dirk
fvision@my-deja.com.bbs@openbazaar.net
The difference between a .cgi and .pl file is really not the issue you
are probably facing. .cgi and .pl are simply file extensions that tell
your web server how to deal with that particular file. On almost all web
servers there is a "cgi-bin" directory. The web server treats all files
in this directory as executables. Web servers can also be configured to
recognize files as executables even when they are not in the "cgi-bin"
directory. When this option is turned on the default for the server is
to treat files ending in .cgi as executables. This however can be
extended to include .pl or .exe or .bucky for all the server cares. It
just wants to know what to try to execute. Making that file executable
is up to you. And yes you can simply change the name of a file from
something.pl to somthing.cgi. This will only cause problems if the
executable itself or other resources expect to find it named something.pl
In article <vjmc5.94$L5....@typhoon.kc.rr.com>,
"DS" <snak...@kc.rr.com> wrote:
> What is the diference betweeen a .pl file and a .cgi file?
> Can I convert a .pl to a .cgi?
>
> Thanks
> Dirk
>
>
DS
Bart Lateur
>What is the diference betweeen a .pl file and a .cgi file?
>Can I convert a .pl to a .cgi?
If in Perl, both are the same. It depends on the servcer configuration
Hero
the extensions...then you decide the extension, so to convert the file,
just change the extension...
DS wrote:
> What is the diference betweeen a .pl file and a .cgi file?
> Can I convert a .pl to a .cgi?
>
> Thanks
> Dirk
Jürgen Exner
news:vjmc5.94$L5....@typhoon.kc.rr.com...
> What is the diference betweeen a .pl file and a .cgi file?
The file extension?
> Can I convert a .pl to a .cgi?
'mv foobar.pl foobar.cgi' should do the job.
But maybe you wanted to ask what is the difference between a Perl file and a
CGI file?
Let's just say they have little in common. Many, many Perl programs are used
without any relation to CGI and CGI files can be programmed in any language,
Perl just being one among many.
jue
Alon Rachamim
language and .pl is for Perl only
DS <snak...@kc.rr.com> wrote in message
news:vjmc5.94$L5....@typhoon.kc.rr.com...
> What is the diference betweeen a .pl file and a .cgi file?
> Can I convert a .pl to a .cgi?
>
>
> Thanks
> Dirk
>
>
Abigail
<URL:news:vjmc5.94$L5....@typhoon.kc.rr.com>:
][ What is the diference betweeen a .pl file and a .cgi file?
The name.
][ Can I convert a .pl to a .cgi?
Sure. Rename the file.
Abigail
--
perl -e '$a = q 94a75737420616e6f74686572205065726c204861636b65720a9 and
${qq$\x5F$} = q 97265646f9 and s g..g;
qq e\x63\x68\x72\x20\x30\x78$&eggee;
{eval if $a =~ s e..eqq qprint chr 0x$& and \x71\x20\x71\x71qeexcess}'
Jürgen Exner
The file extension?
> Can I convert a .pl to a .cgi?
'mv foobar.pl foobar.cgi' should do the job.
Alon Rachamim
language and .pl is for Perl only
DS <snak...@kc.rr.com> wrote in message
news:vjmc5.94$L5....@typhoon.kc.rr.com...
> What is the diference betweeen a .pl file and a .cgi file?
> Can I convert a .pl to a .cgi?
>
>
> Thanks
> Dirk
>
>
Abigail
Peter Sundstrom
Alon Rachamim wrote in message <3973...@news.bezeqint.net>...
> I think and for what I tested no difrence only .cgi can be for other
script
> language and .pl is for Perl only
I can call my Perl script foo.fred or foo.java or foo.c and it will still be
a Perl script.
Joe Kline
> <SNIP>
> But maybe you wanted to ask what is the difference between a Perl file and a
> CGI file?
> <SNIP>
> Perl just being one among many.
For some odd reason I had a flashback to "Full Metal Jacket":
This my Perl script this is my CGI.
One is for fightin' one is for fun.
---
(With sincerest apologies to the Marine Corps and the Rifle Creed)
This is my Perl. There are many like it, but this one is mine.
My Perl is my best friend. It is my life. I must master it as I must master my
life.
My Perl, without me is useless. Without my Perl, I am useless. I must code my
perl true. I must code before the Bill shoots me. I will...
My Perl and myself know that what counts in this war is not the lines we code,
the noise of our line, nor the obfuscation we make. We know that it is the code
that counts. We will code...
My Perl is pure, even as I, because it is my life. Thus, I will learn it as a
brother. I will learn its weaknesses, its strengths, its parts, its
accessories, its JAPHs, and its one-liners. I will ever guard it against the
ravages of Bill and VB. I will keep my Perl clean and ready, even as I am clean
and ready. We will become part of each other. We will...
Before Larry I swear this creed. My Perl and myself are the defenders of my
Three Virtues. We are the masters of our enemy. We are the saviors of my life.
So be it, until victory is Perl's and there is no enemy, but Users!
Hey, I just finished watching "Evil Dead II" after a full day of tutorials...
Villy Kruse
>DS (snak...@kc.rr.com) wrote on MMDXI September MCMXCIII in
><URL:news:vjmc5.94$L5....@typhoon.kc.rr.com>:
>][ What is the diference betweeen a .pl file and a .cgi file?
>
>The name.
>
>][ Can I convert a .pl to a .cgi?
>
>Sure. Rename the file.
>
>
>
Correct.
In some systems the extensions are magic, so a perl script is recognized
as such only based on the suffix.
On unix systems in general the suffix on executables is not used for any
purpuse; the '#!' line does that. And if you install CGI programs in
a dedicated cig-bin directory, the web server doesn't care either.
Villy
Peter Sundstrom
Villy Kruse
turnere
v...@pharmnl.ohout.pharmapartners.nl.bbs@openbazaar.net (Villy Kruse)
wrote:
What if the Apache conf file has this directive?:
AddHandler cgi-script .pl
If you change to .cgi your scripts may not work properly.
Andy Bridges
executed as a .cgi file extension.
you will normally find that this happens on older style webservers , most of
the newer webservers ( apache ) accept both .pl and .cgi file extensions.
just to make sure everyone knows this for future reference ;)
"DS" <snak...@kc.rr.com> wrote in message
news:vjmc5.94$L5....@typhoon.kc.rr.com...
> What is the diference betweeen a .pl file and a .cgi file?
> Can I convert a .pl to a .cgi?
>
>
> Thanks
> Dirk
>
>
Randal L. Schwartz
Andy> the difference is that some servers will only allow a perl
Andy> script to be executed as a .cgi file extension.
Andy> you will normally find that this happens on older style
Andy> webservers , most of the newer webservers ( apache ) accept both
Andy> .pl and .cgi file extensions.
But even that's still wrong. I don't think I've ever written a CGI
program, in Perl or otherwise, that had to have a required extension.
Since the very first release of Apache (and all of the releases of the
NCSA server from which Apache was derived), a CGI script was
recognized by its leading path, not its extension.
Only in recent versions of Apache have you also been able to add CGI
recognized "anywhere" using an extension, which to me seems to be a
Very Bad Idea from a security perspective, intermingling data and code
much too closely for comfort, not to mention revealing the
implementation language to outsiders making systematic attack easier.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Abigail
MCMXCIII in <URL:news:m1wvi2w...@halfdome.holdit.com>:
$$ >>>>> "Andy" == Andy Bridges <abri...@eurobell.co.uk> writes:
$$
$$ Andy> the difference is that some servers will only allow a perl
$$ Andy> script to be executed as a .cgi file extension.
$$
$$ Andy> you will normally find that this happens on older style
$$ Andy> webservers , most of the newer webservers ( apache ) accept both
$$ Andy> .pl and .cgi file extensions.
$$
$$ But even that's still wrong. I don't think I've ever written a CGI
$$ program, in Perl or otherwise, that had to have a required extension.
$$ Since the very first release of Apache (and all of the releases of the
$$ NCSA server from which Apache was derived), a CGI script was
$$ recognized by its leading path, not its extension.
$$
$$ Only in recent versions of Apache have you also been able to add CGI
$$ recognized "anywhere" using an extension, which to me seems to be a
$$ Very Bad Idea from a security perspective, intermingling data and code
$$ much too closely for comfort, not to mention revealing the
$$ implementation language to outsiders making systematic attack easier.
I've never played with Apache much, but I did with NCSA. And that server
could be configured to allow execution of files as CGI programs based on
file name extension.
I do not share your perceived security aspect. Deciding whether
something is a CGI program or a static document based on file extension
is as arbitrary as the leading path. They both depend on the same path,
whether you look at the end or the beginning isn't significant. And file
extensions are already being used en masse to determine the Content-Type
anyway.
Increasing security by not revealing the implementation language (not that
.cgi reveals anything - or .pl for that matter; I doubt Apache will barf
if you have a Python file (with appropriate shebang line) whose name ends
in .pl) sounds like security through obscurity to me.
IMO, a more reasonable approach to decide whether something is a CGI
program or a static document is to look at the execution bit. If set,
it's a program, else, it's a static document. But apparently, some idiots
decided that the execution bit was a neat trick to decide whether a
document should go through an SSI interpreter.
Abigail
--
package Just_another_Perl_Hacker; sub print {($_=$_[0])=~ s/_/ /g;
print } sub __PACKAGE__ { &
print ( __PACKAGE__)} &
__PACKAGE__
( )
Alan J. Flavell
> But even that's still wrong. I don't think I've ever written a CGI
> program, in Perl or otherwise, that had to have a required extension.
> Since the very first release of Apache (and all of the releases of the
> NCSA server from which Apache was derived), a CGI script was
> recognized by its leading path, not its extension.
For as long as I can recall, it's been one possible configuration
option.
> Only in recent versions of Apache have you also been able to add CGI
> recognized "anywhere" using an extension,
Excuse me, but, I'd really have to correct you there. My early
encounters with NCSA HTTPD, years ago, involved taking a decision
whether to use ScriptAlias and/or to configure particular filename
extensions for the "magic" content-type for CGI.
And although Apache now prefers the use of AddHandler for the latter
purpose, it still supports the old "magic" content-types for CGI. SSI
and so forth ( application/x-httpd-cgi etc.).
http://www.apache.org/docs/handler.html
> which to me seems to be a
> Very Bad Idea from a security perspective, intermingling data and code
> much too closely for comfort,
There's a lot of truth in what you say, although sometimes there are
reasons for doing it. I'd agree that it calls for a more intensive
security audit.
> not to mention revealing the
> implementation language to outsiders making systematic attack easier.
This isn't always the case.
Consider the "default document", like http://www.foo.bar/baz/
The server can be given a list of file names to try for the default
document: index.html, index.cgi, index.shtm, Welcome.htm
(these are just examples, not a particular recommendation)
and the URL advertised without giving any file name at all.
The site then has the freedom to change from a static file to an
SSI or CGI or back again at any time, without having to tell the world
about it.
If you want to be really secretive, you can set the server to redirect
any explicit requests for these file names, right back to
http://www.foo.bar/baz/
HTH. (Sorry, yes I know it's OT here)
Randal L. Schwartz
>> Only in recent versions of Apache have you also been able to add CGI
>> recognized "anywhere" using an extension,
Alan> Excuse me, but, I'd really have to correct you there. My early
Alan> encounters with NCSA HTTPD, years ago, involved taking a decision
Alan> whether to use ScriptAlias and/or to configure particular filename
Alan> extensions for the "magic" content-type for CGI.
Yes, I misremembered (twice in three days :). Happens. :)
Alan> This isn't always the case.
Alan> Consider the "default document", like http://www.foo.bar/baz/
Alan> The server can be given a list of file names to try for the default
Alan> document: index.html, index.cgi, index.shtm, Welcome.htm
Yup. That's OK. But it's scary when I end up seeing a URL in my
location bar of "foo.pl" or "index.py" or "whatever.tcl" though.
Gives away more than it needs to give.
Godzilla!
> Andy wrote:
> Andy> the difference is that some servers will only allow a perl
> Only in recent versions of Apache have you also been able to add CGI
> recognized "anywhere" using an extension, which to me seems to be a
> Very Bad Idea from a security perspective, intermingling data and code
> much too closely for comfort, not to mention revealing the
> implementation language to outsiders making systematic attack easier.
My perspective and take on these new relaxed standards, Randal,
is they are both a blessing and a curse. I cannot argue your
point of view but can add some positive notes on this change.
For me personally, I like this change. One benefit is I can
replace " index.html " with " index.cgi " for my directory
indexing. This affords me an ability to closely track those
attemping a directory indexing for whatever reason. This does
have rewards when I recognize a selected server with specific
combinations of other information pulled by an index.cgi; it
enhances my ability to predict and thwart security problems.
Another benefit is an ability to load your cgi programs within
a specific directroy tree, well protected not only by index.cgi
but also creative .htaccess documents free of webserver admin
intervention or assistance. Otherwords, I can bury my sensitive
cgi programs deeply beneath multiple layered security checks.
A minor spinoff on this, is an ability to load your programs
within directory trees with very odd names; concealment.
There are quite a few indirect benefits from this cgi everywhere
philosophy we have today. As a result of security problems you
hint at, experts in this area of security have been presented
with new challenges in security and, in turn, have created
solutions for a wide range of security needs. We have better
security now in exchange for relaxing basic security. Our
collective knowledge base of security issues is growning
exponentially now with new problems presented.
It does seem Brenner's early addressing of security issues
and Stein's subsequent cgi.pm are both a result of opening
up servers to abuse with this cgi everywhere thing. Our
cgi wrappers seem to also be an offshoot.
One of the other gals here, not sure which, Abigail or
Elaine, doesn't matter which, both are clear Sages Of
Perl whose words can be taken as gospel truth, one made
mention during a security debate about servers having
a 'sandbox' for naughty requests. This is another example
of a positive outcome for this issue; servers have no
choice but to be more security aware.
In summary, cgi everywhere, is both a blessing and a curse.
This has brought us new security problems and, has also
afforded us new security techniques going beyond just
basic issues presented by cgi everywhere. This change has
shifted the burden of security to the shoulders of both
administration and programmers. All are responsible now.
So yes, as you say, there are concerns. Hopefully our
programming community in general, is up to these new
challenges today. I believe we are.
Godzilla!
--
@© = (a .. z); @® = qw (7 15 4 26 9 12 12 1 18 15 3 11 19);
srand(time() ^ ($$ + ($$ << 15)));
sub G { rand(1000) < 500 ? "\u$1" : "\l$1" ; }
foreach $¿ (@®) { $¢ = $©[$¿-1]; $¢ =~ s/([a-z])/G($1)/gie;
if ($¢ =~ /($©[0])/i) { $¢ = "$¢ "; } print $¢; }
print "!"; exit;
brian d foy
> >>>>> "Andy" == Andy Bridges <abri...@eurobell.co.uk> writes:
>
> Andy> the difference is that some servers will only allow a perl
> Andy> script to be executed as a .cgi file extension.
>
> Andy> you will normally find that this happens on older style
> Andy> webservers , most of the newer webservers ( apache ) accept both
> Andy> .pl and .cgi file extensions.
>
> But even that's still wrong. I don't think I've ever written a CGI
> program, in Perl or otherwise, that had to have a required extension.
not even for the C----- class? that server recognizes scripts by
extension :)
> Only in recent versions of Apache have you also been able to add CGI
> recognized "anywhere" using an extension,
recent? how time flies... you've been doing this longer than you
think Randal.
--
brian d foy
CGI Meta FAQ <URL:http://www.smithrenaud.com/public/CGI_MetaFAQ.html>
Perl Mongers <URL:http://www.perl.org/>
brian d foy
> >>>>> "Alan" == Alan J Flavell <fla...@mail.cern.ch> writes:
> Alan> The server can be given a list of file names to try for the default
> Alan> document: index.html, index.cgi, index.shtm, Welcome.htm
> Yup. That's OK. But it's scary when I end up seeing a URL in my
> location bar of "foo.pl" or "index.py" or "whatever.tcl" though.
> Gives away more than it needs to give.
some of those are scary no matter how you configure the server :)
however, a server admin with too much time on their hands might
map all of those extensions to something else. not that i've
ever used mod_rewrite to do such a thing.
Villy Kruse
>
>Yup. That's OK. But it's scary when I end up seeing a URL in my
>location bar of "foo.pl" or "index.py" or "whatever.tcl" though.
>Gives away more than it needs to give.
>
In theory you should be able to give your HTML pages the extension .pl
and your perl CGI programs the extension .gif, and have it work with
the proper changes in the apache configuration file. Would probably
confuse a lot of people.
On unix systems, once it has been determined that the file is a CGI
program the suffix doesn't matter one way or the other in determining
what program language the CGI program was written in. MS-Windows may
be a bit different in this respect.
Villy
Konstantin Stupnik
> > Alan> The server can be given a list of file names to try for the
default
> > Alan> document: index.html, index.cgi, index.shtm, Welcome.htm
>
> > Yup. That's OK. But it's scary when I end up seeing a URL in my
> > location bar of "foo.pl" or "index.py" or "whatever.tcl" though.
> > Gives away more than it needs to give.
>
> some of those are scary no matter how you configure the server :)
>
> however, a server admin with too much time on their hands might
> map all of those extensions to something else. not that i've
> ever used mod_rewrite to do such a thing.
My guess is that it doesn't matter for apache under unix
what extension file have (if it is not explicitly configured
to handle some extensions in a special way).
The only thing required is executable permissions.
The trick is in first line of script.
#!/path/executable -options
If first line of file aaa.xxx is something like this:
#! /usr/bin/perl -w
this command will be executed:
/usr/bin/perl -w aaa.xxx
Apache under win32 work in almost the same way,
but I need to add handler for cgi extensions
(ie files that should be treated as cgi SCRIPTS).
--
Best regards,
Konstantin.
Brainbench MVP for perl.
brian d foy
> My guess is that it doesn't matter for apache under unix
guesses aren't a good source for information, especially when you
can read the docs and know for sure.
> what extension file have (if it is not explicitly configured
> to handle some extensions in a special way).
> The only thing required is executable permissions.
and various server configurations to allow CGI execution. it's
all about configuration.
Max Lybbert
> (snip)
> IMO, a more reasonable approach to decide whether something is a CGI
> program or a static document is to look at the execution bit. If set,
> it's a program, else, it's a static document. But apparently, some idiots
> decided that the execution bit was a neat trick to decide whether a
> document should go through an SSI interpreter.
Actually, while it does identify the file as a perl program, I think the
original idea was simply to tell the machine where to go to understand the
coding. This allowed for updates to the perl language. It also allows
bare-bones browsers to take advantage of the newest perl release, for
instance.
Abigail
<URL:news:398BE175...@pe.net>:
== Abigail wrote:
==
==
== > (snip)
==
== > IMO, a more reasonable approach to decide whether something is a CGI
== > program or a static document is to look at the execution bit. If set,
== > it's a program, else, it's a static document. But apparently, some idiots
== > decided that the execution bit was a neat trick to decide whether a
== > document should go through an SSI interpreter.
==
== Actually, while it does identify the file as a perl program, I think the
== original idea was simply to tell the machine where to go to understand the
== coding. This allowed for updates to the perl language. It also allows
== bare-bones browsers to take advantage of the newest perl release, for
== instance.
Djee, that was done by browsers from the first day they allowed execution
of programs. Every other program out there doesn't care in what kind of
language, or version of the language an external program is written. It
just executes the file, and it works perfectly.
Why your browser has taken some gigantic leaps back in time, I dunno.
Abigail
--
$_ = "\nrekcaH lreP rehtona tsuJ"; my $chop; $chop = sub {print chop; $chop};
$chop -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> ()
-> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> ()
Jack Thomas
If you want to convert a .pl file to a .cgi file, you simply need to rename
it.
Jack Thomas
jth...@pdxgothic.com
Tim Hammerquist
> "DS" <snak...@kc.rr.com> wrote in message
> news:vjmc5.94$L5....@typhoon.kc.rr.com...
> > What is the diference betweeen a .pl file and a .cgi file?
> > Can I convert a .pl to a .cgi?
>
>
> If you want to convert a .pl file to a .cgi file, you simply need to rename
> it.
This is correct for the most part. However, .pl (by def) implies that
it's a perl script, perl library, or something written in Polish. =)
.cgi implies that it complies with the Common Gateway Interface
standard, but it need not be written in perl. Here is a perfectly valid
cgi script written in the bash shell language:
: #!/bin/bash
: # test.cgi
: echo "Content-type: text/html
: "
: echo "<P><B>Hey there!</B></P>"
In the end, these are mostly semantic differences. If you see an
executable with a .cgi extension, it's most likely written in perl.
--
-Tim Hammerquist <ti...@cpan.org>
Life is too serious to be taken seriously.
-- Mike Leonard
Abigail
in <URL:news:slrn8ot2...@degree.ath.cx>:
[] On Mon, 7 Aug 2000 01:45:29 -0700, Jack Thomas <jth...@pdxgothic.com> wrote:
[] > "DS" <snak...@kc.rr.com> wrote in message
[] > news:vjmc5.94$L5....@typhoon.kc.rr.com...
[] > > What is the diference betweeen a .pl file and a .cgi file?
[] > > Can I convert a .pl to a .cgi?
[] >
[] > Perl .pl and Perl .cgi are file types which are equivalent.
[] >
[] > If you want to convert a .pl file to a .cgi file, you simply need to rename
[] > it.
[]
[] This is correct for the most part. However, .pl (by def) implies that
[] it's a perl script, perl library, or something written in Polish. =)
By whose definition?
[] .cgi implies that it complies with the Common Gateway Interface
[] standard, but it need not be written in perl. Here is a perfectly valid
[] cgi script written in the bash shell language:
[]
[]
[] : #!/bin/bash
[] : # test.cgi
[] : echo "Content-type: text/html
[] : "
[] : echo "<P><B>Hey there!</B></P>"
[]
[] In the end, these are mostly semantic differences. If you see an
[] executable with a .cgi extension, it's most likely written in perl.
I could easily make PNG images with a .cgi extension, and instruct a web
server to execute files with a .html extension.
Abigail
--
map{${+chr}=chr}map{$_=>$_^ord$"}$=+$]..3*$=/2;
print "$J$u$s$t $a$n$o$t$h$e$r $P$e$r$l $H$a$c$k$e$r\n";
brian d foy
> Perl .pl and Perl .cgi are file types which are equivalent.
maybe. it depends on what importance a certain application places
on file extensions.
Jack Thomas
question originally.
The original message was as follows:
"DS" <snak...@kc.rr.com> wrote in message
news:vjmc5.94$L5....@typhoon.kc.rr.com...
> What is the diference betweeen a .pl file and a .cgi file?
> Can I convert a .pl to a .cgi?
And I responded with:
>Perl .pl and Perl .cgi are file types which are equivalent.
>If you want to convert a .pl file to a .cgi file, you simply need to rename
it.
My answer was SPECIFIC to Perl .pl and Perl .cgi files.
A .cgi could file could very well be a .exe file on an NT server, or it
could be written in Python, or Java, or whatever...
You must of course keep in mind, that it really depends on the MIME type
mapping on the server as well.
Jack Thomas
jth...@pdxgothic.com
"brian d foy" <br...@smithrenaud.com> wrote in message
news:brian-ya02408000...@news.panix.com...
brian d foy
> I think your all missing the point of my reply to the person who asked the
> question originally.
> My answer was SPECIFIC to Perl .pl and Perl .cgi files.
and you miss our point - file extensions are meaningless without
context. even in a Perl context, not all file extensions are
magic.
> You must of course keep in mind, that it really depends on the MIME type
> mapping on the server as well.
perhaps, but not necessarily. there are other things that can affect
this as well.
brian d foy
> Very true. Then again, most files you see with a .cgi extension
> _aren't_ PNG images.
and most *URLs* with a .cgi extension are not Perl source. ;)
Tim Hammerquist
> Tim Hammerquist wrote:
> [] This is correct for the most part. However, .pl (by def) implies that
> [] it's a perl script, perl library, or something written in Polish. =)
>
> By whose definition?
The perl docs mentioned that .pl was an old extension for perl
"libraries," such as cgi-lib.pl, which isn't an independent script, but
a "library" of functions, etc.
ActivePerl for Win32, which operates far too much by file extension,
maps .pl to perl.exe by default.
As for Polish, check your locale dir(s) on *nix systems.
Maybe I should have clarified: .pl IMPLIES perl script by CONVENTION.
It doesn't mean I agree or endorse this practice.
> [] In the end, these are mostly semantic differences. If you see an
> [] executable with a .cgi extension, it's most likely written in perl.
>
> I could easily make PNG images with a .cgi extension, and instruct a web
> server to execute files with a .html extension.
Very true. Then again, most files you see with a .cgi extension
_aren't_ PNG images.
For future reference, I might not always post my personal belief,
preference, or endorsed practice. I might make reference to obsolete
methods, or maybe just what "some people" do.
--
-Tim Hammerquist <ti...@cpan.org>
Of course, that's just my opinion. I could be wrong.
-- Dennis Miller
Abigail
in <URL:news:slrn8p1c...@degree.ath.cx>:
:: On 07 Aug 2000 15:33:34 GMT, Abigail <abi...@foad.org> wrote:
:: > Tim Hammerquist wrote:
:: > [] This is correct for the most part. However, .pl (by def) implies that
:: > [] it's a perl script, perl library, or something written in Polish. =)
:: >
:: > By whose definition?
::
:: The perl docs mentioned that .pl was an old extension for perl
:: "libraries," such as cgi-lib.pl, which isn't an independent script, but
:: a "library" of functions, etc.
::
:: ActivePerl for Win32, which operates far too much by file extension,
:: maps .pl to perl.exe by default.
::
:: As for Polish, check your locale dir(s) on *nix systems.
::
:: Maybe I should have clarified: .pl IMPLIES perl script by CONVENTION.
:: It doesn't mean I agree or endorse this practice.
There is a world of difference between 'convention' and 'by definition'.
Abigail
--
perl -we '$@="\145\143\150\157\040\042\112\165\163\164\040\141\156\157\164".
"\150\145\162\040\120\145\162\154\040\110\141\143\153\145\162".
"\042\040\076\040\057\144\145\166\057\164\164\171";`$@`'
Alan J. Flavell
> Maybe I should have clarified: .pl IMPLIES perl script by CONVENTION.
That is indeed one possible convention. You seem to have hung too
much onto it though.
The use of filename extensions to denote the nature of the file
content is itself only _by convention_. Some OSes have other
mechanisms for doing that, like content-type fields in a file
directory entry and so on.
Tim Hammerquist
Which OSes are these, I'm curious?
I left Win32 because of it's extension associations, and *nix uses the
shebang line to determine execution method. I've only seen the
content-type method when serving documents from a web server.
--
-Tim Hammerquist <ti...@cpan.org>
For every problem, there is one solution
which is simple, neat and wrong.
-- H. L. Mencken
Tim Hammerquist
> There is a world of difference between 'convention' and 'by definition'.
So true. Do you remember where 'by definition' first entered the
thread?
Let it go.
--
-Tim Hammerquist <ti...@cpan.org>
A liar should have a good memory.
-- Quintilian
Alan J. Flavell
> > The use of filename extensions to denote the nature of the file
> > content is itself only _by convention_. Some OSes have other
> > mechanisms for doing that, like content-type fields in a file
> > directory entry and so on.
>
> Which OSes are these, I'm curious?
Well, there's the Mac. And the Apollo was also like this, if my
memory isn't playing tricks (although it also had some kind of
compatibility mode with regular unix). I don't doubt there are others
I'm not aware of.
> I left Win32 because of it's extension associations,
I wasn't for a moment trying to promote the idea that anyone should
change their OS for this specific reason... just a an in-principle
and otherwise throwaway remark.
There are huge numbers of OSes, past and present, that I know almost
nothing about (LynxOS, Plan9...).
cheers
Tim Hammerquist
> > Which OSes are these, I'm curious?
>
> Well, there's the Mac. And the Apollo was also like this, if my
> memory isn't playing tricks (although it also had some kind of
> compatibility mode with regular unix). I don't doubt there are others
> I'm not aware of.
Thanx. I don't have much experience with Mac, and I haven't really
heard much about Apollo at all. KDE on my linux box also has MIME
associations, but a file's mime type is determined by its extension
and/or the first line/few characters of the file. How does the Mac do
this?
> > I left Win32 because of it's extension associations,
>
> I wasn't for a moment trying to promote the idea that anyone should
> change their OS for this specific reason... just a an in-principle
> and otherwise throwaway remark.
My statement was actually a bit hasty. Extension associations weren't
the only reason I switched; I used cygwin bash for the most part, so I
explorer associations were all but forgotten. =)
I also left Windoze because I couldn't leave the box running for more
than 2 hours without it crashing. And Apache wasn't stable. ...I guess
I just came to prefer the unix method. Since I've installed linux, (1
yr ago), applications have only crashed a total of 3 times, and that was
only out of my own misuse of them; the apps NEVER brought down the rest
of the box. Why would I go back? =)
Thanks again for the info.
--
-Tim Hammerquist <ti...@cpan.org>
The surest sign that intelligent life exists elsewhere in
the universe is that it has never tried to contact us.
-- Bill Watterson (Calvin & Hobbes)
Alan J. Flavell
> > Well, there's the Mac. And the Apollo was also like this, if my
> > memory isn't playing tricks (although it also had some kind of
> > compatibility mode with regular unix). I don't doubt there are others
> > I'm not aware of.
> [..] I haven't really heard much about Apollo at all.
Don't worry about it, you're only about a decade too late ;-)
The Apollo Domain OS was a somewhat quirky, generally unix-like,
networked operating system, but with a number of unique features, such
as its own networked file system. Apollo was bought-out by HP in (the
archives say) 1989.
> How does the Mac do this?
With respect, going into that in any detail would take us too far off
topic for this group. Suffice it to say that Mac file handling is
different in a number of ways - the specific point here is that the
file system directory includes a field for specifying a four-character
file-type, independent of any evidence in the visible filename.
Native Mac applications will fill in this field appropriately..
A web search reveals (small world!) that my old friend Robin Walker
wrote a sort of FAQ about importing non-Mac files into a Mac
environment, with suitable mappings from filename extensions into the
Mac filetype fields, see (beware - line wrapping)
<URL: http://wuarchive.wustl.edu/systems/mac/umich.edu/misc/
documentation/exttotypemappings.txt >
cheers
Jim Gaasedelen
extension.
A .cgi script can be written in perl and usually is, but doesn't have to
be. It can
be written in a shell script. Different applications may dictate a
different name
and they must be consistent. You cannot name a script x.pl and reference
it x.cgi.
.cgi scripts are usually used in cgi applications but are very often
written in
perl and this works just fine.
Abigail wrote:
>
> DS (snak...@kc.rr.com) wrote on MMDXI September MCMXCIII in
> <URL:news:vjmc5.94$L5....@typhoon.kc.rr.com>:
> ][ What is the diference betweeen a .pl file and a .cgi file?
>
> The name.
>
> ][ Can I convert a .pl to a .cgi?
>
> Sure. Rename the file.
>
> Abigail
> --
> perl -e '$a = q 94a75737420616e6f74686572205065726c204861636b65720a9 and
> ${qq$\x5F$} = q 97265646f9 and s g..g;
> qq e\x63\x68\x72\x20\x30\x78$&eggee;
> {eval if $a =~ s e..eqq qprint chr 0x$& and \x71\x20\x71\x71qeexcess}'
brian d foy
> A .pl script is written in perl and windows recognizes programs by their
> extension.
it might be written in Perl. windows recognizes it only if someone
(e.g. the ActiveState installer) tells it to.
> A .cgi script can be written in perl and usually is, but doesn't have to
> be. It can
> be written in a shell script. Different applications may dictate a
> different name
> and they must be consistent.
they don't have to be consistent. some servers might have limited
configuration abilities, but that is only some servers.
> You cannot name a script x.pl and reference
> it x.cgi.
yes you can. URL paths do not directly translate to file names