[Top][All Lists]

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

Re: weird problem -- path interpretted/eval'd as numeric expression

From: Linda Walsh
Subject: Re: weird problem -- path interpretted/eval'd as numeric expression
Date: Fri, 29 Mar 2013 10:53:33 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100228 Lightning/0.9 Thunderbird/ Mnenhy/

Greg Wooledge wrote:
> On Fri, Mar 29, 2013 at 12:41:46AM -0700, Linda Walsh wrote:
>>      include was designed to search the path for functions that
>> are relative paths.  While the normal sourcepath allows searching for
>> filenames on the search path, I don't believe (please correct if I am wrong
>> and this works now, as it would make life much simpler) that the PATH will
>> be searched if you give it something like:
>> source lib/Util/sourcefile.shh
> Is that all you want?  Here:
> include() {
>     local paths dir
>     IFS=: read -ra paths <<< "$PATH"
>     for dir in "${paths[@]}"; do
>       if [[ -r $dir/$1 ]]; then
>           source "$dir/$1"
>           return
>       fi
>     done
>     echo "could not find '$1' in PATH" >&2
>     return 1
> }
It  also doesn't keep track of the previously sourced files so as to
not 're-source' them if one of the files you 'source' also sources a file.

It also allows one to optionally leave off the extension, but other than
those additions... yeah... that's close...

The idea is *mainly* to be able to read in functions and aliases..

Vars expected to 'survive' for those funcs or aliases are exported...but
that may not be enough to get them out of the local context...not sure.

reply via email to

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