tcpdump + IFS = no sense?

Ok, perhaps one of the experts here can help. I'm just trying to write
a small script that will start a tcpdump. The dump will be started
with a variable for tcpdump's parameters. This works fine:

cmd="-i eth0"
tcpdump $cmd

BUT, if I then add an IFS command before it (to eventually allow me to
read the parameters from a config file) it doesn't work. This fails:

IFS="
"
cmd="-i eth0"
tcpdump $cmd

with a "tcpdump: ioctl: No such device"

I've tried it with Redhat EL3 and FC5 with the same results. Can
someone explain what the heck's going on?

Thanks!
Tony

On 29 Aug 2006 08:49:46 -0700, (E-Mail Removed) wrote:
> Ok, perhaps one of the experts here can help. I'm just trying to write
> a small script that will start a tcpdump. The dump will be started
> with a variable for tcpdump's parameters. This works fine:

> cmd="-i eth0"
> tcpdump $cmd

> BUT, if I then add an IFS command before it (to eventually allow me to
> read the parameters from a config file) it doesn't work. This fails:

> IFS="
> "
> cmd="-i eth0"
> tcpdump $cmd

> with a "tcpdump: ioctl: No such device"
> I've tried it with Redhat EL3 and FC5 with the same results. Can
> someone explain what the heck's going on?

bash can't parse the command string properly because you changed the
field separator. What are you setting IFS to?

$IFS
internal field separator
This variable determines how Bash recognizes fields, or word
boundaries when it interprets character strings.
$IFS defaults to whitespace (space, tab, and newline), but may be
changed, for example, to parse a comma-separated data file. Note that
$* uses the first character held in $IFS. See Example 5-1.

--
Dale Dellutri <(E-Mail Removed)> (lose the Q's)

I'm setting it to a carriage return:

IFS="
"

As I've done a million times before. The result is the ability to read
a text file one line at a time rather than one word at a time. That
functionality still works fine, it's just that tcpdump is choking.

Dale Dellutri wrote:
> On 29 Aug 2006 08:49:46 -0700, (E-Mail Removed) wrote:
> > Ok, perhaps one of the experts here can help. I'm just trying to write
> > a small script that will start a tcpdump. The dump will be started
> > with a variable for tcpdump's parameters. This works fine:
>
> > cmd="-i eth0"
> > tcpdump $cmd
>
> > BUT, if I then add an IFS command before it (to eventually allow me to
> > read the parameters from a config file) it doesn't work. This fails:
>
> > IFS="
> > "
> > cmd="-i eth0"
> > tcpdump $cmd
>
> > with a "tcpdump: ioctl: No such device"
> > I've tried it with Redhat EL3 and FC5 with the same results. Can
> > someone explain what the heck's going on?
>
> bash can't parse the command string properly because you changed the
> field separator. What are you setting IFS to?
>
> $IFS
> internal field separator
> This variable determines how Bash recognizes fields, or word
> boundaries when it interprets character strings.
> $IFS defaults to whitespace (space, tab, and newline), but may be
> changed, for example, to parse a comma-separated data file. Note that
> $* uses the first character held in $IFS. See Example 5-1.
>
> --
> Dale Dellutri <(E-Mail Removed)> (lose the Q's)

(E-Mail Removed) wrote:

> I'm setting it to a carriage return:
>
> IFS="
> "
>
> As I've done a million times before. The result is the ability to read
> a text file one line at a time rather than one word at a time. That
> functionality still works fine, it's just that tcpdump is choking.

With IFS set to just a newline, bash interprets "tcpdump -i eth0" as
"tcpdump" "-i eth0" instead of "tcpdump" "-i" "eth0", which is what it
expects and requires.

DS

Wierd, I've never experienced this, but putting "eval" in front solved
it.

Thanks!
David Schwartz wrote:
> (E-Mail Removed) wrote:
>
> > I'm setting it to a carriage return:
> >
> > IFS="
> > "
> >
> > As I've done a million times before. The result is the ability to read
> > a text file one line at a time rather than one word at a time. That
> > functionality still works fine, it's just that tcpdump is choking.
>
> With IFS set to just a newline, bash interprets "tcpdump -i eth0" as
> "tcpdump" "-i eth0" instead of "tcpdump" "-i" "eth0", which is what it
> expects and requires.
>
> DS

Wierd, I've never experienced this, but putting "eval" in front solved
it.

Thanks.

David Schwartz wrote:
> (E-Mail Removed) wrote:
>
> > I'm setting it to a carriage return:
> >
> > IFS="
> > "
> >
> > As I've done a million times before. The result is the ability to read
> > a text file one line at a time rather than one word at a time. That
> > functionality still works fine, it's just that tcpdump is choking.
>
> With IFS set to just a newline, bash interprets "tcpdump -i eth0" as
> "tcpdump" "-i eth0" instead of "tcpdump" "-i" "eth0", which is what it
> expects and requires.
>
> DS