better error reporting for `cabal v2-run -- --opts`

[nomeata]

When I run

cabal new-run

it (usually) picks a sensible target to run. But then I want to pass arguments, like

cabal new-run -- --help

and I get

$ cabal new-run -- --help
cabal: Unknown target '--help'.
There is no component '--help'.
The project has no package '--help'

I see how that can be justified if -- means “treat the rest as non-option arguments”, but I find “pass the rest to the called function” more usefull.

[nomeata]

(This is, I think, with cabal-install revision 8adf3f2)

[fgaz]

But what if your executable starts with -? I'm only half joking

[nomeata]

In that corner case you prefix them with the package name ( cabal new-run pkg:-horrible-exe-name -- --help)?

[hvr]

@nomeata btw, if there's only one executable in scope (which is the very case where cabal doesn't require you to specify a target), you can also say

cabal v2-run exes -- --help

and exes will be expanded to the set of executables which has size one... :-)

[nomeata]

Will try to keep it in mind. But it’s not particularly discoverable :-)

[jcguu95]

I set 6am to be the start of a new day. Waking up at 5:30, it did log data, but stopped at 6:00am.

[phadej]

I don't see any reasonably way to help resolve the ambiguities.

In particular I don't like an idea to make our command line parser aware of -- so we could do
interpret as:

cabal v2-run                     => cabal v2-run exes
cabal v2-run     -- --help       => cabal v2-run exes -- --help
cabal v2-run foo                 => cabal v2-run foo
cabal v2-run foo -- --help       => cabal v2-run foo -- -help
cabal v2-run     -- foo --help   => cabal v2-run exes -- foo --help  !!!

where the last case doesn't feel right either. Currently the interface is

v2-run [target [opts]]

and -- cannot be taken into account in command line grammar.

Note: foo could be the subcommand of executable, e.g. site watch for hakyll
sites. Then

cabal v2-run site watch
cabal v2-run -- site watch

would be different. That's confusing as well.

I'm closing this, as I don't see a way this can be resolved.

[BebeSparkelSparkel]

perhaps just add to the error message on the proper syntax of what the user is trying to accomplish.

$ cabal run -- arg

cabal: If you meant for arg to be an executable argument then use "cabal run . -- arg". Otherwise, cannot run the package arg, it is not in this project (either directly
or indirectly). If you want to add it to the project then edit the
cabal.project file.

[jneira]

the exes special target is documented here: https://cabal.readthedocs.io/en/latest/cabal-commands.html?highlight=exes#target-forms
so i think the action to close this would be improve the error message as proposed above (Uhttps://github.com//issues/6074#issuecomment-710067579)