zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <p.stephenson@samsung.com>
To: Zsh Hackers' List <zsh-workers@zsh.org>
Subject: Re: The default $fpath
Date: Mon, 08 Sep 2014 11:23:28 +0100	[thread overview]
Message-ID: <20140908112328.24371de3@pwslap01u.europe.root.pri> (raw)
In-Reply-To: <140907140122.ZM12385@torch.brasslantern.com>

On Sun, 07 Sep 2014 14:01:22 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> } The proposal is simply to provide a directory where there's some
> } reasonable chance it will be found by all installations of the shell on
> } the same system regardless of configuration.
> 
> Actually, I think the proposal is to provide a directory where all OTHER
> softwares' configuration systems can install shell functions so that they
> are found by all installations of zsh on ANY system, regardless of the
> local-zsh-builder's and/or system-zsh-packager's idea of the path to the
> functions provided by zsh itself.

Yes, indeed, the idea is to make this as global as possible.  If you
happen not to use this directory, that's fine: (i) the shell itself and
the standard installation stuff don't care (ii) presumably, therefore,
you've made your own arrangements for fpath, which is the best guarantee
of consistency on your system anyway.

> } [...] If this builtin default becomes configurable
> } to use different directories the whole advantage is lost; it's far better
> } to use common run-time code to ensure a non-default directory.
> 
> This point, however, holds true either way.  I just think it's impossible
> to promise that the directory will exist; certainly the zsh installer
> should not unilaterally create it.

Yes, I agree with both points.  I don't think that removes its utility,
though.

> } I'd really like to know if there are any problems caused by *this*
> } proposal, adding /usr/local/share/zsh/site-functions to the compiled-in
> } path.
> 
> I can't think of any; presumably the configure-time (?) code for this
> would resemble
> 
>     if [ X$ac_default_prefix != X/usr/local ]
>     then fixed_sitefndir=/usr/local/zsh/site-functions
>     elif [ X$tzsh_name != Xzsh ]
>     then fixed_sitefndir=/usr/local/zsh/site-functions
>     else fixed_sitefndir=''
>     fi
> 
> and then zsh.mdd would use something like
> 
>     echo '#define FIXED_FPATH_DIR "'$(fixed_sitefndir)'"' >> zshpaths.h.tmp;
> 
> and finally somewhere in Src/init.c the fpath would be prefixed with the
> value of FIXED_FPATH_DIR if it is non-empty.

OK, so that's an answer to my other open question: you're suggesting (i)
if the prefix is /usr/local and this is a standard zsh installation
we keep things the way they are (ii) otherwise the new component is
the first thing to be tried in the default fpath.

> The worst that happens is that /usr/local is a remote file system (which
> would seem rather unlikely) and zsh gets slowed down every time fpath is
> searched for a directory there that doesn't exist.

Does seem a bit perverse...  we could add a --disable-fixed-sitenfndir
for the paranoid.  In other words, this is a simple boolean; either you
want the shell to be compatible with this pseudostandard, or you don't.

pws


  reply	other threads:[~2014-09-08 10:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-06 12:00 Tanu Kaskinen
2014-09-06 16:06 ` Frank Terbeck
2014-09-06 18:45 ` Peter Stephenson
2014-09-06 19:10   ` Frank Terbeck
2014-09-06 23:04     ` Peter Stephenson
2014-09-07  3:44       ` Bart Schaefer
2014-09-07 18:31         ` Peter Stephenson
2014-09-07 19:37           ` Vin Shelton
2014-09-07 19:53             ` Tanu Kaskinen
2014-09-07 20:40               ` Peter Stephenson
2014-09-07 21:01                 ` Bart Schaefer
2014-09-08 10:23                   ` Peter Stephenson [this message]
2014-09-08 11:16                     ` Frank Terbeck
2014-09-20 19:04                       ` Peter Stephenson
2014-09-20 19:36                         ` Peter Stephenson
2014-09-20 20:00                           ` Peter Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140908112328.24371de3@pwslap01u.europe.root.pri \
    --to=p.stephenson@samsung.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).