Thread overview
pushd / popd for std.process/std.file
Jul 09, 2013
David
Jul 09, 2013
Jakob Ovrum
Jul 09, 2013
Jakob Ovrum
Jul 09, 2013
Artur Skawina
July 09, 2013
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");
}

July 09, 2013
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?

July 09, 2013
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?


July 09, 2013
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