Date: Mon, 3 May 1999 17:21:03 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Michel de Ruiter <Michel AT smr DOT nl>
cc: "'DJGPP workers'" <djgpp-workers AT delorie DOT com>
Subject: Re: v2.03: wrapping up
In-Reply-To: <B0FEA00E82A7D1118BFB00A0CC990278213295@ARGON>
Message-ID: <Pine.SUN.3.91.990503170904.2999A-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Mon, 3 May 1999, Michel de Ruiter wrote:

> The solution
> Eli proposed, using ?default? for the default value however
> bothers me a bit. In particular, I don't like the fact, that
> yet another syntax convention is invented. I understand the
> already existing notations for "use this value if empty", like
> DJGPP.ENV's + or Bash's ${var-value} cannot be used. So I
> think the ?default? solution remains. Or maybe {default},
> [default] or (default)

My rationale for this notation went like this:

  - we must have a default, since env vars are not set all too often;
  - the syntax should allow simple and fast processing, since put_path
    is a work-horse used by many library functions.

?default? was chosen because `?' cannot appear in file names.  I could 
use other characters, like `*' or `"' (the double quote), but they didn't 
seem more attractive.  However, if people like them better, changing 
that is simple.

> so the following would be readable:
> 
> /dev/env/C_INCLUDE_PATH{/dev/env/DJDIR{/djgpp}}/include

{} is not a good idea as it is special to Bash and therefore it would be 
difficult to drag such a name through configure scripts (I'm thinking 
about "./configure --prefix=/dev/env/DJDIR" etc.); [] and () can appear 
in file names (rare, I know, but possible).  Other things I considered 
involved two or more characters, like ?: etc.; but this complicates the 
code, so I've chosen not to use them.

> Would it be a good idea to add the default possibility to the
> DJGPP.ENV syntax somehow?

If a default is part of the feature, why do you need something special 
for DJGPP.ENV?  The DJGPP.ENV file itself won't be found anyway, unless 
$DJDGPP is set.