-
-
Notifications
You must be signed in to change notification settings - Fork 606
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use "" (empty argument) to indicate no file after -run #7927
Conversation
Thanks for your pull request and interest in making D better, @marler8997! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please see CONTRIBUTING.md for more information. If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment. Bugzilla references
|
2acbd92
to
13026a7
Compare
test/compilable/diag13110a.sh
Outdated
function echorun() { | ||
echo $@ > ${output_file} | ||
$@ | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the motivation for this echorun
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It runs the command and logs the command to the output_file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Logging the output is simple with tee
:
| tee ${output_file} | ...
If you want to log all arguments, -x
is your friend.
You can even dump the entire debug stream to the output_file:
exec 42> ${output_file}
export BASH_XTRACEFD=42
(42
is arbitrary)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it logs the command, not the output of the command...how would you use tee
for that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NOTE: I removed this in favor of #7928 and possible future improvements to support "logging by default" to BASH tests.
test/compilable/diag13110b.sh
Outdated
$@ | ||
} | ||
|
||
out=$(echorun ${DMD} -conf= -m${MODEL} compilable/extra-files/echoargs.d -run a b c) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you use -conf=
, Phobos shouldn't be available...
test/compilable/diag13110b.sh
Outdated
} | ||
|
||
out=$(echorun ${DMD} -conf= -m${MODEL} compilable/extra-files/echoargs.d -run a b c) | ||
[ "$out" == "a b c" ] || exit 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... | grep -q "a b c"
would work too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like grep
works better. Windows keeps the trailing \r
which makes ==
fail.
13026a7
to
8b936fa
Compare
423e49f
to
3116b26
Compare
3116b26
to
81f7eb5
Compare
I don't object to this feature, and I may support it, but only after I get clarification on the following, I'm seeing a lack of principled design in our tools and CLI. There appears to be feature overlap between what My understanding is @WalterBright is the keeper of the command line arguments, and I'd like for him to weigh in on what his design principles and intent are. Is |
@JinShil |
Was looking through the commits/PRs to see when |
5b70ea2
to
813e322
Compare
AFAICT is @CyberShadow the expert on command line questions. Two small points
|
Thanks for the ping. This looks like a misuse of the general convention of what Consider, for example, that you want to compile some files that are in a directory that starts with
How about an empty string? It's somewhat esoteric, but it should be no problem to use in shell scripts etc. |
Fix issue 18477
Ah ok. I see that if we used |
813e322
to
d6ae473
Compare
d6ae473
to
87aed09
Compare
empty arg is not standard (does any other tool uses that?) |
As mentioned we already have one precedent in our core tools:
Hmm I was just thinking about this and if we go with optionally supporting BTW there is yet another thread about people getting confused that -run is position-dependent: https://forum.dlang.org/thread/ddyuldfgstkifmyltbda@forum.dlang.org |
@CyberShadow what do you think of @wilzbach's idea? Here's the 2 options we have right now: Option 1 (Current PR)use "" to indicate "no file". -run must appear after all other compiler args
Option 2 (@wilzbach idea)use -- to separate compiler args and program args, -run can appear anywhere in compiler args
|
Well, I don't have a strong opinion on this, but I generally wouldn't call Dub as a pinnacle of good design. Unless there exists wide-spread precedent that I'm not aware of, for all we know, its use of |
@timotheecour messaged me on slack to point out that @wilzbach's idea breaks the use case where a program would have used
This would have 2 different meanings before and after implementing This incompatibility, along with the fact that this PR can be "orthogonal" to @wilzbach's idea makes me think this PR is justifiable on it's own. |
@timotheecour suggested another variation would be to use an option like
I'm fine with this. |
advantage of
or:
|
Note that this is currently valid syntax: $ echo 'module args; void main() {}' > -args.d
$ touch mod.d
$ dmd mod -run -args foo # OK |
interesting point, i thought dmd would reject file names starting with |
Hmm, after looking at Custom flags after
|
This is not a good idea because at some point we may want to implement |
I agree with your points but the change you propose breaks compatibility. If we make any changes to For your proposed interface, we would probably need a new option, maybe something like If we decide to keep |
The use of |
So as rdmd doesn't look like it's getting support for the new #!/bin/bash
DMD="${DMD:-dmd}"
file="$1"
other_flags=()
shift
for arg in "$@" ; do
if [ -f "$arg" ] ; then
other_flags+=("$file")
file="$arg"
else
other_flags+=("$arg")
fi
done
"$DMD" -i "${other_flags[@]}" -run "${file}" (combine this with |
Cleaning up old PRs that aren't going anywhere |
Fix issue 18477
Currently,
-run
must appear at the end of the command line and be followed by a single source file and then the arguments to pass to the compiled program, i.e.This interface makes it difficult for tools to take a list of source files and pass them to dmd with the
-run
option, i.e.For myself and others, this interface is confusing. Having to put exactly one source file after
-run
followed by the compiled program arguments is unintuitive. It requires that one of the files be "split up" from the rest and moved behind the-run
argument. I'm not sure why it was designed this way, my best guess is that it is supposed to indicate which source file has themain
function, but DMD already knows this which violates the DRY principle, and furthermore, DMD doesn't enforce this requirement.It's too late to change this interface and break tools that use it this way, however, I propose we support
--
as a special argument after-run
to indicate "no file".This allows all source files to be given before
-run
while maintaining compatibility with the original interface. It's also unambiguous. Note that supporting a special argument to mean "no file" would be required even if we wanted to make the file argument completely optional (i.e.dmd foo.d -run arg1 arg2...
). For example, if we just made the file optional, then we would need to define a mechanism to determine when the first argument after-run
is a file meant for the compiler. Assume that "mechanism" is when the argument has a.d
extension. But then when we want to pass an argument with a.d
extension as the first argument to the compiled program, we will need to come up with a mechanism to negate the original "mechanism", which is why we would still need to define a special argument to indicate "no file". So in any case, if we want to support this and be backwards compatible, we must support a special argument that means "no file".So just note that this change improves some use cases for
-run
without superseding future improvements, such as making the file after-run
optional or creating a new command-line option that does not take a file but only arguments to the command-line program. In other words, it is the minimum change set needed to make-run
more usable without breaking compatibility.