cc: ford at vader.omnicron.com
Subject: Re: [ksh93-integration-discuss] ksh93 problems - CHLD trap, printf,
prompt
--------
> I'm using the ksh93 project's 2008-02-29 update binaries and would like
> to report a few problems.
>
> The first problem is one that was also present in the 20070419_snapshot,
> which I tried to report last June. Despite posting a message to this
> list twice, once via the web interface and once via email, I never saw
> my message appear on the list. I only got a "pending moderator
> approval" notice. I hope that problem has been fixed and this message
> gets through.
If you are on the list, it should not need moderator approval.
>
> ========================================================================
>
> Problem 1:
>
> For about 20 years I've used
> trap "jobs -l" CHLD
> in my $ENV file to achieve an approximation of the csh "set notify"
> behavior. In the 20070419_snapshot version of ksh93 (I don't know about
> others - I haven't previously used ksh93) this causes an overabundance
> of data:
>
> $ jobs
> $ trap
> trap -- 'jobs -l' CHLD
> $ sleep 1000 &
> [1] 21894
> $ date
> Sat Jun 2 16:59:57 PDT 2007
> [1] + 21894 Running sleep 1000 &
> $ pwd
> /home/ford
> $ /bin/pwd
> /home/ford
> [1] + 21894 Running sleep 1000 &
> $ echo ${.sh.version}
> Version M 1993-12-28 s+
> $ /bin/echo ${.sh.version}
> Version M 1993-12-28 s+
> [1] + 21894 Running sleep 1000 &
> $
>
> In other words, ksh93 seems to execute the CHLD trap even on
> foreground jobs changing state, while previous versions have only done
> this for background jobs. The documentation seems to imply that the
> latter behavior should be expected.
I fixed this in ksh93t.
>
>
> ========================================================================
>
> Problem 2:
>
> /usr/bin/printf is not backward compatible. The first evidence I saw
> was this:
>
> $ utdiskadm -l
> Device Partition Mount Path
> printf: ------ --------- ----------\n: unknown option
> Usage: printf [ options ] format [string ...]
> disk1 disk1p0 /tmp/SUNWut/mnt/ford/unnamed
> $
>
> The problem is that the ksh93 version of /usr/bin/printf is looking
> for getopt style options, which are not allowed according to the man
> page.
>
> $ /be2/usr/bin/printf '----%s----\n' foo # normal SNV81
> ----foo----
> $ /usr/bin/printf '----%s----\n' foo # with ksh93 2008-02-29
> printf: ----%s----\n: unknown option
> Usage: printf [ options ] format [string ...]
> $
>
> A quick fix is to replace /usr/bin/printf with this:
>
> #!/usr/bin/ksh93
> printf -- "$@"
The option parser was changed to treat operands that start with
more than two - as an operand, not an option.
>
> ========================================================================
>
> Problem 3:
>
> This version of ksh93 (via /etc/ksh.kshrc) populates $PS1 with a (rather
> atrocious) default value before running $ENV. This incompatible change
> seems to make it impossible for me to set a prompt that is inherited by
> sub-shells, that is, to set my prompt in $ENV only if it hasn't been
> previously set in the environment.
>
> I suggest that a more compatible way to provide a gaudy prompt to users
> who haven't chosen to customize it for themselves is to set it only if
> it remains unset *after* $ENV has been executed.
>
> If the current behavior remains the default, can someone suggest a
> portable and efficient way for my $ENV to detect that PS1 was set by ksh
> and not inherited from the environment, so that I can set it to my
> preference in that case?
>
> I suppose that /etc/ksh.kshrc is editable by the administrator, but I
> would like to construct my $ENV file so that I get sane behavior even as
> a regular user on systems where the administrator hasn't chosen to "fix"
> /etc/ksh.kshrc .
The contents of /etc/ksh.kshrc is an adminstrator decision and
we do not provide one with the ksh93 distribution.
>
> ========================================================================
>
> Problems aside, thanks for the cool upgrades to ksh.
>
> -=] Ford [=-
Thanks for the feedback.
> _______________________________________________
> ksh93-integration-discuss mailing list
> ksh93-integration-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
>
David Korn
dgk at research.att.com
