# for statement

**URL:** <https://community.unix.com/t/for-statement/248935>\
**Category:** UNIX for Dummies Questions & Answers\
**Created:** [September 9, 2009, 4:26pm UTC](https://community.unix.com/t/for-statement/248935 "2009-09-09T16:26:03Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Amit\_Sura](https://community.unix.com/letter_avatar/amit_sura/32/5_5575768a8748004e209b776fc1b2916d.png) [@Amit\_Sura](https://community.unix.com/u/Amit_Sura)\
**Post date:** [September 9, 2009, 4:26pm UTC](https://community.unix.com/t/for-statement/248935/1 "2009-09-09T16:26:03Z")

</div>

removed the link due to some issues and i got the information i needed

---

<div class="post-metadata">

**Author:** ![BubbaJoe](https://community.unix.com/user_avatar/community.unix.com/bubbajoe/32/1175_2.png) [@BubbaJoe](https://community.unix.com/u/BubbaJoe)\
**Post date:** [September 9, 2009, 5:21pm UTC](https://community.unix.com/t/for-statement/248935/2 "2009-09-09T17:21:02Z")

</div>

I believe the issue is the "$i:" is not being substituted correctly. You may try "${i}:"

---

<div class="post-metadata">

**Author:** ![DeCoTwc](https://community.unix.com/letter_avatar/decotwc/32/5_5575768a8748004e209b776fc1b2916d.png) [@DeCoTwc](https://community.unix.com/u/DeCoTwc)\
**Post date:** [September 9, 2009, 5:21pm UTC](https://community.unix.com/t/for-statement/248935/3 "2009-09-09T17:21:31Z")

</div>

have you tried doing the loop with just echoing $i? Is it possible that one of the results contains a character that is throwing off the second command that references $i?

Just throwing a swag out there.

PS: do you work in the cable industry?

---

<div class="post-metadata">

**Author:** ![TonyFullerMalv](https://community.unix.com/user_avatar/community.unix.com/tonyfullermalv/32/1090_2.png) [@TonyFullerMalv](https://community.unix.com/u/TonyFullerMalv)\
**Post date:** [September 9, 2009, 5:24pm UTC](https://community.unix.com/t/for-statement/248935/4 "2009-09-09T17:24:00Z")

</div>

You need to break it down to see what is spitting out the error although normally I would have expected the "complainant" to announce themselves, e.g.:

```nohighlight
bash: Bad : modifier in $ (").

```

or

```nohighlight
gdb: Bad : modifier in $ (").

```

Did the "complainant" identify itself?

Both:

```nohighlight
for file in `ls *usb*`; do echo -n "${file}:"; done

```

and

```nohighlight
for file in *usb*; do echo -n "${file}:"; done

```

(run in /dev/) work okay (note the curly braces around the variable, good scripting practice).

What does running the gdb alone (with one file specified) do, then add the grep, then add the first cut, then add the second cut, that way you will find out which part is causing the error.

Can't help any more than that as I have no core files to play with...

---

<div class="post-metadata">

**Author:** ![Azhrei](https://community.unix.com/letter_avatar/azhrei/32/5_5575768a8748004e209b776fc1b2916d.png) [@Azhrei](https://community.unix.com/u/Azhrei)\
**Post date:** [September 9, 2009, 5:33pm UTC](https://community.unix.com/t/for-statement/248935/5 "2009-09-09T17:33:47Z")

</div>

You don't say what operating system or shell this is using. I'm going to guess some distro of Linux and the Bash shell...

> [@amit sura](#):
>
> get below response 'Bad : modifier in $ (").'

Check the filenames that your wildcard expands to. It's likely there's a character in there that when expanded in the gdb command line is giving the shell some grief.

Some rules for typing in shell commands:

1. Always put double quotes around your dollar-sign variables. (It's only wrong about 3 times in 1,000 so you've got a 99.7% chance of being right. :))

2. Use $(...) instead of `...`. (Won't matter in this particular case, but it's a good idea for a variety of reasons.)

3. Don't use a bunch of pipes when they're not necessary. (In this case using gdb is way overkill as the file command will likely give you the right data. Using a command like set -- $(file "$i") eliminates all of the pipes and only requires a single fork/exec because the set command is builtin to the shell.)

Otherwise I agree with TonyFullerMalv; you need to go back to basics and test out each piece of your command line. In particular, you need to know what data is going into the loop (such as the filenames).
