l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
October 7: Social gathering
Next Installfest:
TBD
Latest News:
Aug. 18: Discounts to "Velocity" in NY; come to tonight's "Photography" talk
Page last updated:
2001 Dec 30 17:07

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Calling a shell pgm from perl to change ENV
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Calling a shell pgm from perl to change ENV



On Wed, 11 Jul 2001, Nicole Carlson wrote:

> On Wed, 11 Jul 2001 jdnewmil@dcn.davis.ca.us wrote:
> > > WARNING: ugly and untested idea.  Perhaps your Perl script could rewrite
> > > and re-source the .login or .bashrc or .whatever file?
> >
> > The only way you can change the parent's environment is to have the parent
> > receive suggested changes and process them itself.  Communicating those
> > changes through changes to .login or .bashrc would seem inappropriate, but
> > a dedicated file could be used.  The parent could even specify the name of
> > the file, created for the purpose.
> 
> Yes, but how would interprocess communication work in a *script*?  I had
> thought of IPC myself, but the script gets forked off first thing (the
> shell forks it off when it sees the #!/bin/whatever)--I just don't see where
> in a Perl script you'd have the chance to set up parent/child communication.
> It would be a piece of cake in a compiled C program, but a script?
> 
> Of course, I could easily be wrong.  Enlighten me, Jeff...  :)

I am not enlightened... how could I hope to enlighten you? :)

I can suggest you read what I wrote again, though. I didn't say "use IPC",
though putting information in a file for the parent to pick up might be
construed as a primitive form of IPC.  Perl is certainly capable of most
forms of IPC, but I am not enough of a shell wizard to suggest how the
other end of that communication would work. I did suggest that using files
with predetermined uses might not be a good idea for communicating between
a child and a parent, in the general case.

Scenario: Perl script touches temporary file (to reserve it), passes it to
script. Script accepts communication filename as argument, writes
suggested changes to temporary file as VAR=VALUE pairs. Perl notes
successful return from script, reads file, and splits the pairs and
hashes them into %ENV.

If the shellscript's standard output is not otherwise allocated, the
shellscript can be "opened" as a pipe [ open(INFILE, '|shellscript') ] and
the contents of the pipe be split and added to %ENV if you
desire.

If the shellscript were itself simply perl code and you are willing to
possibly pollute your variable namespace, it could be eval'd instead of
system'd or piped.

Or, if you are simply trying to steal the environment variables from a
bash script you could read it in and ignore anything that didn't look like
an environment variable definition.

There may be other solutions as well, but in all cases the parent is in
control of its environment, so choosing the appropriate one will depend on
the actual circumstances and your cleverness.  I don't claim to be clever,
though... this stuff is a continuing learning experience.

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k
---------------------------------------------------------------------------



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.