Called as CGI or from command line?

[bill]

Is there a way for a Perl script to know whether it was called via
a CGI request or through the command line?

Thanks,

-bill

 

[Tad McClellan]

Is there a way for a Perl script to know whether it was called via
a CGI request or through the command line?

I dunno off-hand.

But I _do_ know how to tell if it was run from a tty (command line)
or not:

perldoc -f -t

 

[Sherif Zaroubi]

I dunno off-hand.

But I _do_ know how to tell if it was run from a tty (command line)
or not:

perldoc -f -t

Check the environement variables ( %ENV, for example: $ENV{REMOTE_ADDR} )

 

[Alan J. Flavell]

Is there a way for a Perl script to know whether it was called via
a CGI request or through the command line?

But what's your _real_ question?

The CGI defines a common gateway interface. That interface includes
some environment variables, standard input, and standard output.

Those define the "common gateway". Anything else would be incidental,
and probably dependent on the web server etc.

So, if you wanted to test a CGI script from the command line, you
could set those variables beforehand. And then the script would think
it was being called from a CGI request. Now tell us whether you'd
define that to be "the command line" or "a CGI request". In a sense
it would be both, since you would have established the defined
requirements for the Common Gateway Interface.

 

[A. Sinan Unur]

Check the environement variables ( %ENV, for example: $ENV{REMOTE_ADDR} )

IMHO, checking $ENV{GATEWAY_INTERFACE} interface communicates the purpose
of the code more clearly.

 

[Gregory Toomey]

Is there a way for a Perl script to know whether it was called via
a CGI request or through the command line?

Thanks,

-bill

YES!

http://www.gregorytoomey.com/index.php?option=content&task=view&id=14&Itemid=28

(Apologies for the site to far - I just installed www.mamboserver.com on the weekend)

gtoomey

 

[Matt Garrish]

(Apologies for the site to far - I just installed www.mamboserver.com on the weekend)

Henceforth you shall be known as Orange Julius! : )

Matt

 

[Anno Siegel]

IMHO, checking $ENV{GATEWAY_INTERFACE} interface communicates the purpose
of the code more clearly.

Environment-checking probably is the solution OP was looking for, but it
should be clear that nothing stops a command-line user from setting those
variables. Their existence doesn't prove the program was called through
the CGI.

Anno

 

[Alan J. Flavell]

Environment-checking probably is the solution OP was looking for, but it
should be clear that nothing stops a command-line user from setting those
variables.
Right

Their existence doesn't prove the program was called through
the CGI.

That's a matter of terminology. If it walks like a duck, and quacks
like a duck... If all the relevant requirements have been set up for
the common gateway interface, then it -is- the common gateway
interface. What it really -doesn't- prove is that the program was
invoked from a web server (HTTPD), which is presumably the real
criterion that someone asking this question would have had in mind.
But I know of no portable (i.e platform-independent) way of proving
that conclusively.

 

[ctcgag]

That's a matter of terminology. If it walks like a duck, and quacks
like a duck... If all the relevant requirements have been set up for
the common gateway interface, then it -is- the common gateway
interface. What it really -doesn't- prove is that the program was
invoked from a web server (HTTPD), which is presumably the real
criterion that someone asking this question would have had in mind.
But I know of no portable (i.e platform-independent) way of proving
that conclusively.

Presumably, someone running Perl code from a CLI has access to the
code itself. That being the case, they can do whatever they want
with the code, such as removing or reversing the CGI detection logic.
So if you are assuming a hostile environment, at this point you are
already screwed. I think what the OP really wants to know is whether
the options should be gotten from CGI or from CL arguments, and whether
the output should be HTML or not. If an authorized CLI user wishes to
go out of his way to trick the script into making life more difficult for
himself, I really couldn't care less, unless I'm paying for his time.

Xho

 

[Alan J. Flavell]

Presumably, someone running Perl code from a CLI has access to the
code itself. That being the case, they can do whatever they want
with the code, such as removing or reversing the CGI detection logic.
So if you are assuming a hostile environment, at this point you are
already screwed.

Well, I was thinking more in terms of someone who is trying to design
a portable bi-modal script, which will behave in one way when invoked
from an HTTPD via the CGI (common gateway interface), and in a
different way when invoked from a user call.

I wasn't imputing "hostility" on the part of its user, but rather,
asking what they would want to happen if they, as a user, deliberately
synthesised a "common gateway interface" environment for the script
(for example, in order to debug the way in which it would behave when
run from an HTTPD via the CGI).

If you decided to base your test on the presence of a TTY, for
example, then you'd defeat the ability of the user to do that. Which
is why I was asking to think about the real purpose of this test.

I think what the OP really wants to know is whether
the options should be gotten from CGI or from CL arguments,
agreed

and whether the output should be HTML or not.

Not necessarily! Some CGI scripts are designed to return JPEG, or
even plain text. Maybe you meant to say "whether the output needs to
begin with CGI response header(s) or not" ?

If an authorized CLI user wishes to go out of his way to trick the
script into making life more difficult for himself, I really
couldn't care less,

Sure. But I don't think that was really the point that I was trying
to make. Sorry for any confusion caused.