Is there a reason you can't read the other script and do what it does in the context of the current process? ie., find the chdir and then do what it does in your perl script?
Just a guess, but I think the . command is instructing the current shell to interpret the script - which it can't because it has perl commands/functions in it.
The "exec" builtin in bash (sh on Linux seems to be too) will run the perl process without creating a new process by replacing the original shell process, just like the C exec* family of functions.
So you ought to be able to run a script by "./script.sh" to create a new process and then "exec perl script.pl" to continue execution without introducing a new process, but the original shell script will terminate (control will not return to the shell script).
You would like the Perl script chdir() to affect the parent shell process? That is impossible in this case as exec() won't return, so when the Perl script ends, the original shell process also ends.
I'm sorry that I have probably misunderstood your question. I would say the method is only for the original process image (shell script in your case) affecting the later, replaced process image (the Perl script in your case), and doesn't work if you expect the parent environment to be influenced after exec(), as it won't return at all.
Absolutely correct. What you are asking: 'Can I source a file from inside perl?'
No. Because you have to call exec. This is exactly the same problem you have with shell scripts doing a cd and then exiting.