Date: Mon, 24 Feb 1997 10:13:37 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Daisuke Aoyama <jack AT st DOT rim DOT or DOT jp>
cc: "Alexander V. Lukyanov" <lav AT video DOT yars DOT free DOT net>,
        djgpp-workers AT delorie DOT com
Subject: RE: bashb7.zip is now available.
In-Reply-To: <199702232011.FAA08447@mail.st.rim.or.jp>
Message-ID: <Pine.SUN.3.91.970224101222.3675B-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Mon, 24 Feb 1997, Daisuke Aoyama wrote:

> Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
> >
> > On Sun, 23 Feb 1997, Alexander V. Lukyanov wrote:
> > 
> > > IMHO, the proper solution is to support SYSROOT in the c library.
> > > That way, bash won't need to guess what is a pathname and what is not.
> > > The same about //d/.
> > 
> > I'm afraid that's a libc rewrite.  I don't have time to even think about
> > all the implications of such a change.  For starters, all the places
> 
> I support almost Eli's comment. If use / or //d/ at  your own risk,
> a rewrite (_put_path?) may be needed. But that is last choice.

Alas, `_put_path' is not where the problems are.  The knowledge about
what a Microsoft-style pathname looks like is scattered across the
entire library in the various filename-related functions, which will
all have to be rewritten.  Some examples are `_fixpath', `stat',
`opendir', `rename'... do I need to continue?

And btw, pushing the //d/ feature into DJGPP's libc will mean that
non-DJGPP programs will break when you set PATH_SEPARATOR=: which is
hardly desired, since people use `bash' as their primary interactive
shell.