Stephane Chazelas <stephane.chaze...@gmail.com> wrote:
> Note that ksh implements some utilties as aliases which actually
> breaks compliance.
>
> $ ksh -c 'type () { command -V "$@"; }; type ls'
> ksh: syntax error at line 1: `(' unexpected
LC_ALL=C ksh -c 'type () { command -V "$@"; }; type ls'
ksh: restricted: type is a shell builtin
ls is a tracked alias for /usr/bin/ls
Your behavior applies to ksh93
> Here are a few to complete your list:
>
> POSIX should at least allow .* expansion not to include "." and
> "..".
. and .. are artefacts of an implementation detail from the 1970s
and only present because this did save code space. A conforming filesystem may
not have them at all. I would be happy if this artefact was made history.
The problem: what do you gain if at least one shell and one filesystem still
includes them?
> unset should be guaranteed to clear the export attribute
Didn't we recently require unset to clear all attributes?
> printf %20s "$text" should be allowed to count those 20 in terms
> of characters instead of bytes. If printf is meant to be a
> printf(3) wrapper (which was the justification for that
> misbehaviour last time I asked), then that means the format can
> only have characters of the portable character set.
The printf utility forwards actions to printf(3), so your desire would be hard
to implement and what do you gain if there was one shell that follows your
request?
Jörg
--
EMail:jo...@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
