bug-bash
[Top][All Lists]
Advanced

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

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


From: John Kearney
Subject: Re: weird problem -- path interpretted/eval'd as numeric expression
Date: Fri, 29 Mar 2013 16:10:22 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4

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 <<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.
?? 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"





reply via email to

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