zsh-workers
 help / color / mirror / code / Atom feed
From: Richard Hartmann <richih.mailinglist@gmail.com>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh hackers list <zsh-workers@sunsite.dk>
Subject: Proposed patch for options.yo (was: Re: bug in single_command)
Date: Wed, 11 Feb 2009 21:13:37 +0100	[thread overview]
Message-ID: <2d460de70902111213w2f8b9a6du921cdf1c42c32d71@mail.gmail.com> (raw)

First of all, sorry for the subject of the email. I wanted to change it
after I found out what the actual issue was but forgot. The body of the
mail changed quite substantially. Duh..

On Wed, Feb 11, 2009 at 19:13, Bart Schaefer <schaefer@brasslantern.com> wrote:

> I suggest changing "the command line" here to something like "in the
> flags supplied at invocation of the shell" to match terminology that
> is used elsewhere, e.g., the manual section "Invocation".

Very good point. I'll check against the docs that my terminology is
correct.


> It's true that "the command line" used elsewhere in the manual often
> refers to the equivalent of the ZLE input buffer.  On the other hand,
> it seems so obvious that "setopt single_command" would cause the shell
> to immediately exit (after all, it has now executed a single command!)
> that I hardly believe thsi is a source of significant confusion.

Hardly significant, agreed. But when reading docs, I go into pedantic
prick mode, looking for stuff to improve :p
Liberal in what you require, strict in what you provide and all that.


> A better question might be why these options are not mentioned in the
> "Invocation" section, since that's the only context in which they make
> sense, rather than being relegated to the "Single Letter Options".

I'll see where that fits and work it into the patch.


> Without looking, I'd suspect that the reason is that dosetopt() may at
> times be called from a context where emitting an error message is not
> appropriate.

No idea about appropriate (did not dig too deeply), but it _is_ used
without any checking of return values etc. Namely in

Src/builtin.c 540 & 541:

    dosetopt(VERBOSE, 0, 0);
    dosetopt(XTRACE, 0, 0);

All occurences in Src/init.c

Src/options.c 506:

static void
setoption(HashNode hn, int value)
{
    dosetopt(((Optname) hn)->optno, value, 0);
}


> In general it's bad programming to spew to the standard
> error stream at too low a level because it takes control away from the
> caller.

Agreed, but I didn't know it's too low when I wrote this (and I don't
think it's my place to decide those matters, anyway). That said, I
should have checked all places it is used in before suggesting direct
printing. Return values? Or passing back an actual string?


Richard


             reply	other threads:[~2009-02-11 20:13 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-11 20:13 Richard Hartmann [this message]
2009-02-11 23:53 ` Richard Hartmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2d460de70902111213w2f8b9a6du921cdf1c42c32d71@mail.gmail.com \
    --to=richih.mailinglist@gmail.com \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-workers@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).