[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:18:49 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 |
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 <<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.
>
- Re: weird problem -- path interpretted/eval'd as numeric expression, (continued)
- Re: weird problem -- path interpretted/eval'd as numeric expression, Linda Walsh, 2013/03/29
- Re: weird problem -- path interpretted/eval'd as numeric expression, Greg Wooledge, 2013/03/29
- Re: weird problem -- path interpretted/eval'd as numeric expression, Stefano Lattarini, 2013/03/29
- Re: weird problem -- path interpretted/eval'd as numeric expression, John Kearney, 2013/03/29
- Re: weird problem -- path interpretted/eval'd as numeric expression, Greg Wooledge, 2013/03/29
- Re: weird problem -- path interpretted/eval'd as numeric expression, John Kearney, 2013/03/29
- Re: weird problem -- path interpretted/eval'd as numeric expression, Pierre Gaston, 2013/03/29
- Re: weird problem -- path interpretted/eval'd as numeric expression, John Kearney, 2013/03/29
- Re: weird problem -- path interpretted/eval'd as numeric expression, Greg Wooledge, 2013/03/29
- Re: weird problem -- path interpretted/eval'd as numeric expression, John Kearney, 2013/03/29
- Re: weird problem -- path interpretted/eval'd as numeric expression,
John Kearney <=
- Re: weird problem -- path interpretted/eval'd as numeric expression, Chet Ramey, 2013/03/30
- Re: weird problem -- path interpretted/eval'd as numeric expression, Linda Walsh, 2013/03/29
- Re: weird problem -- path interpretted/eval'd as numeric expression, John Kearney, 2013/03/29
- Re: weird problem -- path interpretted/eval'd as numeric expression, Linda Walsh, 2013/03/29