pushd / popd for std.process/std.file

2013-07-09 Thread David 
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);
}

Re: pushd / popd for std.process/std.file

2013-07-09 Thread Jakob Ovrum 

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?

Re: pushd / popd for std.process/std.file

2013-07-09 Thread Jakob Ovrum 

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?

Re: pushd / popd for std.process/std.file

2013-07-09 Thread Artur Skawina 
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