bug#24949: Command-line argument parsing: named daemons

bug#24949: Command-line argument parsing: named daemons

[Glenn Morris]

Package: emacs
Severity: minor
Version: 25.1

This starts a daemon with a server named "FOO":
   emacs -Q --daemon=FOO

(This usage is documented in the "Initial Options" appendix of the
manual, but not mentioned in --help, or the man page.)


But this very similar form does not work (it starts an un-named daemon and
visits file "FOO"):
   emacs -Q --daemon FOO

Compare with something like "--chdir /tmp", where both forms (with and
without "=") work.

This is due to the fragility of the Emacs argument parsing code,
which seems pretty home-grown. In particular, I guess it is because
struct standard_args has --daemon listed as taking no arguments.
Options with optional arguments don't seem to be handled.

There is a 20-year old comment in emacs.c:

   Too bad we can't just use getopt for all of this, but we don't have
   enough information to do it right.

Perhaps standard argument parsing libraries have improved since then...?

bug#24949: Command-line argument parsing: named daemons

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Tue, 15 Nov 2016 17:25:46 -0500
> 
> Package: emacs
> Severity: minor

I think it should be wishlist.

> This starts a daemon with a server named "FOO":
>    emacs -Q --daemon=FOO
> 
> (This usage is documented in the "Initial Options" appendix of the
> manual, but not mentioned in --help, or the man page.)
> 
> 
> But this very similar form does not work (it starts an un-named daemon and
> visits file "FOO"):
>    emacs -Q --daemon FOO
> 
> Compare with something like "--chdir /tmp", where both forms (with and
> without "=") work.

I wouldn't expect it to work, since long options are documented to
need the equals sign.

> There is a 20-year old comment in emacs.c:
> 
>    Too bad we can't just use getopt for all of this, but we don't have
>    enough information to do it right.
> 
> Perhaps standard argument parsing libraries have improved since then...?

I think that comment is not about the parsing libraries, I think it's
about the fact that submitting the information getopt needs is
difficult or impossible in Emacs, given some of our options.

bug#24949: Command-line argument parsing: named daemons

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

Eli Zaretskii <eliz@gnu.org> schrieb am Mi., 16. Nov. 2016 um 04:40 Uhr:

>
> > This starts a daemon with a server named "FOO":
> >    emacs -Q --daemon=FOO
> >
> > (This usage is documented in the "Initial Options" appendix of the
> > manual, but not mentioned in --help, or the man page.)
> >
> >
> > But this very similar form does not work (it starts an un-named daemon
> and
> > visits file "FOO"):
> >    emacs -Q --daemon FOO
> >
> > Compare with something like "--chdir /tmp", where both forms (with and
> > without "=") work.
>
> I wouldn't expect it to work, since long options are documented to
> need the equals sign.
>

This is incredibly surprising and also inconsistent with the man page,
which doesn't have equals signs for most options. Let's just document what
everybody expects, i.e. that all options work with and without equals sign,
and with one or two dashes.

[-- Attachment #2: Type: text/html, Size: 1304 bytes --]

bug#24949: Command-line argument parsing: named daemons

[Eli Zaretskii]

> X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_50,
> 	FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,T_DKIM_INVALID
> 	autolearn=disabled version=3.3.2
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Wed, 06 Sep 2017 17:33:33 +0000
> Cc: 24949@debbugs.gnu.org
> 
>  > Compare with something like "--chdir /tmp", where both forms (with and
>  > without "=") work.
> 
>  I wouldn't expect it to work, since long options are documented to
>  need the equals sign.
> 
> This is incredibly surprising and also inconsistent with the man page, which doesn't have equals signs for
> most options. Let's just document what everybody expects, i.e. that all options work with and without equals
> sign, and with one or two dashes. 

Why would we want to do that?  Documentation should describe the
software, not our wishes.  If we want to change how the software
works, we should change the code first, and only after that change the
documentation.  Am I missing something here?

bug#24949: Command-line argument parsing: named daemons

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]

Eli Zaretskii <eliz@gnu.org> schrieb am Mi., 6. Sep. 2017 um 20:05 Uhr:

> > X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_50,
> >
>  FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,T_DKIM_INVALID
> >       autolearn=disabled version=3.3.2
> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Wed, 06 Sep 2017 17:33:33 +0000
> > Cc: 24949@debbugs.gnu.org
> >
> >  > Compare with something like "--chdir /tmp", where both forms (with and
> >  > without "=") work.
> >
> >  I wouldn't expect it to work, since long options are documented to
> >  need the equals sign.
> >
> > This is incredibly surprising and also inconsistent with the man page,
> which doesn't have equals signs for
> > most options. Let's just document what everybody expects, i.e. that all
> options work with and without equals
> > sign, and with one or two dashes.
>
> Why would we want to do that?  Documentation should describe the
> software, not our wishes.  If we want to change how the software
> works, we should change the code first, and only after that change the
> documentation.  Am I missing something here?
>

For almost all arguments all four variants (-foo bar, --foo bar, -foo=bar,
--foo=bar) appear to work, for long and for short options. Either we should
document that they work (that's what everybody expects by now), or turn the
unwanted versions into explicit errors.
We should generally change the code and the documentation at the same time,
to make sure they are consistent.

[-- Attachment #2: Type: text/html, Size: 2059 bytes --]

bug#24949: Command-line argument parsing: named daemons

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Wed, 06 Sep 2017 18:32:18 +0000
> Cc: rgm@gnu.org, 24949@debbugs.gnu.org
> 
>  Why would we want to do that? Documentation should describe the
>  software, not our wishes. If we want to change how the software
>  works, we should change the code first, and only after that change the
>  documentation. Am I missing something here?
> 
> For almost all arguments all four variants (-foo bar, --foo bar, -foo=bar, --foo=bar) appear to work, for long and
> for short options. Either we should document that they work (that's what everybody expects by now), or turn
> the unwanted versions into explicit errors. 
> We should generally change the code and the documentation at the same time, to make sure they are
> consistent.

I agree with the last sentence.  It's almost exactly what I said.  The
rest of what you write sounds like a contradiction to me, as currently
the only inconsistency I see is that the emacs.1 man page creates a
wrong impression that omitting the = would work.

bug#24949: Command-line argument parsing: named daemons

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I agree with the last sentence.  It's almost exactly what I said.  The
  > rest of what you write sounds like a contradiction to me, as currently
  > the only inconsistency I see is that the emacs.1 man page creates a
  > wrong impression that omitting the = would work.

I agree.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

bug#24949: Command-line argument parsing: named daemons

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]

Eli Zaretskii <eliz@gnu.org> schrieb am Mi., 16. Nov. 2016 um 04:40 Uhr:

> > From: Glenn Morris <rgm@gnu.org>
> > Date: Tue, 15 Nov 2016 17:25:46 -0500
> >
> > Package: emacs
> > Severity: minor
>
> I think it should be wishlist.
>
> > This starts a daemon with a server named "FOO":
> >    emacs -Q --daemon=FOO
> >
> > (This usage is documented in the "Initial Options" appendix of the
> > manual, but not mentioned in --help, or the man page.)
> >
> >
> > But this very similar form does not work (it starts an un-named daemon
> and
> > visits file "FOO"):
> >    emacs -Q --daemon FOO
> >
> > Compare with something like "--chdir /tmp", where both forms (with and
> > without "=") work.
>
> I wouldn't expect it to work, since long options are documented to
> need the equals sign.
>

I've just re-checked this. The manual states: "When a long option takes an
argument, you can use either a space or an equal sign to separate the
option name and the argument.  Thus, you can write either
@samp{--display sugar-bombs:0.0} or @samp{--display=sugar-bombs:0.0}. "

So it's even documented that both forms should work.
We could either fix the "daemon" arg to match the documentation, or
slightly change the manual to state that the space variant is only possible
if the argument is mandatory (e.g. replace "takes" with "requires").

[-- Attachment #2: Type: text/html, Size: 1949 bytes --]

bug#24949: Command-line argument parsing: named daemons

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sun, 07 Jan 2018 22:44:26 +0000
> Cc: Glenn Morris <rgm@gnu.org>, 24949@debbugs.gnu.org
> 
> I've just re-checked this. The manual states: "When a long option takes an
> argument, you can use either a space or an equal sign to separate the
> option name and the argument.  Thus, you can write either
> @samp{--display sugar-bombs:0.0} or @samp{--display=sugar-bombs:0.0}. "
> 
> So it's even documented that both forms should work.
> We could either fix the "daemon" arg to match the documentation, or slightly change the manual to state that
> the space variant is only possible if the argument is mandatory (e.g. replace "takes" with "requires").

The manual actually already states that ("when a long option takes an
argument"), but I agree it would be good to clarify that as you
propose in the latter alternative.

Thanks.

bug#24949: Command-line argument parsing: named daemons

[Noam Postavsky]

tags 24949 fixed
close 24949 26.3
quit

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philipp Stephani <p.stephani2@gmail.com>

>> We could either fix the "daemon" arg to match the documentation, or slightly change the manual to state that
>> the space variant is only possible if the argument is mandatory (e.g. replace "takes" with "requires").
>
> The manual actually already states that ("when a long option takes an
> argument"), but I agree it would be good to clarify that as you
> propose in the latter alternative.

Done in emacs-26.

3b86e0b812 2019-05-04T23:55:50-04:00 "Clarify handling of long options (Bug#24949)"
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3b86e0b812e97aa83222f042ce8323516aaca0ec

bug#24949: Command-line argument parsing: named daemons

[Philipp Stephani]

Am So., 5. Mai 2019 um 05:59 Uhr schrieb Noam Postavsky <npostavs@gmail.com>:
>
> tags 24949 fixed
> close 24949 26.3
> quit
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Philipp Stephani <p.stephani2@gmail.com>
>
> >> We could either fix the "daemon" arg to match the documentation, or slightly change the manual to state that
> >> the space variant is only possible if the argument is mandatory (e.g. replace "takes" with "requires").
> >
> > The manual actually already states that ("when a long option takes an
> > argument"), but I agree it would be good to clarify that as you
> > propose in the latter alternative.
>
> Done in emacs-26.
>
> 3b86e0b812 2019-05-04T23:55:50-04:00 "Clarify handling of long options (Bug#24949)"
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3b86e0b812e97aa83222f042ce8323516aaca0ec
>

Thanks

bug#24949: Command-line argument parsing: named daemons

[Andreas Schwab]

On Jan 07 2018, Philipp Stephani <p.stephani2@gmail.com> wrote:

> I've just re-checked this. The manual states: "When a long option takes an
> argument, you can use either a space or an equal sign to separate the
> option name and the argument.  Thus, you can write either
> @samp{--display sugar-bombs:0.0} or @samp{--display=sugar-bombs:0.0}. "
>
> So it's even documented that both forms should work.

That's only true for options with a non-optional argument.  For optional
arguments the equal sign is required, otherwise it doesn't know whether
the argument belongs to the option.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."