www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - system mkdir

reply noboy <nobody nowhere.com> writes:
Hello,

import std.stdio;
import std.process;
import std.string;


void main() {
    string debPackage="dmd-2";
    int dmdVersion=2;
    auto path = format("%s/usr/{bin,lib,src/phobos%d,share/man}",debPackage,dmdVersion);
    system("mkdir -p " ~ path);
}


The result:
dmd-2/usr/{bin,lib,src

it should be 
dmd-2/usr/bin
dmd-2/usr/lib
dmd-2/usr/src

Kubuntu 8.0.4
Mar 18 2010
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 18 Mar 2010 06:25:20 -0400, noboy <nobody nowhere.com> wrote:

 Hello,

 import std.stdio;
 import std.process;
 import std.string;


 void main() {
     string debPackage="dmd-2";
     int dmdVersion=2;
     auto path =  
 format("%s/usr/{bin,lib,src/phobos%d,share/man}",debPackage,dmdVersion);
     system("mkdir -p " ~ path);
 }


 The result:
 dmd-2/usr/{bin,lib,src

 it should be
 dmd-2/usr/bin
 dmd-2/usr/lib
 dmd-2/usr/src

 Kubuntu 8.0.4

The system function calls the libc system function. If you don't like the behavior, complain to the developers of libc for Kubuntu. If system is behaving differently under C, then that might be D's problem, but I can't tell if that's the case from your example. -Steve
Mar 18 2010
parent reply noboy <nobody nowhere.com> writes:
I was little bit surprise because 
mkdir -p dmd-2/usr/{bin,lib,src/phobos2,share/man
do the right thing.

But if i make
mkdir -p "dmd-2/usr/{bin,lib,src/phobos2,share/man"
it's wrong.

So i have think the system command wrap quotes about the command.

Perl have the same behaviour.
Thank you for your answer.

Steven Schveighoffer Wrote:

 On Thu, 18 Mar 2010 06:25:20 -0400, noboy <nobody nowhere.com> wrote:
 
 Hello,

 import std.stdio;
 import std.process;
 import std.string;


 void main() {
     string debPackage="dmd-2";
     int dmdVersion=2;
     auto path =  
 format("%s/usr/{bin,lib,src/phobos%d,share/man}",debPackage,dmdVersion);
     system("mkdir -p " ~ path);
 }


 The result:
 dmd-2/usr/{bin,lib,src

 it should be
 dmd-2/usr/bin
 dmd-2/usr/lib
 dmd-2/usr/src

 Kubuntu 8.0.4

The system function calls the libc system function. If you don't like the behavior, complain to the developers of libc for Kubuntu. If system is behaving differently under C, then that might be D's problem, but I can't tell if that's the case from your example. -Steve

Mar 18 2010
parent reply noboy <nobody nowhere.com> writes:
There was a soft link /bin/sh -> dash
I have change this to bash, and now all went fine.

Thank you

Steven Schveighoffer Wrote:

 On Thu, 18 Mar 2010 09:28:06 -0400, noboy <nobody nowhere.com> wrote:
 
 I was little bit surprise because
 mkdir -p dmd-2/usr/{bin,lib,src/phobos2,share/man
 do the right thing.

When you do that, you are using your shell. The shell actually does the argument expansion, not mkdir. So the question to answer is, does system use the shell or just call mkdir directly. According to my man page, using system("cmd") is equivalent to doing /bin/sh -c cmd. On my system doing this: /bin/sh -c 'mkdir -p /testdir/{a,b,c}' results in the desired behavior. The single quotes force the shell I'm currently running *not* to expand the arguments, but pass them directly to /bin/sh as one string. I would expect that system would execute the same command. I would guess on my system that your code would work properly, but I'm not sure. What you need to find out is what /bin/sh actually is on your system. Maybe it is a shell that does not understand how to expand the {a,b,c} term. IIRC, /bin/sh usually is a link to bash, but I think on some systems, bash behaves differently if it's called via /bin/sh.
 But if i make
 mkdir -p "dmd-2/usr/{bin,lib,src/phobos2,share/man"
 it's wrong.

 So i have think the system command wrap quotes about the command.

I don't think this is what's happening. -Steve

Mar 18 2010
parent reply Spacen Jasset <spacenjasset yahoo.co.uk> writes:
noboy wrote:
 There was a soft link /bin/sh -> dash
 I have change this to bash, and now all went fine.
 
 Thank you
 
 Steven Schveighoffer Wrote:
 
 On Thu, 18 Mar 2010 09:28:06 -0400, noboy <nobody nowhere.com> wrote:

 I was little bit surprise because
 mkdir -p dmd-2/usr/{bin,lib,src/phobos2,share/man
 do the right thing.

argument expansion, not mkdir. So the question to answer is, does system use the shell or just call mkdir directly. According to my man page, using system("cmd") is equivalent to doing /bin/sh -c cmd. On my system doing this: /bin/sh -c 'mkdir -p /testdir/{a,b,c}' results in the desired behavior. The single quotes force the shell I'm currently running *not* to expand the arguments, but pass them directly to /bin/sh as one string. I would expect that system would execute the same command. I would guess on my system that your code would work properly, but I'm not sure. What you need to find out is what /bin/sh actually is on your system. Maybe it is a shell that does not understand how to expand the {a,b,c} term. IIRC, /bin/sh usually is a link to bash, but I think on some systems, bash behaves differently if it's called via /bin/sh.
 But if i make
 mkdir -p "dmd-2/usr/{bin,lib,src/phobos2,share/man"
 it's wrong.

 So i have think the system command wrap quotes about the command.

-Steve


say something like: system("bash mkdir -p " ~ path); Messing with your sh symlink may have some undesired consequences.
Mar 19 2010
parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Spacen Jasset wrote:

 then presumably the syntax you are using is a bashism?. You could also 
 say something like:


 system("bash mkdir -p " ~ path);


 Messing with your sh symlink may have some undesired consequences.

Actually, not messing with it will have undesired consequences. Lots of scripts assume sh points to bash. Though he should still change his code so he isn't one of those doing the assuming. I think someone wanted to restore that scripts be sh complient when they claim to use it, so dash became the default.
Mar 19 2010
parent noboy <noboy <nobody nowhere.com>> writes:
Jesse Phillips Wrote:

 Spacen Jasset wrote:
 
 then presumably the syntax you are using is a bashism?. You could also 
 say something like:


 system("bash mkdir -p " ~ path);


 Messing with your sh symlink may have some undesired consequences.

Actually, not messing with it will have undesired consequences. Lots of scripts assume sh points to bash. Though he should still change his code so he isn't one of those doing the assuming. I think someone wanted to restore that scripts be sh complient when they claim to use it, so dash became the default.

Kubuntu 10.04 LTS. By the way, the line system("mkdir -p " ~ path); comes from project DDebber. It's a cool project, and i have make succesfully deb files for dmd 2.041.
Mar 20 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 18 Mar 2010 09:28:06 -0400, noboy <nobody nowhere.com> wrote:

 I was little bit surprise because
 mkdir -p dmd-2/usr/{bin,lib,src/phobos2,share/man
 do the right thing.

When you do that, you are using your shell. The shell actually does the argument expansion, not mkdir. So the question to answer is, does system use the shell or just call mkdir directly. According to my man page, using system("cmd") is equivalent to doing /bin/sh -c cmd. On my system doing this: /bin/sh -c 'mkdir -p /testdir/{a,b,c}' results in the desired behavior. The single quotes force the shell I'm currently running *not* to expand the arguments, but pass them directly to /bin/sh as one string. I would expect that system would execute the same command. I would guess on my system that your code would work properly, but I'm not sure. What you need to find out is what /bin/sh actually is on your system. Maybe it is a shell that does not understand how to expand the {a,b,c} term. IIRC, /bin/sh usually is a link to bash, but I think on some systems, bash behaves differently if it's called via /bin/sh.
 But if i make
 mkdir -p "dmd-2/usr/{bin,lib,src/phobos2,share/man"
 it's wrong.

 So i have think the system command wrap quotes about the command.

I don't think this is what's happening. -Steve
Mar 18 2010