[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ast-users
Subject:    [ast-users] Re: [ksh93-integration-discuss] Patch
From:       zmsjeu47-kshtjdoyle () yahoo ! com (Terrence J !  Doyle)
Date:       2006-07-19 21:27:15
Message-ID: 44BEDBC8.30700 () yahoo ! com
[Download RAW message or body]

Stephan Titard wrote:
> Glenn Fowler escribi?:
>>> The original patch (attached here as
>>> "ksh93_ksh_kshrc_and_bash_bashrc_prototype_diff.txt" for reference) 
>>> also
>>> added /etc/bash.bashrc and made it a softlink to /etc/ksh.kshrc, 
>>> copying
>>> the default used on other operating systems (such as Linux and *BSD
>>> variants) - but after some discussion with Mike Kupfer I removed the
>>> bash parts as this should be part of another RFE (which may include
>>> adding support for /etc/sh.shrc to the bourne shell (and then makes
>>> /etc/ksh.kshrc and /etc/bash.bashrc soft links to /etc/sh.shrc (because
>>> it is usefull to have ONE configuration file for these shells 
>>> instead of
>>> three))).
>>>     
>>
>> isn't that "usefull to have ONE configuration file for these shells" 
>> /etc/profile?
>>
>> also, the patch to force /etc/ksh.kshrc checks for a vendor name 
>> rather than
>> a feature -- we prefer to do that only as a last resort
>> a more appropriate place for vendor specific settings would be in the 
>> vendor
>> specific makefile(s) that set up compile time options
>> in this case -DSHOPT_SYSRC should do what you want
>> if it doesn't then let me know so I can make it work
>>   
> I am definitely against the proliferation of initialization files
> for a login shell it seems  logical  to have one global file, and one 
> for the user...
> for the rest they are already good mechanisms

I'm with Stephan and Glenn. Ksh has been using only /etc/profile and
$HOME/.profile, along with the more flexibly named $ENV, for years. In
that time vendors, system administrators, and ordinary users have all
developed their own creative ways of dealing with the multi-use issue of
these files (as well as the absence of $HOME/.logout) without changing
ksh internals. Changing ksh now could royally mess up some of these
home-grown solutions.

> still it is true that writing a snippet of /etc/profile in a dialect 
> understood by all the shells has become complicated
> to say the least
> this is sad. If a process of standarization only consists in taking an 
> intersection of features and let it stale, it cannot be good.

It doesn't have to be complicated or sad. Just keep the snippet of
universal code reasonably short and Bourne-shell-compatible, and
modularize the shell-specific code into separate files that get sourced
from /etc/profile. In my response to "Fedora Core 4 breaks ksh as login
shell?"
(https://mailman.research.att.com/pipermail/ast-users/2005q4/000734.html)
I presented a case statement that can be used as part of such a
solution. Actually, that case statement, as presented, could use some
adjustments to fit with this discussion. So, here it is again with those
adjustments:

     case "$0" in

	-bash)
             [ -r /etc/bash.bashrc ] && . /etc/bash.bashrc
             ;;

	-ksh)
	    [ -r /etc/ksh.kshrc ] && . /etc/ksh.kshrc
	    ;;

	-sh)
	    [ -r /etc/sh.shrc ] && . /etc/sh.shrc
	    ;;

     esac

As you can see, this case statement satisfies the Sun group's request
for shell-specific login scripts without modifying ksh internal code.
Additional choices could be added for -su (executed with su - or su -l),
and the restricted shells: -rbash, -rksh, and -rsh.

Surprisingly, this idea of a shell-independent /etc/profile can be
extended even to csh. Years ago I had a user account on a system with a
very old version of HP-UX. This version of HP-UX included a version of
csh that actually sourced /etc/profile with every login shell. Of
course, the system administrator and most of the other users were csh
fanatics. So, with csh-specific code in /etc/profile, I had to go along
with the rest and use csh. Some time later, after I no longer needed
access to that system, I realized that /etc/profile could easily have
accommodated both csh and sh-style shells with the following two
statements:

    /bin/test \( "$0" = -csh \) -a \( -r /etc/profile.csh \) && source /etc/profile.csh
    /bin/test \( "$0" != -csh \) -a \( -r /etc/profile.sh \) && . /etc/profile.sh

> I am just another $hacker, and I spent the other day half an hour to 
> have something working for ksh, bash and zsh (in ksh mode).

On the other hand, in situations where universal shell code is not
required, you shouldn't wear yourself out over code-compatibility
issues. For programming projects you should pick a shell, and code for
that shell.

Terrence Doyle


[prev in list] [next in list] [prev in thread] [next in thread]