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:53:41 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4

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 <<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' ??
> 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 <<EOF
>> 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.










reply via email to

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