From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9396 invoked by alias); 17 Aug 2013 03:20:35 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 31657 Received: (qmail 28833 invoked from network); 17 Aug 2013 03:20:28 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <130816202019.ZM27717@torch.brasslantern.com> Date: Fri, 16 Aug 2013 20:20:19 -0700 In-reply-to: <20130815195447.3ab675b0@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Re: please conform to the xdg base directory specification" (Aug 15, 7:54pm) References: <201308131033.54673.thomas@koch.ro> <87siyehrxy.fsf@ft.bewatermyfriend.org> <20130815195447.3ab675b0@pws-pc.ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: please conform to the xdg base directory specification MIME-version: 1.0 Content-type: text/plain; charset=us-ascii This is the second "please conform to XDG" thread in the last few months (last time was users/17726). I mention this because ... On Aug 15, 7:54pm, Peter Stephenson wrote: } } Adding yet more complexity to the initialisation file logic doesn't seem } a great idea, but one thing that could keep everything more or less } under control would be to make ZDOTDIR a colon-separated array (and make } zdotdir an array). ... this suggestion, while fine on its own, does not solve the problem of bootstrapping the value of ZDOTDIR, so zsh would still not "conform to XDG." Unless someone *else* has a good use for a multi-element ZDOTDIR path, there's no benefit in going down this road. Unless of course you're proposing a default of zdotdir=(~/.zsh ~) rather than the current default of unset, a change that has its own set of potential gotchas. } We'd need to decide on the rule for multiple directories: use the first } found, use the first containing initialisation files, use the first file } of each type found by searching through the path... I'd prefer "use the first found" so that dotfiles could be disabled by creating an empty directory. I don't think "first file found of each type" is a wise idea, the files in a particular directory are likely to be related and not necessarily meant to work with files found elsewhere. "First directory containing" would be OK, but means scanning for all the files as soon as any of them is needed. } An empty directory would be equivalent to $HOME. Is "." or anything containing the quivalent of a leading ".." allowed to appear? I tend to think anything not beginning with "/" should just be ignored.