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

[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 <<EOF ><known_path>/source_wrapper.sh
>     find_file "${1:?Missing File Name }" || return $?
>     source "${FOUND_FILE}"
> EOF
> alias include=source\ "<known_path>/source_wrapper.sh"

The <<EOF needs to be <<'EOF' (or similar), and of course you have to
include the definition of find_file in the wrapper script.