On 3/3/12 5:09 AM, John Kearney wrote:
>>> On the other hand, there is the possibility to add FPATH and autoload like
>>> in ksh93 ...
>>> I haven't think to much about it but my guess is that it would really be
>>> easy to implement a module system with that.
An autoload that uses FPATH is trivi
It could be even furthermore separated from the traditional "source" and a
new keyword introduced like "require" a la lisp which would be able to do
things like:
1) load the file, searching in the BASH_LIB_PATH (or other variables) for a
file with optionally the extension .sh or .bash
2) only lo
On 03/03/2012 09:43 AM, Stefano Lattarini wrote:
> On 03/03/2012 08:28 AM, Pierre Gaston wrote:
>> On Fri, Mar 2, 2012 at 9:54 AM, Stefano Lattarini wrote:
>>
>>> Or here is a what it sounds as a marginally better idea to me: Bash could
>>> start supporting a new environment variable like "BASHLIB"
On 03/03/2012 08:28 AM, Pierre Gaston wrote:
> On Fri, Mar 2, 2012 at 9:54 AM, Stefano Lattarini wrote:
>
>> Or here is a what it sounds as a marginally better idea to me: Bash could
>> start supporting a new environment variable like "BASHLIB" (a' la'
>> PERL5LIB)
>> or "BASHPATH" (a' la' PYTHONPA
On Fri, Mar 2, 2012 at 9:54 AM, Stefano Lattarini <
stefano.lattar...@gmail.com> wrote:
> On 03/02/2012 02:50 AM, Chet Ramey wrote:
> > On 2/29/12 2:42 PM, Eric Blake wrote:
> >
> > In the middle of the histrionics and gibberish, we have the nugget of an
> > actual proposal (thanks, Eric):
> >
> >
Chet Ramey wrote:
On 2/29/12 2:42 PM, Eric Blake wrote:
In the middle of the histrionics and gibberish, we have the nugget of an
actual proposal (thanks, Eric):
--- Original Message
Subject: bash 4.2 breaks source finding libs in lib/filename...
Date: Tue, 28 Feb 2012 17
On 03/02/2012 02:50 AM, Chet Ramey wrote:
> On 2/29/12 2:42 PM, Eric Blake wrote:
>
> In the middle of the histrionics and gibberish, we have the nugget of an
> actual proposal (thanks, Eric):
>
> [to allow `.' to look anchored relative pathnames up in $PATH]
>
>> About the best we can do
On 2/29/12 2:42 PM, Eric Blake wrote:
In the middle of the histrionics and gibberish, we have the nugget of an
actual proposal (thanks, Eric):
[to allow `.' to look anchored relative pathnames up in $PATH]
> About the best we can do is accept a patch (are you willing to write it?
> if no
On Wednesday 29 February 2012 17:53:21 Linda Walsh wrote:
> Eric Blake wrote:
> > On 02/29/2012 12:26 PM, Linda Walsh wrote:
> >>> Any pathname that contains a / should not be subject to PATH searching.
> >
> > Agreed - as this behavior is _mandated_ by POSIX, for both sh(1) and for
> > execlp(2)
Greg Wooledge wrote:
On Wed, Feb 29, 2012 at 11:26:06AM -0800, Linda Walsh wrote:
Greg Wooledge wrote:
Any pathname that contains a / should not be subject to PATH searching.
You are alone in this opinion -- as most application don't follow that rule.
??
Try '
r is _mandated_ by POSIX, for both sh(1)
>> and for execlp(2) and friends.
>
>
> Is it that you don't read english as a first language, or are you
> just trying to be argumentative?'
>
> I said: ---- Original Message Subject: bash 4.2 breaks
> so
e, or are you just
trying to be argumentative?'
I said:
Original Message
Subject: bash 4.2 breaks source finding libs in lib/filename...
Date: Tue, 28 Feb 2012 17:34:21 -0800
From: Linda Walsh
To: bug-bash
Why was this functionality removed in non-posix mode?
So, your arg
On 02/29/2012 12:26 PM, Linda Walsh wrote:
>> Any pathname that contains a / should not be subject to PATH searching.
Agreed - as this behavior is _mandated_ by POSIX, for both sh(1) and for
execlp(2) and friends.
> Pathnames that *start* with '/' are called an "absolute" pathnames,
>
> while p
On Wed, Feb 29, 2012 at 11:26:06AM -0800, Linda Walsh wrote:
> Greg Wooledge wrote:
> >Any pathname that contains a / should not be subject to PATH searching.
> You are alone in this opinion -- as most application don't follow that rule.
??
> Try 'C', if you include a include file with "/", it s
Greg Wooledge wrote:
On Tue, Feb 28, 2012 at 05:34:21PM -0800, Linda Walsh wrote:
How can one get the same behavior as before and look up files
relative to PATH regardless of them having a '/' in them?
What? That sounds like it WAS a bug before, and you had somehow
interpreted it as a feat
On Wed, Feb 29, 2012 at 3:30 PM, Greg Wooledge wrote:
> On Tue, Feb 28, 2012 at 05:34:21PM -0800, Linda Walsh wrote:
>> How can one get the same behavior as before and look up files
>> relative to PATH regardless of them having a '/' in them?
>
> What? That sounds like it WAS a bug before, and yo
On Tue, Feb 28, 2012 at 05:34:21PM -0800, Linda Walsh wrote:
> How can one get the same behavior as before and look up files
> relative to PATH regardless of them having a '/' in them?
What? That sounds like it WAS a bug before, and you had somehow
interpreted it as a feature. And now you're ask
I have several files that source the lib files by expecting
the name of the lib to be checked against PATH --
but this no longer works when the library is in lib/filename.
How can one get the same behavior as before and look up files
relative to PATH regardless of them having a '/' in them?
Why
18 matches
Mail list logo
