Hi Duy,

On Thu, 8 Nov 2018, Duy Nguyen wrote:

> On Thu, Nov 8, 2018 at 2:14 PM Johannes Schindelin
> <johannes.schinde...@gmx.de> wrote:
> >
> > On Wed, 7 Nov 2018, Jeff King wrote:
> >
> > > All that said, if we're just interested in allowing this for config,
> > > then we already have such a wrapper function: git_config_pathname().
> >
> > Good point. I agree that `git_config_pathname()` is a better home for this
> > feature than `expand_user_path()`.
> >
> > But now I have a really crazy idea: how about ~~/ssl/certs/ca-bundle.crt?
> > The `~` prefix is *already* a reserved character, and while it would
> > probably not be super intuitive to have `~~` be expanded to the runtime
> > prefix, at least it would be less ambiguous than `$RUNTIME_PREFIX` (which
> > *is* a valid directory name).
> 
> One thing I had in mind when proposing $VARIABLE is that it opens up a
> namespace for us to expand more things (*) for example $GIT_DIR (from
> ~/.gitconfig).
> 
> (*) but in a controlled way, it may look like an environment variable,
> but we only accept a selected few. And it's only expanded at the
> beginning of a path.

I understand that desire, and I even agree. But the fact that it looks
like an environment variable, but is not, is actually a point in favor of
*not* doing this. It would violate the principle of least astonishment.

The form `<RUNTIME_PREFIX>/abc/def` would not be confused with anything
that it is not, I would think. The only thing against this form (at least
that I can think of) is that some people use this way to talk about paths
that vary between different setups, with the implicit assumption that the
reader will "interpolate" this *before* applying. So for example, when I
tell a user to please edit their <GIT_DIR>/config, I implicitly assume
that they know to not type out, literally, <GIT_DIR> but instead fill in
the correct path.

Ciao,
Dscho

> > Of course, `~~` is also a valid directory name, but then, so is `~` and we
> > do not have any way to specify *that* because `expand_user_path()` will
> > always expand it to the home directory. Or am I wrong? Do we have a way to
> > disable the expansion?
> >
> > Ciao,
> > Dscho
> 
> 
> 
> -- 
> Duy
> 

Reply via email to