zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@zsh.org
Subject: Re: 'emulate sh -c' and $0
Date: Tue, 03 Jun 2014 18:10:14 -0700	[thread overview]
Message-ID: <140603181014.ZM28105@torch.brasslantern.com> (raw)
In-Reply-To: <CAH+w=7bhRnt-S=9rX-B14v=H+eQjrMUppQD=tErP2mYnaLb8Ww@mail.gmail.com>

On Jun 3,  5:03pm, Bart Schaefer wrote:
}
} On Jun 3, 2014 3:54 PM, "Richard Hansen" <rhansen@bbn.com> wrote:
} >
} > I was thinking more along the lines of temporarily
} > restoring the top-level (non-emulated) option state when calling a
} > function that was not defined inside of 'emulate <shell> -c'.  (Maybe
} > there's not a significant implementation difference between what I'm
} > thinking and assigning sticky options to all functions.)
} 
} Implementation aside, operationally this still violates dynamic scoping.
} It means for example that the completion system can't set extendedglob on
} entry and be sure it remains in effect throughout any helper functions it
} calls.

OK, that's not quite true.  What you're suggesting is not that the called
function has made the global options sticky, rather that if the calling
function has sticky options, it automatically reverts them upon making
a nested call.  So that would only mess up completion if somebody did
"emulate zsh -c compinit" to load it.

That still prevents the calling function from intentionally propagating
a particular set of options down to the called function, which I think
is the more common use case (certainly so far it has been the *only*
use case, though that may just be because no other is possible).

And as I suspected "reverts them" currently involves completing the C
fuction scope of doshfunc(), though that could be disentangled with a
bit of effort.


  reply	other threads:[~2014-06-04  1:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-29 23:04 Richard Hansen
2014-05-30  3:45 ` Bart Schaefer
2014-05-30  8:49   ` Richard Hansen
2014-05-30 17:00     ` Bart Schaefer
2014-05-30 21:14       ` Richard Hansen
2014-05-31  5:13         ` Bart Schaefer
2014-05-31 23:47           ` Bart Schaefer
2014-06-03 20:15           ` Richard Hansen
2014-06-03 20:26             ` Peter Stephenson
2014-06-03 21:10               ` Bart Schaefer
2014-06-03 23:35                 ` Richard Hansen
2014-06-04  0:09                   ` Bart Schaefer
2014-06-03 21:21             ` Bart Schaefer
2014-06-03 22:54               ` Richard Hansen
2014-06-04  0:03                 ` Bart Schaefer
2014-06-04  1:10                   ` Bart Schaefer [this message]
2014-06-04  1:23                 ` Bart Schaefer

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=140603181014.ZM28105@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /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).