bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 5/8] builtins/source: parse the -i option


From: Phi Debian
Subject: Re: [PATCH v2 5/8] builtins/source: parse the -i option
Date: Tue, 21 May 2024 15:30:52 +0200

On Tue, May 21, 2024 at 1:15 PM Greg Wooledge <greg@wooledge.org> wrote:

> On Tue, May 21, 2024 at 10:12:55AM +0000, Matheus Afonso Martins Moreira
> wrote:
> > > the schizophrenic nature of the feature
> >
> > First the feature was "irritating" ... Now it's "schizophrenic" ?
> > I must be mentally ill for trying to contribute this?
> >
> > Yeah, I'm done.
>
> I don't think "schizophrenic" was used as an insult.  Rather, it looks
> like an attempt to describe the fact that everyone in the thread has a
> different concept and/or experience regarding how 'source' and '.'
> should work.
>
>
Well, what I really meant was that there are 2 directions one with
read/parse the other read/parse/eval and not being able to make a mind,
like the Buridan ass
https://en.wikipedia.org/wiki/Buridan%27s_ass

'import' read/parse (along with a PATH var) make sense and don't break
interfere with source

A 'source' read/parse/eval is there with its semantic and should not go
away.

An 'import' with source look alike and tweaking its flags and semantic is
border line, besides, it and can be implemented in shell only with no bash
modification, there is no perf consideration here, we are not on the perf
path, unless one come up with a source in the inner loop :-)

No offense, just pointing that these two path sounds not mixable, an
implementation of your $BASH_SOURCE_PATH can be all done in shell in one of
your libs, (say your bootstrap lib) whence this one is loaded, it can load
all the others.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]