Re: Two questions

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

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