Re: Changing our help messages to mention --foo options instead of -foo options
On Fri, Oct 24, 2014 at 6:31 AM, Benjamin Smedberg wrote: >> >> Some of our options are handled elsewhere, via ad hoc >> code that is generally less flexible. > > Can you point me to this? Pretty much any code handling command lines should > either be use the nsAppRunner code or using the nsICommandLine APIs. Patch 1 in bug 1080302 covers four of these places. * http://dxr.mozilla.org/mozilla-central/source/toolkit/xre/nsNativeAppSupportWin.cpp#336 handles -console and /console. My patch adds --console support. * http://dxr.mozilla.org/mozilla-central/source/webapprt/gtk/webapprt.cpp#329 handles -profile and -remove. My patch adds --profile and --remove support. * http://dxr.mozilla.org/mozilla-central/source/webapprt/win/webapprt.cpp#447 handles -profile and /profile. My patch adds --profile support. * http://dxr.mozilla.org/mozilla-central/source/widget/windows/winrt/MetroContracts.cpp#106 handles -url. My patch adds --url and /url support. There's also http://dxr.mozilla.org/mozilla-central/source/mobile/android/base/GeckoApp.java#1151, which handles -P and --profile in a horrendous way. I didn't have to change it because it already matches single- and double-dash forms, AFAICT, but that appears to be by luck rather than design. >> Another obvious >> follow-up is to drop support for -foo options, but that's *much* harder, so I >> haven't even bothered filing a bug about that. > > I don't think we should ever do this. It would break some existing user for no > apparent benefit other that consistency with "standard" command-line > conventions. Fair enough. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Changing our help messages to mention --foo options instead of -foo options
On 10/23/14 9:20 PM, Nicholas Nethercote wrote: Hello. Our command-line option handling is *interesting*. Did you know that: - our options work in -foo form and --foo form; - they are case-insensitive; - this holds for both short options (e.g. -h) and long options (e.g. -help). I did in fact know this, but I may be one of the few. This dates back to the pre-FF1.0 days where we had different startup paths for windows/mac/linux each of which had their own arg handling code with different expectations. My decision was to accept all the different varieties of argument and treat them equivalently. At least, all this is true for the options that are processed via the main option-processing code. Some of our options are handled elsewhere, via ad hoc code that is generally less flexible. Can you point me to this? Pretty much any code handling command lines should either be use the nsAppRunner code or using the nsICommandLine APIs. Before I land those patches, I thought I would ask here if anyone can see any reason not to do this. Remember, it's not a functional change -- both -foo and --foo options will still work -- it's just a documentation change. Doesn't matter to me. Another obvious follow-up is to drop support for -foo options, but that's *much* harder, so I haven't even bothered filing a bug about that. I don't think we should ever do this. It would break some existing user for no apparent benefit other that consistency with "standard" command-line conventions. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Changing our help messages to mention --foo options instead of -foo options
On Thu, Oct 23, 2014 at 6:20 PM, Nicholas Nethercote wrote: > > > So, for example, the following are all equivalent: -h, -H, --h, --H. On Windows, /h and /H are also equivalent. > As are -help, --help, -HELP, --HeLp. Again on Windows, /help, /HELP, /HelP, etc. are equivalent. As are /-help, /-HELP, etc., though I suspect this is not intentional. (See CheckArg() in nsAppRunner.cpp for the code.) Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Changing our help messages to mention --foo options instead of -foo options
Hello. Our command-line option handling is *interesting*. Did you know that: - our options work in -foo form and --foo form; - they are case-insensitive; - this holds for both short options (e.g. -h) and long options (e.g. -help). So, for example, the following are all equivalent: -h, -H, --h, --H. As are -help, --help, -HELP, --HeLp. At least, all this is true for the options that are processed via the main option-processing code. Some of our options are handled elsewhere, via ad hoc code that is generally less flexible. Despite this flexibility, in all our help messages we only mention the -foo form for long options. But -foo options are kind of archaic and --foo options are much more standard these days. So it would be nice to switch to them. In particular, it would avoid messes like |mach run| having a mixture of -foo and --foo options. In bug 1080302 there are r+'d patches for converting all our help messages and almost all of our comments from -foo form to --foo form. (And also for making some of the ad hoc option handling more consistent with the main option handling, and also for making |mach run| use --foo options throughout.) Before I land those patches, I thought I would ask here if anyone can see any reason not to do this. Remember, it's not a functional change -- both -foo and --foo options will still work -- it's just a documentation change. An obvious follow-up is to convert our code to use --foo options instead of -foo options, which is bug 1088430, and slightly riskier. Another obvious follow-up is to drop support for -foo options, but that's *much* harder, so I haven't even bothered filing a bug about that. Thanks. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
