Re: CSH script that calls a perl script

There are many ways to return data from your perl script to your csh script.

If the perl script is not otherwise writing to STDOUT, you could output the new value to STDOUT. Your csh script could execute the perl script and capture its STDOUT and use what it receives to update its variable.

You could have the perl script write a file with the new value in it and have your csh script read the file after it runs the script. If you might have more than one instance of the csh and perl script running at a time, you will have to make sure the filenames are unique. The easiest way might be to generate a unique filename in the csh script (e.g. use the pid in the filename) and pass the filename to the perl script, as you do stapl and serial.

There are other options for IPC, including named and unnamed pipes and sockets, but these would be a bit more complicated to use. I wouldn't bother unless I had already ruled out the simple options.

Comment on Re: CSH script that calls a perl script

Replies are listed 'Best First'.
Re^2: CSH script that calls a perl script by McA (Priest) on Oct 17, 2012 at 07:30 UTC
Hi, just an addition to that what ig said: Let the perl script generate shell variable assignments like `SOME=thing`, capture the output of the perl script and evaluate it in the context of the csh script. Than you have the return values in the variables of the csh script. But be careful with variable interpolation, shell meta characters and all that stuff. But the core of the idea is: Generate something which can be directly interpreted with csh. A kind of serialize to something that can be deserialized by csh. Best regards McA	[reply] [d/l]
Re^3: CSH script that calls a perl script by MidLifeXis (Monsignor) on Oct 17, 2012 at 12:21 UTC
As an example on this method, ssh-agent does this. eval `ssh-agent PARAMS`. ssh-agent generates the commands that the shell will then evaluate. OT: In a previous life I also used this method to set up user accounts at a university to have the proper environment for their classwork (see modules). A user's account, on login, would read configuration files that would generate the appropriate variables, aliases, path settings, and other schtuff specific to their coursework or other projects that they were participating in. The shell (independent of which one they used) would then evaluate these shell commands that were generated. It made my life as an admin much easier, the user accounts much more consistent and predictable, and allowed the professors the ability to request applications and configurations particular (or peculiar) to their classes. Not certain if I would use this particular implementation again, but it did work well in the mid 1990's. --MidLifeXis	[reply] [d/l]


more useful options
	PerlMonks