From mboxrd@z Thu Jan 1 00:00:00 1970 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes From: "Bart Schaefer" Message-Id: <990126223651.ZM26737@candle.brasslantern.com> Date: Tue, 26 Jan 1999 22:36:51 -0800 In-Reply-To: <19990126183201.A27794@fysh.org> Comments: In reply to Phil Pennock "Two questions" (Jan 26, 6:32pm) References: <19990126183201.A27794@fysh.org> X-Mailer: Z-Mail (4.0b.820 20aug96) To: Zsh Development Workers Subject: Re: Two questions MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: 5042 On Jan 26, 6:32pm, Phil Pennock wrote: } Subject: Two questions } } A few weeks ago I queried (on zsh-users) how to do redirection from a } variable file descriptor. The answer was quite complex, and boiled down } to the fact that the parser gets in the way. } } Bog-standard Bourne shell handles it smoothly. If we're aiming for } compatibility, fixing this might be good. How feasible is it? } } Eg, } % cat foo } #!/path/to/zsh -f } print >$1 '=== Foo! ===' Shouldn't that be print >&$1 '=== Foo! ===' (note `&')? Otherwise you're redirecting to the file named $1, not to the descriptor numbered $1. } % ./foo 5 5>Funky I just tried the following little function: tryit() { echo No parameter 1>&2 echo Parameter: $1>&$2 } Any of bash, zsh 3.0.5, and zsh-3.1.5-pws-5 give exactly the same result: The output is correctly redirected to the descriptor on the right-hand side of the redirection, even when that descriptor is named in a variable, but a variable on the left-hand side of the redirection simply becomes another argument to the echo. E.g., zagzig% tryit 5 1 No parameter Parameter: 5 zagzig% tryit 2 5 No parameter zsh: 5: bad file number zagzig% tryit 2 5 5>/dev/null No parameter zagzig% Now, are you certain that "bog-standard Bourne shell" does the thing you wanted with descriptors on both/either sides of the redirection operator? } Recently zsh has changed a number of things to be more compatible with } ksh. And some things, such as the associative arrray stuff, has } followed what seem to be dubious criteria in order to be compatible. Could you please describe which "dubious criteria" you mean? Other than the fact that we now have conflicting meanings of the -A option for some nominally related commands, I thought we were doing pretty well with the associative array stuff. } Given that there's pdksh for that, just how important is it for zsh to } parallel ksh? Not that I'm really in the compatibily camp, but the argument goes a bit like this: Lots and lots of shell scripts -- particularly system init scripts and components of GNU utilities -- are written to work with bash and/or ksh. If zsh can't interpret those scripts, lots of things go wrong; /bin/sh can't be a link to zsh, some "make" tools that don't properly reset $(SHELL) will break for people who use zsh, and so forth. Every such bit of breakage is an obstacle to getting zsh installed and used on the machine where it happens. In extreme cases there are even disk space or memory usage issues that limit the number of shells that can be made available; if zsh can't reliably interpret critical shell scripts, it will be removed in favor of a shell that can, even if interactive users suffer as a result. Therefore, zsh must always be a superset of other Bourne-like shells, not just in function but also in form. } And how important to do so natively, as opposed to an option adding } behaviour or whatever? Here I'm of the opinion that the number of options has already gotten out of hand and very close scrutiny should be applied to new ones. That means that if you're adding something that another Bourne-like shell has already implemented, do it the same way as that other shell UNLESS that already conflicts with an established zsh usage. In that case only, an option could be considered (and the established zsh usage should remain the default). -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com