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
do
my_command $line
donethanks
Hi there.
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
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.
@User123... 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
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
do
my_command $line < /dev/null
doneThe 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.
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: first
second
my_command < /path_to/input.txt
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.
Ad Choices