Path: csiph.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!news.glorb.com!usenet.stanford.edu!not-for-mail From: Chet Ramey Newsgroups: gnu.bash.bug Subject: Re: Feature discussion - startup files Date: Wed, 23 Dec 2015 09:51:51 -0500 Lines: 26 Approved: bug-bash@gnu.org Message-ID: References: <56785EE2.3050108@case.edu> <1450739858.4716.5.camel@16bits.net> Reply-To: chet.ramey@case.edu NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: usenet.stanford.edu 1450882321 25370 208.118.235.17 (23 Dec 2015 14:52:01 GMT) X-Complaints-To: action@cs.stanford.edu Cc: kefalonia@gmail.com, Kenneth Hoste , mclay@tacc.utexas.edu, chet.ramey@case.edu To: =?UTF-8?Q?=c3=81ngel_Gonz=c3=a1lez?= , bug-bash@gnu.org Envelope-to: bug-bash@gnu.org User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <1450739858.4716.5.camel@16bits.net> X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.567AB508.0158,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2015-08-12 04:07:17, dmn=2011-05-27 18:58:46 X-Mirapoint-Loop-Id: ef9d90e8cfdf1d8de57181e50e569f95 X-Junkmail-Whitelist: YES (by domain whitelist at mpv3-2015.case.edu) X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.567AB509.0040,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2015-08-12 04:07:17, dmn=2011-05-27 18:58:46 X-Mirapoint-Loop-Id: a5e9a11f84d1cceb4bfa5c24e563bc34 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 129.22.103.194 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:12119 On 12/21/15 6:17 PM, Ángel González wrote: > Chet Ramey wrote: >> The current configurable startup file options are insufficient for >> their purposes because they can be enabled or disabled by vendors, >> and these folks would rather not modify the "vendor" parts of the >> system. In some cases, with some Linux distributions, doing so voids >> their support. > > How are they going to deal with vendors disabling the new configuration > file, too? The idea is that by making it an unconditional option that is on by default, vendors will be discouraged from changing it. It's an optimistic perspective, no doubt. > "Create a new configuration file" is the wrong "solution" to "the > vendor disables existing configuration files". As I said, the vendor is the obstacle here. (And it's not `the vendor', its the multitude of them that make different choices.) -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRU chet@case.edu http://cnswww.cns.cwru.edu/~chet/