Need help running shell commands

[jm]

I have my perl file set up as 4711 and am running it as root.

I simply want to change the path via the perl script:

I have tried system('/mypath'); and system "/mypath";



When I set the path in the script, is it only set for the script
itself (just for the script's usage)? and thus it wouldn't change the
path of the person running the script? Thank you.

 

[Ben Morrow]

Quoth (e-mail address removed) (jm):

I have my perl file set up as 4711 and am running it as root.

Why? It sounds like you don't know Perl anywhere near well enough yet to
be writing scripts to run setid.

I simply want to change the path via the perl script:

I have tried system('/mypath'); and system "/mypath";

When I set the path in the script, is it only set for the script
itself (just for the script's usage)? and thus it wouldn't change the
path of the person running the script? Thank you.

Please explain yourself a little better.

Are you attempting to set $PATH in the invoking user's shell? This is a
faq: perldoc -q environment

If you're trying to do something else, then I'm afraid I don't
understand you at all. Try posting a short complete program, and
explaining what it does that you don't want it to do (or what it doesn't
do that you do want).

Ben

 

[Bob Walton]

I have my perl file set up as 4711 and am running it as root.

I simply want to change the path via the perl script:

I have tried system('/mypath'); and system "/mypath";



When I set the path in the script, is it only set for the script
itself

Nope. Not even for the script itself (by using system()). Only for the
process kicked off by system() -- which, incidently, won't do much other
than error out if it is as shown, unless you happen to have an
executable program or script in your root directory named 'mypath'.
Maybe you meant system('cd /mypath'); ?

(just for the script's usage)? and thus it wouldn't change the
path of the person running the script? Thank you.

Even if you changed the directory in the process in

which your Perl interpreter is running your script
(which can be done using a module whose name I can't recall
-- maybe File::chdir ?), you *still* wouldn't change the
directory for the user, script, or whatever that fired
off Perl's process. Read a Unix primer -- a subprocess
is pretty well insulated from its parent process -- the
subprocess cannot make any change to the parent's
environment. That's a feature, not a bug. See:

perldoc -q 'changed directory'

 

[Ben Morrow]

Quoth (e-mail address removed):

Even if you changed the directory in the process in
which your Perl interpreter is running your script
(which can be done using a module whose name I can't recall
-- maybe File::chdir ?)

err, try perldoc -f chdir

Ben

 

[Gregory Toomey]

Quoth (e-mail address removed) (jm):

Please explain yourself a little better.

I dont have a clue what he wants. 4711 is a brand of aftershave.
http://www.fragrancewholesale.com/471127ozedc1.html

gtoomey

 

[Jürgen Exner]

I have my perl file set up as 4711 and am running it as root.

I simply want to change the path via the perl script:

You are not very clear about you are trying to do at all.
But I am guessing you are not talking about the path at all but you are
talking about the current working directory aka CWD.

I have tried system('/mypath'); and system "/mypath";

Assuming your shell has such a shortcut command, that if a directory name is
entered instead of a command then it will change the CWD to that directory.
Then still you are changing the CWD for the forked system process only, not
for the process that is running the Perl script.

When I set the path in the script, is it only set for the script
itself (just for the script's usage)?

Using system() you are not changing anything for the script itself, but at
best for the process that is being forked to execute the command(s) listed
in the system() call.
If you want to chagne the cwd of the Perl process then use the chdir()
command.

and thus it wouldn't change the
path of the person running the script?

Child process cannot modify the environment (including the CWD) of the
parent process. Please see "perldoc -q environment".

jue

 

[Tad McClellan]

When I set the path in the script, is it only set for the script
itself (just for the script's usage)? and thus it wouldn't change the
path of the person running the script?

Right.

That is how it is _supposed_ to be.

A child process (perl) cannot affect the environment of its parent (sh).


See this Perl FAQ:

I {changed directory, modified my environment} in a perl script.
How come the change disappeared when I exited the script?
How do I get my changes to be visible?

 

[jm]

Quoth (e-mail address removed) (jm):

Why? It sounds like you don't know Perl anywhere near well enough yet to
be writing scripts to run setid.


Please explain yourself a little better.

Are you attempting to set $PATH in the invoking user's shell? This is a
faq: perldoc -q environment

If you're trying to do something else, then I'm afraid I don't
understand you at all. Try posting a short complete program, and
explaining what it does that you don't want it to do (or what it doesn't
do that you do want).

Ben

Sorry, I was in a hurry. What I meant was:

system ('export PATH=/mypath:$PATH');
system ('. /mypath/myenvironment some_argc');

The problem is that I am using DBI and I have to be in a certain
environment to use it. I can't just call DBI. I have to set several
variables in the system (export myvar=myvalue) etc. and finally be in
a production environment before I can rund the DBI stuff in the Perl
script.

I apologize for the crazy code above.

 

[Ben Morrow]

Quoth (e-mail address removed) (jm):

Sorry, I was in a hurry.

When in a hurry explaining yourself clearly will *definitely* result in
quicker and more useful answers (if any) than being vague.

What I meant was:

system ('export PATH=/mypath:$PATH');
system ('. /mypath/myenvironment some_argc');

The problem is that I am using DBI and I have to be in a certain
environment to use it. I can't just call DBI. I have to set several
variables in the system (export myvar=myvalue) etc. and finally be in
a production environment before I can rund the DBI stuff in the Perl
script.

Right, that can't be done, as it stands. system forks a shell; this
shell cannot affect the working environment of the perl process.

You can change your environment variables yourself using the %ENV hash,
so for instance you can do

$ENV{PATH} = "/mypath:$ENV{PATH}";

.. You may find if this is for a DBD module that you need to do this in a
BEGIN block: certainly, I've found that with DBD::Sybase before.

Alternatively, if it is for some reason inconvenient to re-write the
shell script setting up the environment in Perl, you can wrap the perl
script in a shell script:

Move 'script' to 'script.pl'
Create a new file 'script' like

#!/bin/sh

export PATH="/mypath:$PATH"
.. /mypath/myenvironment some_argc

perl /path/to/script.pl

A third way would be to do something like

/(.*?)=(.*)$/ and $ENV{$1} = $2 for qx{
export PATH=...
. /mypath/...
env
};

if you can be sure nothing in your environment has a newline in it.

Ben

 

[Tad McClellan]

Changing directories, clearly, is not an environment variable
as you have indicated, not an environment variable in a
classic sense.

There are components of the "environment" that are NOT "variables".

The cwd is one such.

 

[Tad McClellan]

Sorry, I was in a hurry.

So you had hundreds or thousands of people trying to sort it all out?

That is an inefficient distribution of labor, please try not to do
that to us anymore.

What I meant was:

system ('export PATH=/mypath:$PATH');

$ENV{PATH} = "/mypath:$ENV{PATH}";

system ('. /mypath/myenvironment some_argc');

"myenvironment" is in a child process, so it inherits the environment
from its parent (perl), so it will have the modified path.

The problem is that I am using DBI and I have to be in a certain
environment to use it.

That is not a problem.

I have to set several
variables in the system

see the %ENV hash in:

perldoc perlvar

 

[Joe Smith]

I dont have a clue what he wants. 4711 is a brand of aftershave.

You cut out the part where Ben shows that he knows exactly what it
means:
A script is made setUID=root via the unix command "chmod 4771 script.pl".
It's a dangerous and ill-advised thing to do, especially for newbies.
-JOe

 

[Josef Moellers]

Ben Morrow wrote:

I dont have a clue what he wants. 4711 is a brand of aftershave.

Not only an aftershave but a whole series of fragrances, body lotions,
aftershaves etc.
Named after the number of the company's house in the Glockengasse in
Cologne (Germany). A specific product of 4711 is often referred to as
"Eau de Cologne" (Water of Cologne), mainly used by old spinsters B-{).
(No, I do not work for 4711).

Besides: Setting any the permission triples of an interpreted script to
1 is pretty senseless: the interpreter will be unable to read the
script's code:
Can't open perl script "./x.pl": Permission denied

Josef

 

[Tad McClellan]

You have forgotten you have me in your killfile.

I was slumming.

 

[Brad Baxter]

An activity much in keeping with the quality of your character.

Now, now, Ms. Gurl, you know it takes one to know one.

Regards,

Brad