cabal v2-run requires a TARGET when passing flags

[toonn]

Describe the bug The documentation states a TARGET only has to be specified if necessary to disambiguate. However, if you want to pass a flag to an executable it seems TARGET is non-optional.

To Reproduce Steps to reproduce the behavior:

# In a project with a single executable which accepts the `-t` flag:
$ cabal v2-run -- -t

Please use version-prefixed commands (e.g. v2-build or v1-build) to avoid ambiguity.

Expected behavior Since there's only a single possible target the documentation suggests it does not need to be specified. Either the documentation or the functionality should be updated.

[toonn]

@fgaz, mentioning you as requested.

[fgaz]

The fix is simple, but then we'd have to drop support for the currently supported but not advertised:

cabal run --some-cabal-flag -- target --some-target-flag

ie. we'd have to change the meaning of -- from "stop the parsing of options" to "stop the parsing of (cabal) arguments".

So I guess it comes to which one is more valuable: the current meaning (and backward compatibility) or @toonn's one?

A point in favor of the current meaning is that the above invocation just works, while with the other meaning it could complain about multiple targets (or run the wrong target?), and it's easy to mistakenly put the -- before the target since most programs (ex. sudo) accept that form too.

@phadej?

[toonn]

I think you have those meanings flipped around maybe? Afaik -- usually means "stop interpreting things that start with a -."

Imo this is definitely a valid concern. I'm not sure what the right decision is. I ran into this specifically when helping a beginner. It is somewhat strange to me that the target would be optional only if you don't want to pass any flags or options to it. So at least the documentation needs to change to point this out if the behavior isn't changed.

Maybe an alternative sentinel can be used to really mean "pass whatever follows to the target", i.e., --- or something. Then -- can continue to mean "these may look like options, but they're not options."

[fgaz]

I think you have those meanings flipped around maybe

I did, fixed :sweat_smile:

[dunrix]

*bump*

Yeah, this issue struck me too. All of any imaginable toolchain I've ever met, either for programming languages or for (POSIX) administration utilities, use of -- separator as a way to pass all following arguments to processed target is notorious. Explicitly stated or default, no exception.

$ cabal help run Run an executable.

Usage: cabal run [TARGET] [FLAGS] [-- EXECUTABLE_FLAGS]

Target is optional, executable_flags likewise, so where is the problem?

[andreasabel]

Me too. When

cabal run

invokes the only executable in the package without arguments, I expect

cabal run -- args

to pass args to just this executable.

Btw. I also tried cabal run -- -- args but this complains about unknown target '--'.

[fgaz]

Two points in favour of the proposed behaviour:

• as @dunrix points out, the help is inconsistent with the current behaviour: it explicitly says that only executable flags go after the --

  Usage: cabal run [TARGET] [FLAGS] [-- EXECUTABLE_FLAGS]

• the current behaviour combined with the cabal run script.hs feature can be confusing: see https://discourse.haskell.org/t/solved-cabal-v2-run-and-fake-package-0-infinite-loop/4872?u=fgaz

[chreekat]

All of any imaginable toolchain I've ever met, either for programming languages or for (POSIX) administration utilities, use of -- separator as a way to pass all following arguments to processed target is notorious.

@dunrix your use of the word "notorious" makes it hard for me to know if you're arguing for or against any changes. Did you mean "well-known"?

---

I'm in favor of -- separating cabal arguments from TARGET arguments. That's what stack does, and I've always found it intuitive and useful: "Everything after -- on the command line is interpreted as a command line argument to be passed to what is run, other than a first argument recognised as the name of an executable component of a project package [stack run docs]." Most packages I've ever worked on only have one executable target, anyway.