I just released File::pushd 0.20 to CPAN. It provides for a temporary directory change that reverts at the end of a scope (similar to File::chdir but works on Win32). From the synopsis: 

     use File::pushd;

     chdir $ENV{HOME};

     # change directory again for a limited scope
     {
         my $dir = pushd( '/tmp' );
         # working directory changed to /tmp
     }
     # working directory has reverted to $ENV{HOME}

     # equivalent to pushd( File::Temp::tempdir )
     {
         my $dir = tempd();
     }

[download]

I wrote this as a helper module for my test scripts and it seeemed like it might be useful to others. Comments and critique welcome.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Replies are listed 'Best First'.
Re: Released: File::pushd
by diotalevi (Canon) on Sep 02, 2005 at 12:45 UTC

    What does "push'd" mean? Why didn't you just overload chdir or extend it like chdir_push/push_chdir/local_chdir/chdir_local? Could you rename it to something like File::LocalChdir?

[reply]
      pushd/popd are rather well known shell builtins for directory stack manipulation. That's probably the rationale for the naming.
      --kap
[reply]
[d/l]
        Ok. I come from the programming side of the world and just use perl when I need something fancier in a shell.
[reply]
        Howdy!

        ...for some values of "shell"...

        yours,
        Michael
[reply]

      Good question! Based on the node title, I thought it'd be some daemon to push files from a server to clients. Quite wrong ...

      --
      b10m

      All code is usually tested, but rarely trusted.
[reply]
Re: Released: File::pushd
by merlyn (Sage) on Sep 02, 2005 at 12:44 UTC
    If the problem was that File::chdir didn't work on win32, did you try to contact the author to get that module fixed first? You've increased the community confusion by introducing a new module just to fix a problem with an old module. {sigh}

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

[reply]

      Several reasons.

      • Schwern has his hands full these days and non-essential stuff is getting (appropriately) put on the back burner. (I say this based on email exchanges with him after I identified a possible off-by-one bug in Sub::Uplevel some weeks ago).
      • File::pushd uses a different interface that doesn't rely on manipulating automatically-exported, tied, global variables. (Aren't those anti-patterns? Shouldn't we be discouraging their use?) From that perspective, I'd argue my module brings something new to the table rather than just being a fix to an old module.
      • The broken functionality in File::chdir has to do with using @CWD to represent separated components of a directory and changing directories by pushing/popping the array. This breaks on Win32 due to the existence of the volume (e.g. C:\ ). It wasn't just broken -- it was never written to be portable in the first place. None of this functionality was relevant to what I needed, but it meant the module wasn't available via PPM, which I try to stick with for my Win32 perl. It was faster to code up and release a more narrowly targeted module (including a test suite) than to unravel getting the right behavior in File::chdir. (Which I did pull down and examine to see if I could manage a quick fix before I even started.)

      I think your standards on your home node about "needless reimplementation" are needlessly high.

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

[reply]
[d/l]
        I think your standards on your home node about "needless reimplementation" are needlessly high.
        Not at all. You satisfied my curiousity entirely. I ask such a question because I want to know, and because sometimes it reveals things to the addressee as well.

        -- Randal L. Schwartz, Perl hacker
        Be sure to read my standard disclaimer if this is a reply.

[reply]
      you've increased the community confusion by introducing a new module just to fix a problem with an old module. {sigh}

      by your reasoning, we should also have one language, since now we have confusion of the right tool to use. we should also drive the same cars and what not. it's competition and evolution. bad/old/wrong things die out, good/new/right things live on. tmtowtdi

      save {sigh} us {sigh} your {sigh} emotional {sigh} distress. you would think that someone who would be considered a teacher would be a little more patient with others much less the entire community.

[reply]
        While some would consider responding to Anonymous Monk akin to responding to a known troll, I would assure you that I'm not fighting a non-existent boogeyman here. I have clients that say "Why do we have implementations X, Y, and Z of a given problem?" and therefore I know that marketplace confusion does exist when things get forked.

        Do not try to reduce this argument through taking it to an extreme. If there's a fork, it should be justified. The justifications were shown, so I'm happy, and moving on. You should do the same.

        -- Randal L. Schwartz, Perl hacker
        Be sure to read my standard disclaimer if this is a reply.

[reply]

Back to Perl News