Comment #0 by timothee.cour2 — 2015-06-20T00:34:28Z
dmd -of/tmp/foo/bar/z01 main.d
creates /tmp/foo/bar/z01 even if parent dir doesn't exist (ie it must call the equivalent of mkdir -p).
that's error prone and dangerous. just fail early if parent dir doesn't exist, it's easy enough for user to create the dir if he really intended to as part of his script. Or at least make it a non-default option.
Likewise, other flags need to be checked (eg -od etc)
Comment #1 by dlang-bugzilla — 2015-06-23T21:30:45Z
> that's error prone and dangerous.
Why?
Comment #2 by timothee.cour2 — 2015-06-25T06:42:35Z
(In reply to Vladimir Panteleev from comment #1)
> > that's error prone and dangerous.
>
> Why?
* the shell/command line is more error prone than using a library API and it's easy for errors to creep in resulting in unwanted entire hierarchy structure being created (that's what made me file this bug btw)
* it's easy enough for user to create the base directory first
* most importantly: that's the standard unix way. Pretty much NO unix tool works the way dmd does, and for good reason:
eg, 'clang++ -c main.cc -o /tmp/d32/foo3/bar.o ' fails if /tmp/d32/foo3/ doesn't exist
mkdir requires -p to be recursive
same with cp, ln, etc etc
Comment #3 by dlang-bugzilla — 2015-08-31T10:11:33Z
Good points. However, at this point it's unlikely the current behavior will be changed (unless e.g. new arguments surface that show this to be a security problem) as it might break existing build scripts.
Comment #4 by luis — 2015-08-31T17:00:40Z
(In reply to Vladimir Panteleev from comment #3)
> Good points. However, at this point it's unlikely the current behavior will
> be changed (unless e.g. new arguments surface that show this to be a
> security problem) as it might break existing build scripts.
If this were to be changed, would you include a -p switch to allow deep path creations? If so, then how about outputting a warning when a deep path is created and -p was not specified? Later, this could become an error, instead of a warning.
Comment #5 by timothee.cour2 — 2017-01-08T02:54:02Z
(In reply to Luís Marques from comment #4)
> (In reply to Vladimir Panteleev from comment #3)
> > Good points. However, at this point it's unlikely the current behavior will
> > be changed (unless e.g. new arguments surface that show this to be a
> > security problem) as it might break existing build scripts.
>
> If this were to be changed, would you include a -p switch to allow deep path
> creations? If so, then how about outputting a warning when a deep path is
> created and -p was not specified? Later, this could become an error, instead
> of a warning.
That would be a good deprecation path, yes.
Comment #6 by razvan.nitu1305 — 2022-02-17T13:02:31Z
This is not a critical issue. At best an enhancement request.
Comment #7 by robert.schadek — 2024-12-13T18:43:25Z