in reply to chdir vs. shell behavior

I believe this is a FAQ, and if it isn't, it should be. per-process features, like current directory are not inherited upward, only downward. There's nothing any child process can do that can affect the parent's directory, without the parent cooperating in very unusual ways.

-- Randal L. Schwartz, Perl hacker

Replies are listed 'Best First'.
RE: RE: chdir vs. shell behavior
by BBQ (Curate) on Jun 14, 2000 at 21:30 UTC
    Yup. The FAQ (perlfaq8) says:

    In the strictest sense, it can't be done -- the script executes as a different process from the shell it was started from. Changes to a process are not reflected in its parent, only in its own children created after the change. There is shell magic that may allow you to fake it by eval()ing the script's output in your shell; check out the comp.unix.questions FAQ for details.

    "There is shell magic that may allow you to fake it" is exactly what I'm after. At this point, I'm not worried about portability, compatibility or downright correctness. If it gets the job done, I'm game.

    #!/home/bbq/bin/perl
    # Trust no1!
[reply]
      On the one occasion I had cause to do this, I exec'd the perl script from the login script, and exec'd a new shell from the perl script. Problem was, that launched the shell twice - easily solved in my case, as I had the luxury of making the perl script the login shell for the relevant users. This also solves the problem of needing to stop the script from executing twice (either by assuming a login shell the first time around, or setting an environment variable from within the script)

      As someone else pointed out, passing the output from the script to a cd command works too. But things complicate if you want to change more of the environment than just the directory...

      That is (shell script): 

         # ... stuff run every time this script is invoked
   if [ "$checkvar" != "foo" ]; then
     exec perl /usr/script/myscript.pl
   else
     # ... stuff to do after the script has run
   fi

      [download]
      And in the perl script: 
        $ENV{checkvar}="foo";
  exec "sh", "/usr/script/myshell.sh" # or, if you're logging in
  exec "sh", "-l"

      [download]
      There may be a problem if the shell script is not being executed as part of a login sequence, as you can't assume the environment is trustworthy. I suspect in most cases all someone who fakes the variable is going to do is make the perl script fail to run...
[reply]
[d/l]
[select]
        ahunter++!

        Right before I read your post, I tried something that was almost there and gave me some p-r-e-t-t-y stupid results. The following is an example of what NOT TO DO: 
        .bashrc contained:
# last line
exec /usr/global/distinctuser.pl
logout

        [download]
        and my distinctuser.pl user:
        # check for files, connect via DBI, make toast, etc...
chdir('/bar');
system('/bin/bash');
exit;

        [download]
        So, now that I had everything setup, I logged in. BOOM!!! At the end of .bashrc, we get perl, and the end of perl we call bash (and .bashrc again), and over and over. I just stood there looking at the screen wondering for a second or two why I was getting 800 printouts of fortune.

        The method you just described works perfectly. Its true tho that there will be 2 bashes and 1 perl running per user, but that doesn't seem to be affecting the system load. It isn't a heavily used machine anyway. Thanks!

        #!/home/bbq/bin/perl
        # Trust no1!
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom