Casper.Dik at Sun.COM wrote:
[snip] 
> In the particular case of /etc/ksh.kshrc, we have several reasons for these
> discussions:
> 
>     - we introduce a file which is always read by ksh

Minor correction: Is is read by all interactive ksh93 shell sessions.

>         - nice for system administrators, so this is good

<Wearing_my_admin-hat>: Yes, yes</Wearing_my_admin-hat> ... :-)

>         - is it a pathname specific to Solaris or is it common?

It is used on Linux and other platforms, too. Originally ksh93 had this
as a compile-time option which checked whether the underlying build
machine has a /etc/ksh.kshrc or /etc/bash.bashrc file installed and then
enabled the support for /etc/ksh.kshrc - but our Makefile system
unconditionally enables support for /etc/ksh.kshrc

>     - this file changes the default editing setting to gmacs, but
>       raises valid questions like:
>         - does this override $EDITOR or $VISUAL?

No, because the shell code in /etc/ksh.kshrc checks whether any
editor-related flag is turned-on or not. Only if all of these flags are
"off" the "gmacs" editor mode is enabled.

>         - does it override user's $ENV or ~/.profile or ~/.kshrc settings?

No, because enabling an editor mode in /etc/profile or ~/.profile will
set a flag and then the fallback code in /etc/ksh.kshrc will not be used
(see above) and any settings in ~/.kshrc are sourced after
/etc/ksh.kshrc and therefore will wallpaper over anything we set in
/etc/.ksh.kshrc

>         - is this a sensible default (clearly there's a disagreement
>           some (including me) think so, others such as jek3 do not;

What do you mean with "sensible default" ?

>         - is it a sensible way to implement the default?
>         - is it how the default is implemented elsewhere?

At least SuSE Liunx unconditionally sets an editor mode in
/etc/ksh.kshrc and any user settings have to be done in ~/.kshrc

>     - since this file is supposed to be editable by the administrator
>       what is the proposed patch/upgrade policy?
> 
>         (for /etc/profile we use a class action edit script;
>         for /etc/.login, we just deliver the new file as /etc/.login.new)

The current solution we use in the ksh93-integration prototype002/003
codebase is to rename the file on updates and replace it with the one
from the newer version. That is not prefect but avoids that any content
is lost and allows us to deliver another missing item later (I am
referring to the "multiline" option (which allows that strings which are
longer than one terminal line can be edited in multiple terminal lines
instead of the "one line scrolling string" used in ksh88) which isn't
turned on yet because we have trouble with the 64bit shells...
sometimes. Once I've killed the problem we may want to enable this
option in /etc/ksh.kshrc, too (not this case, not this case, not... I
just trying to explain why I didn't choose the solution for
"/etc/.login" (we can change that later...))).

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)

Reply via email to