From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9314 invoked from network); 30 Jul 2001 02:21:30 -0000 Received: from unknown (HELO sunsite.dk) (130.225.51.30) by ns1.primenet.com.au with SMTP; 30 Jul 2001 02:21:30 -0000 Received: (qmail 24126 invoked by alias); 30 Jul 2001 02:21:24 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 15522 Received: (qmail 24105 invoked from network); 30 Jul 2001 02:21:23 -0000 From: Bart Schaefer Message-Id: <1010730021953.ZM29184@candle.brasslantern.com> Date: Mon, 30 Jul 2001 02:19:53 +0000 In-Reply-To: Comments: In reply to Zefram "Re: Enhanced shell" (Jul 29, 10:53am) References: X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.dk Subject: Re: Enhanced shell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jul 29, 10:53am, Zefram wrote: } Subject: Re: Enhanced shell } } >coproc keyword (|& as per csh is already semi-standard and useful) } } It's just a pity we can't make coproc a normal command -- it has to be } part of the shell grammar to pick up an entire pipeline, which seems to } be what we want. I think the syntax `coproc { LIST }' would be preferable to what we have now. Ksh has introduced `namespace NAME { LIST }' already. If the LIST associated with `coproc' were brace-delimited, we could use the regular redirection operators to specify inputs and outputs, rather than using options to the coproc pseudo-command. Heck, you could even have coprocs with multios! } >? ZDOTDIR? (or equivalent) } } I'm very dubious about this kind of thing. We should mostly ignore the } environment when deciding which dotfiles to execute. That's why I suggested not importing ZDOTDIR unless geteuid() == getuid(). Seems to be the right balance. (How does ksh deal with ENV ?) } >CPUTYPE/HOSTYPE/OSTYPE, EGID/GID, EUID/UID, ERRNO, HOST or HOSTNAME (bash) } } Instead, we should put all magic variables -- ones that affect the } shell or that the shell fiddles with, other than by explicit command } -- into a sub-namespace. Things like PATH would have to remain where } they are, because they're needed in the environment. But EGID should be } "egid.sh". Ksh namespaces are ${.namespace.parameter}, not ${parameter.namespace}. I think we're probably going to be stuck with that. However, I agree that most of the "magic" variables should be in a namespace, and futher I that the magic should be implemented with something like discipline functions. E.g., there should be a builtin command to change effective UID, and assigning to .sh.euid should invoke that command. } With the emulate command as described above, we can have multios be on } by default in "posix_v2" mode and (of course) off by default in POSIX } v1 mode. We don't need to standardise "setopt multios", or most other } user-visible options. Hmm, perhaps that's true, but should we at least standardize a reserved name (e.g., a .sh.options parameter) for changing the option settings? Should we try to do anything at all about the plethora of single-letter shell-startup command-line options? } modifiers on parameter expansion: the history modifiers could be } standardised for use in parameter expansion a la "${FOO:t}". These seem } useful, and a clean syntax. The syntax isn't all that clean, really, once you get involved with using more than one modifier per expansion ... and the semantics of :s/p/r and :& etc. are rather baroque. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net