Very Computer

I am using IFS to parse out a line in sh (actually, bash under Linux).

I have something like:

        foo=`IFS=/;set -- /foo/bar/bletch/some/filename;echo $5`

However, it doesn't work.  After the first 'set', everything is in $1, not
in the other args (although it does convert the slashes into spaces).
To get what I really want, I have to do:

        foo=`IFS=/;set -- /foo/bar/bletch/some/filename;set -- $1;echo $5`

This correctly gets me 'some' (Note that $1 is null).

But why do I need the additional 'set' command?  Is this WAD (*) ?
It seems to me that the first form ought to work.

(*) Working as designed.

************************************************************************
Are you joking?  DOS applications in WinNT?  WinNT is just a toy
you install on your machine, to give more shine to OS/2's glory.
                - Mikael Wahlgren -

          hundreds, if not thousands, of dollars, every time he posts -
************************************************************************
rwvpf wpnrrj ibf ijrfer

$ foo=`IFS=/;set -- /foo/bar/bletch/some/filename;echo $5`
$ echo $foo

--

GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.

...

Quote:>It works for me, in /usr/bin/sh under Solaris 2.5.1.  

>$ foo=`IFS=/;set -- /foo/bar/bletch/some/filename;echo $5`
>$ echo $foo

Can there be a sense in which this is a feature, or does it just have to
considered a bash bug?  Anyway, I guess on Linux, I'm stuck.

************************************************************************

                        The Official JM Personality Test

Part I. Answer these questions:

        1) You are visiting a friend in his office and you notice two
           calendars on adjacent walls.  On one wall, is a Three Stooges
           calendar; on the other, one of the Sports Illustrated Swimsuit
           Edition.  Which one is more likely to hold your
           interest/attention?

        2) You are driving on an urban freeway (not at rush hour) and
           there is a traffic snarl, that looks like it could go on for
           some time.  As you crawl forward, you notice an exit to a
           surface street that looks like it might get you where you
           are going more quickly than the freeway will.  Are you
           likely to take the exit or would you just stay where you
           are and duke it out with everybody else?

        3) You go into a restaurant and order a Rueben sandwhich.
           When it arrives, you are not pleased with its
           price/performance ratio.  Are you more likely to say that
           it is not big enough or that it is too expensive?

Part II. Now, write an essay for each one telling what you think it
        says about you/What the purpose of each question is.

          hundreds, if not thousands, of dollars, every time he posts -
************************************************************************
rwvpf wpnrrj ibf ijrfer

|> ...
|>> It works for me, in /usr/bin/sh under Solaris 2.5.1.  
|>>
|>> $ foo=`IFS=/;set -- /foo/bar/bletch/some/filename;echo $5`
|>> $ echo $foo

|> Yup, you're right.  It is a bash problem.  I just tested it on this Solaris
|> system (which has both sh and bash), and sh got it right; bash got it wrong.

Actually bash gets it right.

|> Can there be a sense in which this is a feature, or does it just have to
|> considered a bash bug?  Anyway, I guess on Linux, I'm stuck.

It's not a bug, it's a security feature.  Bash does IFS splitting only on
the result of expansions.  Use the following:

$ foo=`IFS=/;set -- /foo/bar/bletch/some/filename$empty;echo $5`

--
Andreas Schwab                                      "And now for something

...

Quote:>Actually bash gets it right.

>|> Can there be a sense in which this is a feature, or does it just have to
>|> considered a bash bug?  Anyway, I guess on Linux, I'm stuck.

>It's not a bug, it's a security feature.  Bash does IFS splitting only on
>the result of expansions.  Use the following:

>$ foo=`IFS=/;set -- /foo/bar/bletch/some/filename$empty;echo $5`

I had the feeling that there was some reason why somebody would consider it
a feature - that is why I asked the question above in the way I did.
I am familiar with the security implications of IFS.

Note, BTW, that my actual example in practice is something like:

        /foo/bar/bletch/some/file*

where I am doing filename expansion - yet in that case, it doesn't do the
IFS thing.  So, it is not just any expansion...

************************************************************************
        "Tucked away in winter quarters,
        Gainsborough's sons and Buchan's daughters,
        Blue of *, clean-lined, and handsome,
        Priced beyond a prince's ransom,
        Where no danger can befall them,
        Rest till next year's Classics call them."

                        - Will H Ogilvie -

          hundreds, if not thousands, of dollars, every time he posts -
************************************************************************
rwvpf wpnrrj ibf ijrfer

[cut]

Quote:>  |> Can there be a sense in which this is a feature, or does it just have to
>  |> considered a bash bug?  Anyway, I guess on Linux, I'm stuck.
>  It's not a bug, it's a security feature.  Bash does IFS splitting only on
>  the result of expansions.  Use the following:
>  $ foo=`IFS=/;set -- /foo/bar/bletch/some/filename$empty;echo $5`

cut -d/ -f5 avoids the problem altogether, although it does spawn a process.

--

  See another pointless homepage at <URL:http://home.pages.de/~naddy/>.

: Can someone explain me, what is the security risk?
: I looked at the FAQ, and found that IFS is considered a security risk,
: just as PATH is. (PATH and SHELL I can understand, but IFS !?).

in [original non-POSIX] bourne shell, if IFS was set to (let's say...)
"x", any script spawned with this environment would, when encountering
an "exit" command, actually execute command "e" with argument "it".
Now, if one were to _write_ such a script "e", then it would execute
under the privileges of the owner of the original script! Bad news.

Kornshell (and other POSIX-compliant shells) will avoid this by
mandating an initial value of <space><tab> for IFS regardless of
the exported value of IFS in the environment and only using the
value of IFS to do word-separation upon variable substitution and
read inputs.

-Brian

Heiner
--
  -------------------------------------------------------------

/ Milky Way, Solar System, Earth, Europe, Bavaria, Nuernberg /
-------------------------------------------------------------

As others have pointed out, there are certainly a million ways to do this;
one of the attractions of using IFS is that no processes are forked.

I ended up with:

 foo=`IFS=/;set -- /foo/bar/bletch/some/file*;eval set \\$$#;eval echo \\$$#`

which works nicely (although I typed that in from memory, so there may
be typos).  Once one get used to it, one sees that the actual behavior of
the shell is the desirable behavior.

************************************************************************
Pure balls. (David Spade)

          hundreds, if not thousands, of dollars, every time he posts -
************************************************************************
rwvpf wpnrrj ibf ijrfer