✨ Short option for `--no-mod` such as `-M`
What are you trying to do?
Today if you want dagger aka dagger shell to ingore the possible module in the local dir, you need to add --no-mod, there should be a shorter option available.
I propose -M since today we have -E meaning --no-exit, -M would signify --no-mod(ule)
OPTIONS
-c, --code string Command to be executed
-d, --debug Show debug logs and full verbosity
-i, --interactive Spawn a terminal on container exec failure
--interactive-command string Change the default command for interactive
mode (default "/bin/sh")
-m, --mod string Path to the module directory. Either local
path or a remote git repo
-E, --no-exit Leave the TUI running after completion
--no-mod Don't load module during shell startup
(mutually exclusive with --mod)
--progress string Progress output format (auto, plain, tty)
(default "auto")
-q, --quiet count Reduce verbosity (show progress, but clean
up at the end)
-s, --silent Do not show progress at all
-v, --verbose count Increase verbosity (use -vv or -vvv for more)
-w, --web Open trace URL in a web browser
Why is this important to you?
No response
How are you currently working around this?
No response
This has already been released in v0.16.3, but with the shorthand -n.
Let me know if you want to get consensus on changing it to -M.
Something consistent would make sense, I chose -M because of the -E precedent and the fact the -n usually takes a number (e.g. of lines) in most CLI tools
Additionally we already have one other --no-xxxxx command which could also claim -n in someone's mind. Though perhaps if -n for --no-mod is used a lot more than --no-exit in an interactive way, then perhaps it makes sense to give it to --no-mod.
cc @shykes
Mm, agreed with @jpadams here. -n for "no" is too broad, I think -M is really neat as an inverse, and lets us be consistent if we decide to keep expanding the number of inverse parameters.
Works for me! @helderco not too late to change to -M?
I actually think -n has better ergonomic for such a (I expect) heavily used flag. -M requires Shift, and it puts a screaming "M" when what you want is the exact opposite. It doesn't give me the same feeling as not a double negative. While -n in my mind is saying "just don't". Feels symmetrical/close to -m too. I think since -m is so heavily used, I'm good with reserving -n for it's opposite.
I've seen it be used for other things as well in other CLIs, but I think that's no reason to assume it'll cause confusion here. In echo it's for "no newline". In uv it's for --no-cache. Notice that uv has a bunch of other --no- flags too, and it also has some uppercase like -U for upgrade.
There's only one precedent with -E but it doesn't mean it was intentionally trend setting and I don't think it has to be. If -n doesn't make sense for one --no- flag for the above discussed reasons, then it shouldn't be used for any flag, --no- or not. I think that's unfortunate. It's also limiting if uppercase shorthands mean negation because it can't be used with affirmative flags which could get around an already used letter or give symmetry to a pair of flags (e.g., -p and -P in docker run are for publishing a list vs publishing all).
I'm not aware of any CLI that has the upper case shorthand convention for --no-, does anyone know any?
That's my 2c, but if the consensus is to change to -M then we have it until release tomorrow. It's a trivial PR. Will also need to update docs, but there's not much on it yet so it's not too late.
I'm not aware of any CLI that has the upper case shorthand convention for
--no-, does anyone know any?
There's ssh -t|-T, which we copied in docker: docker run -t|-T.
I'm not aware of any CLI that has the upper case shorthand convention for
--no-, does anyone know any?There's
ssh -t|-T, which we copied in docker:docker run -t|-T.
Neither ssh nor docker use uppercase shorthand flags as a convention for shorthanding --no- flags only (or at least for general negation). That's what I meant.
I'm also worried about claiming -n for a single instance of --no-.
Note that I'm not claiming that capitalizing short flags always implies --no-. Just that it's a somewhat discoverable alternative to claiming -n for a single --no-.
I've also seen -n used for --no-interaction i.e. approve all "are you sure?" prompts. We've just started adding the beginnings of support for that with the LLM prompt so it might come up in the short term.
I don't think you'll ever find consistently across the full suite of common CLIs, but capitalizing (or lowercasing) to invert default behavior does have precedent. And it's something we can at least be internally consistent on.
Here's one from ripgrep:
-n, --line-number
Show line numbers (1-based).
This is enabled by default when stdout is connected to a tty.
This flag can be disabled by -N/--no-line-number.
-N, --no-line-number
Suppress line numbers.
Line numbers are off by default when stdout is not connected to a tty.
Line numbers can be forcefully turned on by -n/--line-number.
Amusingly grep does the opposite here, maybe because the default is contextual:
-H, --with-filename
Print the file name for each match. This is the default when there is more than one file to search. This is a GNU extension.
-h, --no-filename
Suppress the prefixing of file names on output. This is the default when there is only one file (or only standard input) to search.
Here's one from fd:
-I, --no-ignore
Show search results from files and directories that would otherwise be ignored by
'.gitignore', '.ignore', '.fdignore', or the global ignore file, The flag can be
overridden with --ignore.
And another from curl:
-N, --no-buffer
Disables the buffering of the output stream. In normal work situations, curl uses a standard buffered output stream that has the effect that it outputs the data in chunks, not necessarily exactly when the data arrives. Using
this option disables that buffering.
And ls:
-u with -lt: sort by, and show, access time; with -l: show access time and sort by name; otherwise: sort by access time, newest first
-U do not sort; list entries in directory order
Note that I'm not claiming that capitalizing short flags always implies
--no-. Just that it's a somewhat discoverable alternative to claiming-nfor a single--no-.
Yeah, that was my main concern (first sentence).
I don't think you'll ever find consistently across the full suite of common CLIs, but capitalizing (or lowercasing) to invert default behavior does have precedent. And it's something we can at least be internally consistent on.
When I mentioned precedent (in other CLIs) I was only concerned about any that reserved capitalized shorthands only for --no- flags. Not an issue otherwise.
I've also seen
-nused for--no-interactioni.e. approve all "are you sure?" prompts. We've just started adding the beginnings of support for that with the LLM prompt so it might come up in the short term.
This part is still a sticky point for me. If -n can't be used for --no-mod, which is something that's pretty real for our own CLI, why would we use it for another --no- flag just because it's been used by another CLI? What about --no-cache for example? I'm not convinced there's a "convention" for -n in CLIs.
In any case, I'll make a PR to change to -M as it seems there's consensus on it. 👍
Just piling up on the consensus for using -M, it sounds more consistent. 👍
This part is still a sticky point for me. If
-ncan't be used for--no-mod, which is something that's pretty real for our own CLI, why would we use it for another--no-flag just because it's been used by another CLI? What about--no-cachefor example? I'm not convinced there's a "convention" for-nin CLIs.
@helderco Oh sorry, me either - I didn't meant to suggest using -n for --no-interaction because of some other CLI - just that people might guess that's what -n does if they're coming from any CLI that had -n mean --no-<some-common-thing-that-we-also-support>. And if the desire for --no-interaction came before the desire for shorthand for --no-mod we might have chosen -n for it and be having the same bikeshed we're having now. 😄 (Since it's also a common ask the moment you add confirmation prompts.)
(Since it's also a common ask the moment you add confirmation prompts.)
True 😄