From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18250 invoked from network); 9 Jul 2001 19:44:03 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 9 Jul 2001 19:44:03 -0000 Received: (qmail 21574 invoked by alias); 9 Jul 2001 19:43:58 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 15348 Received: (qmail 21560 invoked from network); 9 Jul 2001 19:43:56 -0000 Sender: kiddleo Message-ID: <3B4A097B.51C28509@u.genie.co.uk> Date: Mon, 09 Jul 2001 20:43:55 +0100 From: Oliver Kiddle X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.15 i686) X-Accept-Language: en MIME-Version: 1.0 To: zsh-workers@sunsite.dk Subject: Re: named references References: <3B35D04E.F6F4E3A1@u.genie.co.uk> <1010624182845.ZM9789@candle.brasslantern.com> <3B3A2D7A.7B8EA3AF@u.genie.co.uk> <010630003732.ZM20228@candle.brasslantern.com> Content-Type: multipart/mixed; boundary="------------8D625150DDBC042EEDD82A07" This is a multi-part message in MIME format. --------------8D625150DDBC042EEDD82A07 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On 30 Jun, Bart Schaefer wrote: > We should emulate ksh when `name' is already a nameref. > However, we could follow our usual pattern of choosing some other syntax > that's illegal in sh/ksh and giving it additional semantics; e.g. Okay, that sounds good though I'll get the basics working first before any new for syntax. > > > } what should ${(t)ref} return - the same as what it refers to with > > > } -nameref- inserted? > Hmm, that's probably true. In which case I'm not even sure if it should > insert -nameref- anywhere. Hard to say. I know what you mean. My thinking behind inserting -nameref- was that it would enable shell code to detect namerefs -- so for example I can write a proper completion for unset -n -- while being compatible with any old shell code that pattern matches against the output of ${(t)ref} (which most probably does). > > In 5068, you said that ksh has "separate namespaces for namerefs and > > parameters". Can you remember what you meant by that? > > Exactly what you mentioned before -- `nameref ref=var; typeset ref' > doesn't output anything, and `unset ref' doesn't remove `ref', so the > name `ref' does not behave like a parameter name. What I didn't realize > at the time was that `unset ref' actually removes `var', nor that there The name `ref' does behave like a parameter name in ksh. `typeset ref' is just defining ref if it isn't already defined so it will never output anything for any variable in ksh. You have to do `typeset|grep ref'. > was such a thing as `unset -n'. (Flags to `unset'? Heresy!) Well, we already have two flags to unset -- -f and -m (and I've just realised that I've not done a completion for them). Anyway, I had a little time on the weekend to look at using a pointer for the nameref. I am convinced that it is the better way, it'll just be slightly less easy because I have to meddle more with existing code. The first problem is that fetchvalue() currently returns NULL for PM_UNSET variables which I'm probably going to have to change. In case anyone is interested, attached is a descripton of ksh93 features which aren't in zsh. Let me know if you know of things to add to it. Oliver --------------8D625150DDBC042EEDD82A07 Content-Type: text/plain; charset=us-ascii; name="ksh93.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ksh93.txt" local variables --------------- The two function definition syntaxes work differently in ksh. function name syntax is equivalent to using localtraps and typeset defines local variables. function() syntax uses the same environment as the caller and shares all traps and variables. This is also the case if the function is invoked with the `.' special builtin. Also note that in ksh, local variables are statically scoped (they aren't in zsh). Dynamic scoping seems more natural for a shell in my opinion. In future we could have something like Perl's `my' for static scoping (but preferably using a less cheesy name). discipline functions -------------------- Any function with a "." in its name is a "discipline function". Anything up to the last "." refers to a parameter. Only `get', `set' and `unset' are defined at the moment and they intercept assignments to the variable. The trouble is that functions are not scoped so discipline functions can only be used for global variables. The situation is actually that if you redefine a discipline in a function for a local, the discipline is removed after the function returns and ksh seg faults next time you access the variable because it is pointing to a removed discipline. I pointed this out to David Korn and he got back to me so it'll be fixed. Anyway, if anyone thinks about implementing discipline functions, they might want to consider scoped functions first (in case it isn't clear, ksh does *not* do scoped functions). hierarchical variables ---------------------- If namerefs are the equivalent of pointers, these are the equivalent of structs/records. They, amount to little more than allowing "." in a variable name with nameref logic so `nameref ref=val; echo ${ref.one}' will output the value of ${val.one}. There is also a compound assignment statement though so you can do things like val=(one=1 two=2) instead of val.one=1;val.two=2 There are aspects of this which I don't like though: $ n.o=1 ksh: n.o=1: no parent $ n= $ n.o=1 $ unset n # this unsets just `n' so we now have an orphaned ${n.o} There is seemingly no way to manipulate a whole hierarchy such as to unset it or whatever. The idea is that you pass it around by name which is fair enough. namespaces ---------- I may have confused these with hierarchical variables previously. I get the impression that these did not exist in the original ksh93 (the latest is sub-release l). I also suspect that they are not quite finshed yet - I have had a couple of seg faults and there is no documentation. Anyway, there is a reserved word, `namespace' which I am guessing is similar to Pascal's with statement. It seems to be possible to use it like this: $ .Z= $ .Z.one=hello $ namespace Z { > echo $one > } set and typeset will then not list variables in the namespace. typeset will include `namespace Z' in its output though. These would be nice for hiding the completion system caches out of the way. nested assignment statements ---------------------------- This is related to hierarchical variables above. Basically, any assignment of the form var=( ... ) contains other assignment statements within the brackets. So you can do stuff like: rec=(integer i=3; arr=(one two three); assoc=([a]=1 [b]=2)) other misc things ----------------- named references - of course += assignment operator (appends to or arithmetic add). a wrapper (/etc/suid_exec) to allow suid/sgid/unreadable scripts to be run /dev/fd/n emulated in the script argument to ksh filenames of the form /dev/{tcp,udp}/hostid/port can be used to create tcp and udp connections. two consecutive characters in IFS has a different meaning --------------8D625150DDBC042EEDD82A07--