l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
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:
> > > Of course, I could easily be wrong.  Enlighten me, Jeff...  :)
> >
> > I am not enlightened... how could I hope to enlighten you? :)
> But you can *juggle*!  Surely a man who can juggle is at one with the
> universe and will be kind enough to ease my poor feeble mind.

In that case, let me show you how to juggle, and your mind will be at
ease. :)

> > 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.
> Maybe I should have explained myself.  A point I realized but didn't
> mention was that all the IPC techniques (including shared files, which I
> agree may not be such a hot idea) that I personally am aware of :) have the
> same problem: no chance, AFAIK, for communication to get set up on the
> parent (shell) end.  I treated the more general case of IPC between shell
> and Perl script rather than the more specific case of shared files not--as
> far as I am aware, anyway--out of misunderstanding of what you wrote, but
> because the same problem is present in the general case.

If Jay had wanted the perl script to be the child and the bash script to
be the parent, any of the options I posed could be turned around and the
shellscript could process the output of the perlscript.

If your "general case" is wanting to change the interactive shell from
which you invoke your environment-setting code, then you still have to
cooperatively accept the changes.  This calls for the straightforward
"source" or "." command to invoke the script that accepts the changes.  
To simplify the user interface, an alias (alias changeenv=". bashrcvenv")
will finish it off.

print "TESTVAR=100\n";

eval `perl perlchangenv`

This clearly requires cooperation on both ends, but it gets the job done.
Doing this without cooperation isn't possible, which is one of the good
things about *nix.

I'm still not sure about how other forms of IPC (shared memory,
sockets) might be used from bash (hmm.. netcat for sockets...) but they
won't change the fundamental issue of the parent process having to accept
and process properly formatted data.

(Jay: Note the potential security problems with eval if this is a shared

> > 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.
> Wouldn't that only change the environment variables in the process running
> the first Perl script?

That is what Jay wanted.  His shell script that sets the variables is
called by the perl script, and the variables he wanted set are in the
perl %ENV.

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

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
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:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.