From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2905 invoked from network); 20 Aug 2001 11:18:13 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 20 Aug 2001 11:18:13 -0000 Received: (qmail 11975 invoked by alias); 20 Aug 2001 11:18:06 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 15667 Received: (qmail 11964 invoked from network); 20 Aug 2001 11:18:05 -0000 From: martin.ebourne@arcordia.com Subject: Re: New options & arguments processing system for ZSH To: Bart Schaefer Cc: zsh-workers@sunsite.dk Date: Mon, 20 Aug 2001 12:17:26 +0100 Message-ID: X-MIMETrack: Serialize by Router on LON-ARCMTA-01/ARCORDIA(Release 5.0.3 (Intl)|21 March 2000) at 08/20/2001 12:17:28 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii > - I like it a lot better than the XML version suggested by Felix, but > the ideal solution probably lies somewhere between the two. Quite likely. Certainly I can see advantages of both systems, and even of converting between the two. As to whether it'll ever be possible to come up with a format that's ideal both for complicated programs such as find, and simple ones as cat, I'm not so certain. Coupled with the fact that different people like to do things in different ways, I think it's helpful to have different systems. > - It suffers from the same problems as my _arg_compile scheme, to wit, > every function that uses it has to do a lot of extra work that is not > directly related to the purpose of the function. I like _arg_compile, it certainly makes the less than intuitive (in my opinion anyway!) syntax of _arguments much more readable. However, with parse_opts I was really trying to tackle a different problem. What I wanted was something that would decode the command line when a program is run, splitting options and arguments into data structures as required, and performing any validation possible (sort of a zparseopts on steroids ;)). I wanted this to simplify the writing of scripts/functions which were complicated enough to need some code to parse the command line. While I was on the way I found I could add automatic completion for almost no extra hassle on the user's part, so I jumped at the chance. As to the extra work done by the 'client' function, in terms of processing there is a fair bit extra - mostly to do with decoding the help. However since this is intended to be done mainly for functions which are used directly by a person, not ones used by other functions in a larger system, I don't think the processing overhead is really an issue. I can think of some ways of caching this stuff though, which would be of most advantage to speed when completing I think, and would probably almost eliminate the overhead. As to extra work in terms of code in the function, I don't think that's the case. Most of the lines are real help text, and there's not much you can do to shorten that apart from not provide it. I've done my best to keep the calling syntax very simple, and hopefully managed it to a large extent. I did go through most of my shell functions and convert them to this system. Almost all functions that did any kind of options parsing, help, or validation became shorter, and all of the functions became more functional (long options, completion, etc). Even with a case like the 'yes' example, the real code became noticably shorter, and the division of responsibility between decoding and doing became much more clear. > - Here-documents end up getting encoded as strings in the compiled > function definition in memory, so this is probably prohibitive for > general use except when using zcompile'd files with memory mapping. I've already mentioned that most of the text is 'real' help, so that's no different to you'd get if you provided that anyway. Personally I like commands to be as helpful as possible, so that's a price I'm prepared to pay - and as I've said, I don't see a major use for this in decoding options for internal functions - ie. I wouldn't expect the completion system or anything similar to use it internally! [nothing stopping it though... ;)] On the other hand, tt is fair to say that all of my functions are in separate autoloaded files, and I do have them all compiled on a per-directory basis. But then I did that anyway. ;) > - You should have sent it to zsh-workers, not zsh-users. :-) Yes, I can certainly see your point. I did think about it for quite a while. The thing that tipped the balance for me was that I feel it is the sort of thing that any users of zsh who are writing shell scripts might find helpful, as opposed to just the developers of Zsh. After all, I'm in the former category, and obviously find it useful! Also even on a slow modem the download time should be < 15 seconds, so I didn't think it was too bad. Certainly all followup should be on workers, as has happened. Thanks for looking at it, any further suggestions welcomed if you get chance. Cheers, Martin.