Command Line Switches: Addition of short switches for their long counterparts

[elliott94]

Is your feature request related to a problem? Please describe.

NVDA offers several command line switches that can be used. Some of these switches offer both short and long versions - could we possibly consider adding short versions of the following? This would have the potential to speed up the workflows of power users/system admins when manually typing out these switches at regular intervals:

--disable-addons - consider adding a "-noaddons" switch to perform this task

--debug-logging - consider adding a "-debuglog" switch to perform this task

--no-logging - consider adding a "-nolog" switch to perform this task

--no-sr-flag - consider adding a "-noflag" switch to perform this task

Describe the solution you'd like

Describe alternatives you've considered

Additional context

[XLTechie]

NVDA offers several command line switches that can be used. Some of these switches offer both short and long versions - could we possibly consider adding short versions of the following? This would have the potential to speed up the workflows of power users/system admins when manually typing out these switches at regular intervals:

I very much agree with the concept here. Alternate short forms should be available for everything possible.

--disable-addons - consider adding a "-noaddons" switch to perform this task

Regarding this and your other suggestions: that breaks the getopt/GNU standard of only using a single dash for single letter options. The reason that is a thing, is a use case like the following:

You have options: --disable-addons (-d) --debug-logging (-D)

You could then do:

nvda -D -d

But, if you're in a real hurry you could do:

nvda -Dd

If you're passing a boatload of options, that latter format can be helpful. It also doesn't work at all if multi-letter options are allowed after a single dash.

I don't actually know if the option combining method works with NVDA's option processor, but standards exist for a reason, and that's the reason for that one.

So if you're proposing single hyphen options, which I fully support, please consider proposing only single-letter versions.

[elliott94]

Makes perfect and logical sense - thank you too for adding info about these standards. :) So how about:

--disable-addons - consider adding a "-d" switch to perform this task

--debug-logging - consider adding a "-D" switch to perform this task

--no-logging - consider adding an "-n" switch to perform this task

--no-sr-flag - consider adding an "-N" switch to perform this task

Depending on feedback, happy to edit the initial description with these alternative switches.

[XLTechie]

First, NVDA does in fact support option combining as I mentioned it might (-Dd), according to user guide section 16.1.

Second, I'm not really clear on the value of the --no-logging option. That should be doable with "-l 0" or "-l 255" or something, even if it isn't now. So I'm not sure I support a short option for that, since I don't see the need for having the switch at all.

Third, I think the --portable-path=PORTABLEPATH switch should go away, and the portable creation options should require a pathspec.

Lastly, here is my list of suggestions for short options, incorporating those of yours with which I agree:

SHORT	LONG
-d	--disable-addons
-D	--debug-logging
-R	--no-sr-flag
-i	--install
-I	--install-silent
-E	--enable-start-on-logon
-p	--create-portable
-P	--create-portable-silent

Note regarding -E: it is an uncommon option, so I capitalized it. Rather keep the lowercase for something more valuable.

@feerrenrut @josephsl : thoughts on the reasonableness of any of this? I come from a Linux background, so it feels wrong to me if there aren't short switches for the vast majority of the CLI options.

[feerrenrut]

I would prefer only adding short switches for commonly typed options. Adding short form for all options doesn't seem to solves any specific issue. Short form is useful for regularly typed options. If an admin is configuring a script or shortcut, it would be more sensible to use the long form since it is self documenting the intent.