for statement

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

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

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?

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.:

bash: Bad : modifier in $ (").

or

gdb: Bad : modifier in $ (").

Did the "complainant" identify itself?

Both:

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

and

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...

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...

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).