Re: weird problem -- path interpretted/eval'd as numeric expression
Dan Douglas wrote:
> Can you whittle this down to the smallest reproducer and post a stand-alone
> synthetic testcase with sample input data that fails?
If I had a clue how to do that, I would, that's why I mentioned
that that **NORMALLY** it works fine.
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
I can work around things in lib by putting 'lib' in my path, but
for things not at the first level...
exporting arrays (and Hashes) was something to make USE of, not a goal.
I wanted to be able to store arbitrary pathnames and the only way to
do that easily is to have them in arrays, since you can't use '\000'
as a separator. I had similar requirements for group names -- I wanted
to test for group membership by name, so I can use Hashes to test
if something 'should' work (actual file permissions will decide security),
but the HASH'ed group tests are to give messages about needing to be
in such and such a group or whether or not to go ahead and try. Attempting
to falsify the _GROUPS_ array would only lead to ugly error messages. ;-)
echo ${_GROUPS_[Remote Desktop Users]}
555
echo ${_GROUPS_[Domain Admins]}
512
I also use similar methods for propagating aliases like
int=declare\ -i
array=declare\ -a
sub=function
my=declare
etc...
'int' and 'sub' are the most useful ones...
>
> If the goal is simulating "exported arrays", there are other methods that
> would probably work out better.
---
Well, if that isn't the goal, but the above are goals, do your methods
apply equally well? Without NULL as a separator, arrays are the only way to
store things without lots of quoting, but they are very difficult to use ...
Try pulling out a groupid from a groupname without a hash...it is doable, but
not nearly so simply.
I've *lived* with the reported bug for at least several months, because I
couldn't
figure out why it failed there but not elsewhere.
It only *fails* when including 'needroot.shh'...
But these two work:
> cd /tmp
> include stdalias.shh #include file or lib/file are generally
> equivalent
> include lib/stdlib.shh
> include Util/urlparts.shh # but this one - Util is a subdir of 'lib'
> (i.e. not in path)
> echo ${_INC[@]} ## keeps track of what has been included so a subsequent
> include won't reinclude
/home/law/bin/lib/stdlib.shh /home/law/bin/lib/Util/urlparts.shh
/home/law/bin/lib/stdalias.shh
#i.e.:
> echo ${_INC[stdalias.shh]}
/home/law/bin/lib/stdalias.shh
The calling script CAN be simple:
#!/bin/bash
include Util/needroot.shh
whoami
> tryroot
./tryroot: line 7: Util/needroot.shh: syntax error: invalid arithmetic operator
(error token is ".shh")
law
--- or if I do include lib/Util/needroot.shh I get the div by 0:
> cat zroot
#!/bin/bash
include lib/Util/needroot.shh
whoami
> zroot
./zroot: line 7: lib/Util/needroot.shh: division by 0 (error token is
"/needroot.shh")
law
Util/needroot.shh works when sourced:
> cat >do_root
#!/bin/bash
source ~/lib/Util/needroot.shh
whoami
Ishtar:tmp> +x do_root
Ishtar:tmp> do_root
root
Oddly, it happens w/needroot even when it doesn't re-execute itself (i.e.
already
running as root!) (but only if it needs to access it via the PATH --
if I'm in a dir like bin, and needroot is in bin/lib/Util/needroot.shh
then it works!
needroot.shh:
#!/bin/bash
shift
declare -xi _needroot+=1
sudo="$(type -P sudo 2>/dev/null)"
if [[ $sudo == "" || ! -e $sudo ]]; then
((_needroot<2)) && echo "warning: sudo not found, executing as normal
user..." >&2
exit 0
else
# echo "UID=$UID, EUID=$EUID"
if ((EUID)); then
((_needroot<2)) && exec $(eval echo sudo "$0" "$@")
echo "Need root: Fatal error" >&2
exit -1
fi
fi
((1))
--- function include:
declare -A _INC
export _INC
function include {
[[ $1 ]] || return 1
local fnc="$1"
[[ $PATH != ${_SPATH:-} || ${#_FPATH[@]} -lt 1 ]] && {
unset _FPATH
local -xa _FPATH=( $(IFS=:;echo $PATH) )
export _SPATH="$PATH"
}
# function seems to exit here when including needroot when it's not given via a
relative name
# i.e. would need to find it off of the PATH
if [[ -z ${_INC["${fnc:-}"]:-} ]]; then
local pw
for pw in "${_FPATH[@]}"; do
[[ ${pw:0-1:1} != / ]] && pw+='/'
local fn="${pw}${fnc}"
if [[ -r $fn || -r $fn.shh && fn="$fn.shh" ]]; then
source "$fn" || {
stat=$?
echo "Error: include of \"$fnc\" did not return 0 status"
return $stat
}
_INC["$fnc"]="$fn"
return 0
fi
done
echo "Cannot find \"$fnc\" in \"$PATH\"" >&2
exit 2
fi
}
export -f include
Those are the basic
parts
Re: weird problem -- path interpretted/eval'd as numeric expression
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
}
Re: weird problem -- path interpretted/eval'd as numeric expression
On 03/29/2013 12:57 PM, 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
> }
>
AFAIK, this won't work if the sourced file contains declarations
like 'declare -a foo=(1 2)'; those variables will be made local to
the 'include' function. Perhaps an alias could work better (but
writing it might involve some unpleasant tricks with eval etc.)
Regards,
Stefano
Re: weird problem -- path interpretted/eval'd as numeric expression
Am 29.03.2013 12:57, schrieb Greg Wooledge:
> 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
> }
>
Actually I've had trouble
IFS=: read -ra paths <<< "$PATH"
and embedded new lines.
I think this is better
find_file() {
local IFS=:
for dir in $PATH; do
[[ ! -r $dir/$1 ]] || continue
FOUND_FILE="$dir/$1"
return 0
done
echo "could not find '$1' in PATH" >&2
return 1
}
include() {
local FOUND_FILE
find_file "${1:?Missing File Name }" || return $?
source "${FOUND_FILE}"
}
includeExt() {
local FOUND_FILE
local PATH=${1:?Missing Search Path}
find_file "${2:?Missing File Name}" || return $?
source "${FOUND_FILE}"
}
Ideally what I want to do is
alias include=source\ "$(find_file "${1}")"
but that doesn't work in bash and I still haven't found a way around the
problem.
The only way I can think to do it is to use a second file.
cat
Re: weird problem -- path interpretted/eval'd as numeric expression
On Fri, Mar 29, 2013 at 03:11:07PM +0100, John Kearney wrote:
> Actually I've had trouble
>
> IFS=: read -ra paths <<< "$PATH"
>
> and embedded new lines.
A directory with a newline in its name, in your PATH? Terrifying.
> I think this is better
> find_file() {
> local IFS=:
> for dir in $PATH; do
But that one's vulnerable to globbing issues if a directory has a
wildcard character in its name. If you're concerned about newlines
then you should be just as concerned with ? or *, I should think.
Workarounds:
1) In yours, use set -f and set +f around unquoted $PATH to suppress
globbing.
2) In mine, use -d '' on the read command, and manually strip the
trailing newline that <<< adds to the final element.
3) In mine, use -d '' on the read command, and use < <(printf %s "$PATH")
so there isn't an added trailing newline to strip.
> Ideally what I want to do is
> alias include=source\ "$(find_file "${1}")"
> but that doesn't work in bash and I still haven't found a way around the
> problem.
I can't think of an alias workaround off the top of my head either.
Even Simon Tatham's "magic aliases" require a helper function, which leads
back to the variable scope issue, the avoidance of which was the whole
reason to attempt an alias (instead of a function) in the first place
> The only way I can think to do it is to use a second file.
>
> cat find_file "${1:?Missing File Name }" || return $?
> source "${FOUND_FILE}"
> EOF
> alias include=source\ "/source_wrapper.sh"
The <
Re: weird problem -- path interpretted/eval'd as numeric expression
Am 29.03.2013 15:30, schrieb Greg Wooledge:
> On Fri, Mar 29, 2013 at 03:11:07PM +0100, John Kearney wrote:
>> Actually I've had trouble
>>
>> IFS=: read -ra paths <<< "$PATH"
>>
>> and embedded new lines.
> A directory with a newline in its name, in your PATH? Terrifying.
why not :) its a great way to make sure only my scripts work on my system;).
>> I think this is better
>> find_file() {
>> local IFS=:
>> for dir in $PATH; do
> But that one's vulnerable to globbing issues if a directory has a
> wildcard character in its name. If you're concerned about newlines
> then you should be just as concerned with ? or *, I should think.
Strangely enough I that hasn't been as much of a problem. But a good point.
> Workarounds:
>
> 1) In yours, use set -f and set +f around unquoted $PATH to suppress
> globbing.
I actually have that in my code :( coding off the top of your head is
always a bit sloppy :).
>
> 2) In mine, use -d '' on the read command, and manually strip the
> trailing newline that <<< adds to the final element.
consider
dethrophes@dethace ~
$ read -ra vals -d '' <<< $'lkjlksda\n adasd\n:sdasda:'
dethrophes@dethace ~
$ echo ${vals[0]}
lkjlksda
I meant to update your wiki about it but I forgot.
I guess read uses gets not fread and that truncates the line anyway.
>
> 3) In mine, use -d '' on the read command, and use < <(printf %s "$PATH")
> so there isn't an added trailing newline to strip.
>
>> Ideally what I want to do is
>> alias include=source\ "$(find_file "${1}")"
>> but that doesn't work in bash and I still haven't found a way around the
>> problem.
> I can't think of an alias workaround off the top of my head either.
> Even Simon Tatham's "magic aliases" require a helper function, which leads
> back to the variable scope issue, the avoidance of which was the whole
> reason to attempt an alias (instead of a function) in the first place
I'm actually almost convinced that it just isn't possible.
>> The only way I can think to do it is to use a second file.
>>
>> cat > find_file "${1:?Missing File Name }" || return $?
>> source "${FOUND_FILE}"
>> EOF
>> alias include=source\ "/source_wrapper.sh"
> The < include the definition of find_file in the wrapper script.
?? why <<'EOF' ??
No I don't need to include the function I would declare it like this.
find_file() {
local dir IFS=:
FOUND_FILE=""
set -f
for dir in $PATH; do
[[ ! -r ${dir}/$1 ]] || continue
FOUND_FILE="${dir}/$1"
done
set +f
[ -z "${FOUND_FILE:-}" ] || echo "could not find '$1' in PATH" >&2
return ${FOUND_FILE:+1}
}&& echo 'find_file "${1:?Missing File Name }" && source "${FOUND_FILE}"'
>/tmp/source_wrapper.sh && alias include=source\ "/tmp/source_wrapper.sh"
Re: weird problem -- path interpretted/eval'd as numeric expression
Oh and FYI
IFS=: read
may change the global IFS on some shells I think.
Mainly thinking of pdksh right now.
IFS=: ls # local
ls_wrap(){
ls
}
IFS=: ls_wrap # Changes global IFS
I think it was the same with builtins, but not sure right now.
Thats why I always use wrapper functions and local to do that sort of
thing now.
Am 29.03.2013 15:30, schrieb Greg Wooledge:
> On Fri, Mar 29, 2013 at 03:11:07PM +0100, John Kearney wrote:
>> Actually I've had trouble
>>
>> IFS=: read -ra paths <<< "$PATH"
>>
>> and embedded new lines.
> A directory with a newline in its name, in your PATH? Terrifying.
>
>> I think this is better
>> find_file() {
>> local IFS=:
>> for dir in $PATH; do
> But that one's vulnerable to globbing issues if a directory has a
> wildcard character in its name. If you're concerned about newlines
> then you should be just as concerned with ? or *, I should think.
>
> Workarounds:
>
> 1) In yours, use set -f and set +f around unquoted $PATH to suppress
> globbing.
>
> 2) In mine, use -d '' on the read command, and manually strip the
> trailing newline that <<< adds to the final element.
>
> 3) In mine, use -d '' on the read command, and use < <(printf %s "$PATH")
> so there isn't an added trailing newline to strip.
>
>> Ideally what I want to do is
>> alias include=source\ "$(find_file "${1}")"
>> but that doesn't work in bash and I still haven't found a way around the
>> problem.
> I can't think of an alias workaround off the top of my head either.
> Even Simon Tatham's "magic aliases" require a helper function, which leads
> back to the variable scope issue, the avoidance of which was the whole
> reason to attempt an alias (instead of a function) in the first place
>
>> The only way I can think to do it is to use a second file.
>>
>> cat > find_file "${1:?Missing File Name }" || return $?
>> source "${FOUND_FILE}"
>> EOF
>> alias include=source\ "/source_wrapper.sh"
> The < include the definition of find_file in the wrapper script.
>
Re: weird problem -- path interpretted/eval'd as numeric expression
On Fri, Mar 29, 2013 at 5:10 PM, John Kearney wrote:
> consider
> dethrophes@dethace ~
> $ read -ra vals -d '' <<< $'lkjlksda\n adasd\n:sdasda:'
>
> dethrophes@dethace ~
> $ echo ${vals[0]}
> lkjlksda
>
> I meant to update your wiki about it but I forgot.
> I guess read uses gets not fread and that truncates the line anyway.
>
you miss the IFS part:
IFS=: read -ra vals -d '' <<< $'lkjlksda\n adasd\n:sdasda:'
echo "${vals[0]}"
(IFS contains \n by default)
Re: weird problem -- path interpretted/eval'd as numeric expression
Am 29.03.2013 16:23, schrieb Pierre Gaston:
> On Fri, Mar 29, 2013 at 5:10 PM, John Kearney wrote:
>> consider
>> dethrophes@dethace ~
>> $ read -ra vals -d '' <<< $'lkjlksda\n adasd\n:sdasda:'
>>
>> dethrophes@dethace ~
>> $ echo ${vals[0]}
>> lkjlksda
>>
>> I meant to update your wiki about it but I forgot.
>> I guess read uses gets not fread and that truncates the line anyway.
>>
> you miss the IFS part:
> IFS=: read -ra vals -d '' <<< $'lkjlksda\n adasd\n:sdasda:'
> echo "${vals[0]}"
>
> (IFS contains \n by default)
Ok that works, I must have somehow misunderstood the description.
Oh well thanks that makes he world a little more sane.
Re: weird problem -- path interpretted/eval'd as numeric expression
On Fri, Mar 29, 2013 at 04:10:22PM +0100, John Kearney wrote:
> consider
> dethrophes@dethace ~
> $ read -ra vals -d '' <<< $'lkjlksda\n adasd\n:sdasda:'
>
> dethrophes@dethace ~
> $ echo ${vals[0]}
> lkjlksda
You forgot to set IFS=: for that read.
imadev:~$ IFS=: read -ra vals -d '' <<< $'lkjlksda\n adasd\n:sdasda:'
imadev:~$ declare -p vals
declare -a vals='([0]="lkjlksda\
adasd\
" [1]="sdasda" [2]="\
")'
> I meant to update your wiki about it but I forgot.
> I guess read uses gets not fread and that truncates the line anyway.
No, that's not correct.
> >> cat >> find_file "${1:?Missing File Name }" || return $?
> >> source "${FOUND_FILE}"
> >> EOF
> >> alias include=source\ "/source_wrapper.sh"
> > The < > include the definition of find_file in the wrapper script.
> ?? why <<'EOF' ??
Because if you don't quote any of the characters in the here document
delimiter, the expansions such as "${FOUND_FILE}" will be done by the
shell that's processing the redirection. I believe you want the code
to appear in the output file. Therefore you want to quote some or all
of the characters in the delimiter.
Compare:
imadev:~$ cat < echo "$HOME"
> EOF
echo "/net/home/wooledg"
imadev:~$ cat <<'EOF'
> echo "$HOME"
> EOF
echo "$HOME"
On Fri, Mar 29, 2013 at 04:18:49PM +0100, John Kearney wrote:
> Oh and FYI
> IFS=: read
> may change the global IFS on some shells I think.
> Mainly thinking of pdksh right now.
If those shells have such a bug, then you'd need to bring it up on THEIR
bug mailing list. This is bug-bash. ;-)
In any case, I've never seen such a bug, and the pdksh to which I have
access does not display it:
...
Get:1 http://ftp.us.debian.org/debian/ squeeze/main pdksh i386 5.2.14-25 [265
kB]
...
arc3:~$ pdksh
\h:\w$ echo a:b:c > /tmp/frob
\h:\w$ IFS=: read a b < /tmp/frob
\h:\w$ rm /tmp/frob
\h:\w$ echo "$IFS"
\h:\w$
This is a fundamental feature that's commonly used. If it were so
egregiously broken I think more people would have noticed it.
off topic IFS=: read changing the global IFS
On Fri, Mar 29, 2013 at 5:18 PM, John Kearney wrote: > Oh and FYI > IFS=: read > may change the global IFS on some shells I think. > Mainly thinking of pdksh right now. it seems ok on this netbsd machine: PD KSH v5.2.14 99/07/13.2 IFS=f read
Re: weird problem -- path interpretted/eval'd as numeric expression
Am 29.03.2013 16:36, schrieb Greg Wooledge:
> On Fri, Mar 29, 2013 at 04:10:22PM +0100, John Kearney wrote:
>> consider
>> dethrophes@dethace ~
>> $ read -ra vals -d '' <<< $'lkjlksda\n adasd\n:sdasda:'
>>
>> dethrophes@dethace ~
>> $ echo ${vals[0]}
>> lkjlksda
> You forgot to set IFS=: for that read.
>
> imadev:~$ IFS=: read -ra vals -d '' <<< $'lkjlksda\n adasd\n:sdasda:'
> imadev:~$ declare -p vals
> declare -a vals='([0]="lkjlksda\
> adasd\
> " [1]="sdasda" [2]="\
> ")'
>
>> I meant to update your wiki about it but I forgot.
>> I guess read uses gets not fread and that truncates the line anyway.
> No, that's not correct.
>
cat >> The <>> include the definition of find_file in the wrapper script.
>> ?? why <<'EOF' ??
> Because if you don't quote any of the characters in the here document
> delimiter, the expansions such as "${FOUND_FILE}" will be done by the
> shell that's processing the redirection. I believe you want the code
> to appear in the output file. Therefore you want to quote some or all
> of the characters in the delimiter.
>
> Compare:
>
> imadev:~$ cat <> echo "$HOME"
>> EOF
> echo "/net/home/wooledg"
>
> imadev:~$ cat <<'EOF'
>> echo "$HOME"
>> EOF
> echo "$HOME"
Didn't know that, Actually I forgot to escape them in my example.
>
> On Fri, Mar 29, 2013 at 04:18:49PM +0100, John Kearney wrote:
>> Oh and FYI
>> IFS=: read
>> may change the global IFS on some shells I think.
>> Mainly thinking of pdksh right now.
> If those shells have such a bug, then you'd need to bring it up on THEIR
> bug mailing list. This is bug-bash. ;-)
It was just a warning, and I don't think there is a pdksh bug list.
>
> In any case, I've never seen such a bug, and the pdksh to which I have
> access does not display it:
>
> ...
> Get:1 http://ftp.us.debian.org/debian/ squeeze/main pdksh i386 5.2.14-25 [265
> kB]
> ...
> arc3:~$ pdksh
> \h:\w$ echo a:b:c > /tmp/frob
> \h:\w$ IFS=: read a b < /tmp/frob
> \h:\w$ rm /tmp/frob
> \h:\w$ echo "$IFS"
>
>
> \h:\w$
>
> This is a fundamental feature that's commonly used. If it were so
> egregiously broken I think more people would have noticed it.
try this
f(){ echo "ddd${IFS}fff"; } ; f ; IFS=KKK f; f
This just didn't work as I would expect on ubuntu pdksh.
I didn't look into it regarding builtins, I just stopped using that
feature, as it seemed to be wonky.
the original platform I saw it on was QNX6.5.0/BB10.
Re: weird problem -- path interpretted/eval'd as numeric expression
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.
completion of '../' with symlink component in CWD path
I just encountered the following behaviour. Set up a directory structure like: mkdir basedir cd basedir mkdir -p dir1/dir2 ln -s dir1/dir2 dir2link cd dir2link now, you're sitting in dir2link, and you type: cd ../ and hit the Tab key. The possible completions are shown as 'dir1' and 'dir2link', i.e. the contents of basedir. And if you finish the command as: cd ../dir1 It will change to dir1. However, if you instead do this while your current working directory is 'dir2link': echo foo > ../dir1/bar It fails with "No such file or directory". The problem is that some commands are "smart" and "know" how you got to your current working dir -- bash knows that you're in a symlink and that the parent dir of the *symlink* (not the actual directory you're in) is 'basedir'. However, this is not the literal meaning of the '..' directory entry according to the filesystem. Some parts of bash use the "smart" behaviour (cd and completion), and some parts use what the filesystem actually says, i.e. that '..' inside 'dir2' is 'dir1', not 'basedir' (output redirection). ...after thinking about this, I've managed to confuse myself and am not sure which behaviour should be considered correct. ~Felix.
Re: weird problem -- path interpretted/eval'd as numeric expression
Am 29.03.2013 18:53, schrieb Linda Walsh:
>
> 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.
>
Like this then ?
unset INCLUDED ;
declare -A INCLUDED
find_file() {
local dir
FOUND_FILE=""
[ $((INCLUDED[${1%.sh}]+=1)) -eq 1 ] || return 1
while IFS= read -rd ':' dir ;do
#echo "trying : ${dir}/${1%.sh}.sh"
[[ -r ${dir}/${1%.sh}.sh ]] || continue
FOUND_FILE="${dir}/${1%.sh}.sh"
echo "found : ${FOUND_FILE}"
done <<< "${PATH}"
[ -n "${FOUND_FILE:-}" ] || echo "could not find '$1' in PATH" >&2
return ${FOUND_FILE+1}
} && echo 'find_file "${1:?Missing File Name }" && source "${FOUND_FILE}"'
>/tmp/source_wrapper.sh && alias include=source\ "/tmp/source_wrapper.sh"
I actually tested this one and it seems to work ok.
Re: completion of '../' with symlink component in CWD path
Marcel Giannelia wrote: > The problem is that some commands are "smart" and "know" how you > got to your current working dir -- bash knows that you're in a symlink > and that the parent dir of the *symlink* (not the actual directory > you're in) is 'basedir'. > > However, this is not the literal meaning of the '..' directory entry > according to the filesystem. Some parts of bash use the "smart" > behaviour (cd and completion), and some parts use what the filesystem > actually says, i.e. that '..' inside 'dir2' is 'dir1', not > 'basedir' (output redirection). > > ...after thinking about this, I've managed to confuse myself and am not > sure which behaviour should be considered correct. I consider the 'set -o physical' behavior the canonical and correct form. Try it. You might like it. Because it isn't possible to have the shell create a 100% correct facade over the top of everything. And even if it could I am not sure that is desired. However the casual user often prefers the logical view. If you never use symlinks and never rename or move directories then it doesn't matter. Bob
Re: weird problem -- path interpretted/eval'd as numeric expression
John Kearney wrote:
> Am 29.03.2013 18:53, schrieb Linda Walsh:
>> 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.
>>
>
> Like this then ?
>
> unset INCLUDED ;
> declare -A INCLUDED
> find_file() {
> local dir
> FOUND_FILE=""
> [ $((INCLUDED[${1%.sh}]+=1)) -eq 1 ] || return 1
> while IFS= read -rd ':' dir ;do
> #echo "trying : ${dir}/${1%.sh}.sh"
> [[ -r ${dir}/${1%.sh}.sh ]] || continue
> FOUND_FILE="${dir}/${1%.sh}.sh"
> echo "found : ${FOUND_FILE}"
> done <<< "${PATH}"
> [ -n "${FOUND_FILE:-}" ] || echo "could not find '$1' in PATH" >&2
> return ${FOUND_FILE+1}
> } && echo 'find_file "${1:?Missing File Name }" && source "${FOUND_FILE}"'
> >/tmp/source_wrapper.sh && alias include=source\ "/tmp/source_wrapper.sh"
>
>
> I actually tested this one and it seems to work ok.
---
I'll have to drop it in and see what happens! Always one for experimenting! ;-)
