zsh-workers
 help / color / mirror / code / Atom feed
From: Zefram <zefram@tao.co.uk>
To: schaefer@brasslantern.com (Bart Schaefer)
Cc: zefram@tao.co.uk, zsh-workers@math.gatech.edu
Subject: Re: Variable namespaces, goals for ZLE, etc.
Date: Wed, 10 Jun 1998 19:01:35 +0100 (BST)	[thread overview]
Message-ID: <199806101801.TAA21245@taos.demon.co.uk> (raw)
In-Reply-To: <980610103728.ZM12142@candle.brasslantern.com> from "Bart Schaefer" at Jun 10, 98 10:37:28 am

Bart Schaefer wrote:
>Are there any "available" names in the POSIX space?

Depends what you mean by "available".  POSIX lists "the special
parameters" as being "*", "@", "#", "?", "-", "$", "!" and "0"; by
implication, all other parameters have the semantics of normal variables.
It lists "IFS", "PATH", "PPID" et al as normal variables that are either
set or read by the shell, but does not permit them to have any weird
semantics beyond those it defines.  It is arguable that the shell can
modify its behaviour based on the values of other variables, but it
certainly isn't permitted to make variables with normal names behave as
special variables.

>The problem with introducing an incompatible syntax in order to escape
>POSIX is that you can't reliably export variables with the new names.

You can export anything.  Whether other utilities accept anything unusual
is, admittedly, a more complicated issue.

>I've used versions of sh that would mangle the environment and/or issue
>warning messages if there were any strings present where the stuff to
>the left of the `=' contained characters other than [A-Z][a-z][0-9]_.

We could do a configure test for that.  Perhaps if the local sh does
complain, we could import/export using munged names starting with
"__ZSH__" or something like that.  Within zsh, the variable name "__ZSH__"
would still be legal, it would just be exported under a different name.
Alternatively, we keep things simple, and just don't import/export
special variables on platforms that really can't handle it -- there
can't be many of them, surely?

-zefram


  reply	other threads:[~1998-06-10 18:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-06-09 17:09 User-defined zle widgets and built-in widget failure Bart Schaefer
1998-06-09 18:01 ` Zefram
1998-06-09 19:12   ` Bart Schaefer
1998-06-09 20:02     ` Zefram
1998-06-10  6:26       ` Variable namespaces, goals for ZLE, etc Bart Schaefer
1998-06-10 10:55         ` Zefram
1998-06-10 17:37           ` Bart Schaefer
1998-06-10 18:01             ` Zefram [this message]
1998-06-10 18:36               ` Bart Schaefer
1998-06-10 10:24       ` Associative arrays, structured namespaces Bruce Stephens
1998-06-10 10:44         ` Zefram
1998-06-10 12:07           ` Bruce Stephens
1998-06-10 12:28             ` Bruce Stephens

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=199806101801.TAA21245@taos.demon.co.uk \
    --to=zefram@tao.co.uk \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-workers@math.gatech.edu \
    /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).