Of course, this bash process is unnecessary, if all it does is to do a chdir. You can do the chdir in Perl as well (see chdir). However, if you expect that this intermediate bash script later will do additional stuff, which you, for whatever reason, would prefer implementing in bash, it would make sense to stick with that. As for passing the value of your variable to the other script, you have several options. Since in your case, the value is only a fairly short string, I would consider two possibilities: Pass them as a parameter to your bash script, which then hands it over as a parameter to your Perl script; or use an environment variable to pass the information.

Again, sorry for not being more clear in my description. You all make very valid points.

The reason I have two Perl scripts, is because they will executed at different times. Some background information through an example:

User executes PerlScript1. This creates a directory with contains a Checklist and a small bash script. The reason the bash script isn't executed yet is because it will execute PerlScript2, which produces a timestamped file that contains updates (only as recent as the timestamp, which is why I delay PerlScript2 by means of the bash script. This way the user can complete and add to the Checklist document and they don't have to worry about executing the second Perl script until they are absoultey ready, so as to ensure they have the most current updates.) When the user is finally ready for the timestamped folder, they can execute the bash script, which will call upon PerlScript2 and execute it, thus creating an updated timestamped folder. PerlScript2 sends out an email notification when it is executed and ultimately needs to use the $final variable from PerlScript1 to populate the email with the correct filename given in PerlScript1.

Hope this helps fill in some of the gaps.

Thanks.

In that case, see the answer below by Athanasius, about putting the value in a file. That's probably the simplest way to share a value between two programs that run independently of each other. You could write the value into the bash script directly, so it could pass it to script2.pl, but either way, you're writing the value into a file which can later be accessed in some way by the other script. So to keep it simple:

# in script1.pl
open my $out, '>', '/tmp/myvalue' or die $!;
print $out $final;
close $out;

# in script2.pl
open my $in, '<', '/tmp/myvalue' or die $!;
my $final = <$in>;
close $in;
[download]

There's a potential issue here if you have multiple users possibly running both scripts at the same time. Potentially the value could be half-written at the moment that script2.pl tries to read it. If that's possible in your case, look into file locking or have the storage file in the user's home directory so there won't be a conflict between users.

Aaron B.
Available for small or large Perl jobs; see my home node.

Since you are also create the bash script, create it in a way that it will pass on the requested value to PerlScript2 - either as an argument, or via the environment, depending on your taste.

-- 
Ronald Fischer <ynnor@mm.st>

This depends on whether the bash script is being executed by script1.pl, or by some other parent process which runs script1.pl, waits for it to complete, then runs the bash script. In the first case, simply pass the value in the command line like I did in my example, and then do the same from within your bash script. In the latter case, script1.pl would need to return the value to its parent process, which would then pass the value to the bash script.

I think it's very likely that the best solution would be to redo the whole thing as a single Perl script. However, if you already have two Perl scripts and you're just hoping to pass a value from one to the next without making any other changes, use my example, except stick chdir "directory"; at the beginning of script2.pl. That will eliminate the need for a bash script sitting between the two.