zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@zsh.org
Subject: Re: 4.3.17 unset RPS1 vs RPROMPT
Date: Sat, 30 Jun 2012 10:31:28 -0700	[thread overview]
Message-ID: <120630103128.ZM30227@torch.brasslantern.com> (raw)
In-Reply-To: <20120630050512.GA87092@redoubt.spodhuis.org>

On Jun 29, 10:05pm, Phil Pennock wrote:
}
} If the name could be rebound to another variable and no longer be magic,
} the current approach would be sane, but it seems that perhaps the
} correct behaviour should be to ensure that whatever the state of one
} name, the other name should be in the same state: set, unset, empty,
} with-content, whatever.

There's some precedent for this; although $#, $@ and $* are read-only
variables, if you "unset argv" you erase $* and $@, and $# becomes 0.
On the other hand, argv has its own weird semantics (see below) which
probably exempts it from this analogy.

} Perhaps I've become contaminated with the Pythonic approach of being
} distinct about the binding of a name to a variable versus the changing
} of the value of a variable.

I think this comes down to a scoping issue.

Shell variables have a form of dynamic scoping that's somewhat different
from that of any other interpreted language.  In the first shells, all
variables were environment variables.  Then shell variables became a
separate thing and the idea of exporting them into the environment was
introduced, but there was still only one global scope.  Then local scopes
were introduced, but to retain the semantics of the former global scope,
the local scopes became dynamic, based on runtime call heirarchy rather
than code structure.

Once a shell variable has a scope, unsetting the variable does not delete
it from that scope.  If you re-use the name, it returns in the same scope
where it was originally defined, unless you are declaring it in a new
dynamic scope.  You can't change the magic binding in the original scope;
that's what it means for the variable to be "special".

But you can rebind them in any scope other than the global one, and thus
in all dynamically nested scopes, with e.g. "local -h RPROMPT".

Weird semantics:  Although argv is seems implicitly to be local in all
scopes, unsetting without first actually declaring it local causes it
to disappear in all scopes, which breaks the connection to $* et al.

torch% showargv() { print -l "argv: $argv" "*: $*" }
torch% noargv() { print -l "argv: $argv"; unset argv; print "*: $*" }
torch% showargv one two three
argv: one two three
*: one two three
torch% noargv four five six
argv: four five six
*: 
torch% showargv seven eight nine
argv: 
*: seven eight nine
torch% noargv gone gone gone
argv: 
*: gone gone gone
torch% 

Resetting it brings it back with full magic intact:

torch% argv=()
torch% showargv seven eight nine
argv: seven eight nine
*: seven eight nine
torch% 

Of course I say "seems" to be local in all scopes because really it's
the special binding to $@ and $* that makes it local; the name itself
and its properties are still defined in the global scope.


  reply	other threads:[~2012-06-30 17:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-29  9:40 Phil Pennock
2012-06-29 10:02 ` Mikael Magnusson
2012-06-29 13:32   ` Phil Pennock
2012-06-29 17:35 ` Bart Schaefer
2012-06-29 18:52 ` Peter Stephenson
2012-06-30  5:05   ` Phil Pennock
2012-06-30 17:31     ` Bart Schaefer [this message]
2012-07-01 17:39     ` Peter Stephenson
  -- strict thread matches above, loose matches on Subject: below --
2007-05-03  5:39 [PATCH] Proposal: stat -> zstat Phil Pennock
2007-05-03  8:50 ` Peter Stephenson
2007-05-06  1:07   ` Phil Pennock
2007-05-06 11:57     ` Peter Stephenson
2007-05-06 14:00       ` Phil Pennock
2007-05-07  0:58         ` Peter Stephenson
2007-05-03 14:48 ` Bart Schaefer
2007-05-03 15:46   ` Peter Stephenson
2007-05-07  5:31     ` Bart Schaefer
2007-05-08 14:40       ` Peter Stephenson
2007-05-09 17:19         ` Bart Schaefer
2007-05-09 17:47           ` Peter Stephenson

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=120630103128.ZM30227@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).