[p4] P4 environment variables and csh or Perl

[Sheryl McKeown]

Hello All,

I'm currently writing some scripts to centralize our
p4 and p4d access. Currently we have a mixture of
.csh and .pl scripts used to start and stop p4d, run
checkpoints and do other admin tasks. I would like to
consolidate these into some central scripts.

I need to use C Shell or Perl.

The current configuration is to either set the P4*
variable in each and every script (which is a
nightmare to keep updated) or to read it from the
.cshrc.

I would like to set the P4* variables and some root
directory variables in one script then 'include' these
settings in all other scripts. But I can't seem to
get that to work.

P4CONFIG is an option, but I want to set other
variables we use in our admin tasks.

Ideally, I would like to "#include" a file into my
current shell. However, I am hitting the limits of
set and setenv of csh. (My hat for ksh and export!)

What I would like to do:

File include.csh:
#!/bin/csh
set P4TOP=/data1/perforce
set P4ARCHIVE=/data1/perforce/journal/archives
#and so on.

Calling file:
#!/bin/csh
./include.csh
#Now I have access to $P4TOP and $P4ARCHIVE
#Go and do some stuff

Of course the problem I am having with csh is that the
variables I set in include.csh are not being exported
back to the calling shell.

How can I get around this in either csh or Perl?

Any ideas are appreciated!
Sheryl McKeown

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

[Stephen Vance]

If you want to use the "include" approach, the csh equivalent is the
builtin 'source' command. For example,

#!/bin/csh
source include.csh

This is the equivalent of the Bourne shell '.' command. It invokes the
contents of the script used as its argument in the current shell, rather
than in a subshell.

There is another approach that works well. Typically, there are global
configuration files. For sh, it's /etc/profile. For csh, it's
/etc/cshrc. I don't recall if there is one for Perl. These are useful for
setting things like P4PORT and P4CONFIG, and can be managed over an
enterprise with tools like rdist (or Perforce as an archive for your
configuration files). Your P4TOP and P4ARCHIVE seem appropriate for this,
too, unless you need to protect their values from users.

Once you specify the two variables named above, you can put the rest either
in users' startup scripts (things like P4USER and P4PASSWD) or in the file
specified in P4CONFIG (e.g. .p4config). For administrative clients, you
carefully control their OS-level permissions to only be readable by your
Perforce adminstrative login and put the administrative user and password
in the file, as well as client options.

Post by Sheryl McKeown
Hello All,
I'm currently writing some scripts to centralize our
p4 and p4d access. Currently we have a mixture of
.csh and .pl scripts used to start and stop p4d, run
checkpoints and do other admin tasks. I would like to
consolidate these into some central scripts.
I need to use C Shell or Perl.
The current configuration is to either set the P4*
variable in each and every script (which is a
nightmare to keep updated) or to read it from the
.cshrc.
I would like to set the P4* variables and some root
directory variables in one script then 'include' these
settings in all other scripts. But I can't seem to
get that to work.
P4CONFIG is an option, but I want to set other
variables we use in our admin tasks.
Ideally, I would like to "#include" a file into my
current shell. However, I am hitting the limits of
set and setenv of csh. (My hat for ksh and export!)
#!/bin/csh
set P4TOP=/data1/perforce
set P4ARCHIVE=/data1/perforce/journal/archives
#and so on.
#!/bin/csh
./include.csh
#Now I have access to $P4TOP and $P4ARCHIVE
#Go and do some stuff
Of course the problem I am having with csh is that the
variables I set in include.csh are not being exported
back to the calling shell.
How can I get around this in either csh or Perl?
Any ideas are appreciated!
Sheryl McKeown
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
_______________________________________________
http://maillist.perforce.com/mailman/listinfo/perforce-user

Stephen Vance
mailto:***@vance.com
http://www.vance.com/

[Jeff A. Bowles]

Post by Stephen Vance
If you want to use the "include" approach, the csh equivalent is the
builtin 'source' command.

Exactly right. I probably would put a file in /usr/local/bin called
p4env.csh
and another called
p4env.pl
and, if necessary, one called
p4env.sh

Each would do the same thing: set variables (environment variables
if possible) in the appropriate scripting language, and assume that
the script was source'd/require'd/.'ed from its respective csh/perl/sh
script.

And you'd tell everyone to put such a line into their startup script:
source /usr/local/bin/p4env.csh (.cshrc)
. /usr/local/bin/p4env.sh (.profile)
and so on.

Heck, you could even have it set $P4CLIENT if it's not set,
according to your local conventions.

-jab

[Sascha Woyde]

Hi,
if you decide to put your environment variables in the users ~/.cshrc
and rely on this being executed be carefull with cron jobs. These may
not invoke such scripts. In such cases you have got to call them with
source as mentioned before. We are doing exactly this for our backup
procedure.
Bye,
Sascha

--

Sascha Woyde

Configuration Management

New postal address and phone number:
====================================

Gauss Interprise AG fon : [phone]
Research & Development fax : [phone]
Weidestr. 120 a
mail: ***@gauss-interprise.com
D-22083 Hamburg http://www.gauss-interprise.com