problem with WHILE clause

May 13, 2014 at 06:09:26
Specs: Red Hat, x86-64
I'm using the below command to use the input from each line of $checkfile_c to be used as a new command with column 2 used as a parameter for the call to another program ...

... but, the "my_command" is an interactive program, and what it does is this : it just replies the NEXT line of the WHILE command as input to that line. That wasn't the idea.
Question is 2 fold, why does he do that ? And; how to fix, in the best manner this should be fixed.

I liked to avoid creating a temporary file, and run it, although I know that works ...

cat $checkfile_c | awk ' { print $2 } ' | while read line
my_command $line


Hi there.

See More: problem with WHILE clause

Report •

May 13, 2014 at 07:01:43
Not sure what you're asking. You just want to pass the second field to my_command's stdin? That's simple enough.

cat $checkfile_c | cut -f 2 -d ' ' | my_command

How To Ask Questions The Smart Way

Report •

May 13, 2014 at 08:43:41
That doesn't work here, he just displays nothing, and ends ...

The file under $checkfile_c has got many lines, and the problem is that some lines (basically the next one(s) on the one being processed) is used as user input.

Hi there.

Report •

May 14, 2014 at 07:16:01

If I am interpreting your question correctly, part of the input of my_command is interactive?

Not every Unix/Linux command is designed as a pipe so Razor's method won't work. Maybe redirecting might work like this:

my_command < $line

However, $line probably has to be a file name.

In order to really help you, we need more info about how my_command expects input.

message edited by nails

Report •

Related Solutions

May 16, 2014 at 07:32:37
It's not that easy I admit, but "my_command" basically is a script that asks for different input, using the READ command (with a timeout).

Whatever is in $line, that is not the input from any question, it's a parameter for that same script.

I've changed the code to :

cat $checkfile_c | awk ' { print $2 } ' | while read line
my_command $line < /dev/null

The initial issue is gone (unwanted info being "read"), but this way there's no input whatsoever.
Which on itself is not a big problem, but better would be if ...

Hi there.

Report •

May 16, 2014 at 15:02:06
If redirecting from /dev/null, works for you fine, but you can always put that "different input" in a file provided you know what the input is. For example, if the user needed to input the string "first" and a carriage return, following by a carriage return, and finally a different string, place the input into a file called input.txt:



my_command < /path_to/input.txt

Report •

June 3, 2014 at 05:12:42
I know that that would work, but I would like to keep the option open to actually reply something to those question(s). Reverse redirecting /dev/null doesn't allow that either, but now I do not have any wrong input being processed, at least. Actually, I have all empty input, which is not wrong, but not optimal either.

Hi there.

Report •

Ask Question