www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - pushd / popd for std.process/std.file

reply David <d dav1d.de> writes:
Having pushd/popd in std.process would make a lot of code look better,
often you have to change the workding directory only for a few commands,
with pushd/popd you don't have to temporarily store the old one explicitly.

pushd/popd: https://en.wikipedia.org/wiki/Pushd_and_popd

What do you think?


void build() {
    pushd("../build")
    scope(exit) popd();

    shell("cmake ../src/c/bla");
    shell("make");
}
Jul 09 2013
next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Tuesday, 9 July 2013 at 14:21:48 UTC, David wrote:
 Having pushd/popd in std.process would make a lot of code look 
 better,
 often you have to change the workding directory only for a few 
 commands,
 with pushd/popd you don't have to temporarily store the old one 
 explicitly.

 pushd/popd: https://en.wikipedia.org/wiki/Pushd_and_popd

 What do you think?


 void build() {
     pushd("../build")
     scope(exit) popd();

     shell("cmake ../src/c/bla");
     shell("make");
 }

I think it's a good idea, except instead of maintaing a separate stack it could use the call stack through RAII. Also, considering `getcwd` and `chdir` are in std.file, maybe that's the better location? Example implementation using RAII: --- auto pushd(in char[] path) { import std.file : chdir, getcwd; auto workingDir = getcwd(); struct PopWorkingDir { ~this() { chdir(workingDir); } } chdir(path); return PopWorkingDir(); } void main() { auto a = pushd("test"); import std.file : write; write("test.txt", "hi"); // Writes test/test.txt } --- Not sure if I like the fact that it will silently fail without the seemingly unused variable 'a' here (because the destructor is run immediately), but isn't this how we already do stuff like threading locks?
Jul 09 2013
parent Artur Skawina <art.08.09 gmail.com> writes:
On 07/09/13 17:04, Jakob Ovrum wrote:
 On Tuesday, 9 July 2013 at 15:02:59 UTC, Jakob Ovrum wrote:
 On Tuesday, 9 July 2013 at 14:21:48 UTC, David wrote:
 Having pushd/popd in std.process would make a lot of code look better,
 often you have to change the workding directory only for a few commands,
 with pushd/popd you don't have to temporarily store the old one explicitly.

 pushd/popd: https://en.wikipedia.org/wiki/Pushd_and_popd

 What do you think?


 void build() {
    pushd("../build")
    scope(exit) popd();

    shell("cmake ../src/c/bla");
    shell("make");
 }

I think it's a good idea, except instead of maintaing a separate stack it could use the call stack through RAII. Also, considering `getcwd` and `chdir` are in std.file, maybe that's the better location?


struct chDir { import std.file : chdir, getcwd; typeof(getcwd()) oldDir; this(string newDir) { oldDir = getcwd(); chdir(newDir); } ~this() { chdir(oldDir); } disable this(this); } import std.file : write; with (chDir("testdir")) write("test.txt", "hi"); But that is not going to work right now - the chDir object is destroyed too soon (compiler bug).
 Apropos threads; this isn't thread-safe at all, is it... does it make sense to
define semantics with multi-threading in mind?

Allowing declarations inside with() would make it possible to handle the multithreaded case too. artur
Jul 09 2013
prev sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Tuesday, 9 July 2013 at 15:02:59 UTC, Jakob Ovrum wrote:
 On Tuesday, 9 July 2013 at 14:21:48 UTC, David wrote:
 Having pushd/popd in std.process would make a lot of code look 
 better,
 often you have to change the workding directory only for a few 
 commands,
 with pushd/popd you don't have to temporarily store the old 
 one explicitly.

 pushd/popd: https://en.wikipedia.org/wiki/Pushd_and_popd

 What do you think?


 void build() {
    pushd("../build")
    scope(exit) popd();

    shell("cmake ../src/c/bla");
    shell("make");
 }

I think it's a good idea, except instead of maintaing a separate stack it could use the call stack through RAII. Also, considering `getcwd` and `chdir` are in std.file, maybe that's the better location? -snip-

Apropos threads; this isn't thread-safe at all, is it... does it make sense to define semantics with multi-threading in mind?
Jul 09 2013