<br><br><div class="gmail_quote">On Mon, May 7, 2012 at 5:40 PM, Simon Peter <span dir="ltr"><<a href="mailto:speter@inf.ethz.ch" target="_blank">speter@inf.ethz.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
- trap "pkill -P $$" SIGINT can not kill previous cat process<br>
properly,<br></div><div class="im">
Can you point out why it is failing? It seems to be working here.<br>
Unfortunately, your fix will end up killing any cat process in the<br>
system, which is not desirable.<br>
My understanding is that the script's process id ($$) is not the same on<br>
each run. So the second run of the script fail to kill the cat processes<br>
created by the first run of the script. Is this reasonable?<br>
</div></blockquote>
<br>
You shouldn't be starting the script twice at the same time. AFAIK, the serial console cannot be opened multiple times. The next time you start the script, the $$ should point to the right process, no?</blockquote><div>
<br></div><div>I suddenly realized that I mis-understood the trap command. It's used to kill all the processes created by this script when user hit crtl+c to terminate, right? What a good script trick that I didn't know before. Please forgive my poor script knowledge. Hope this didn't bother you :-) </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- "cat /dev/crbif0rb0c${i}ttyS0 | grep . --line-buffered &" in<br>
the for<br>
loop can not display the<br>
outputs properly: only empty lines are printed.<br>
Thanks for fixing this one. I'm not sure why it prints only empty<br>
lines in your case, though I see no problem applying your fix.<br>
I don't know why it fails here either. I tried stackoverflow[1][2] by<br>
get no useful answer. Personally, I suspect that there are some control<br>
bytes in the UART stream that fools grep, but I'm not sure...<br>
</blockquote>
<br></div>
In fact, it prints only non-empty lines. And it should also have an -a added, in case non-printable characters are being sent. I've fixed this.<span class="HOEnZb"><font color="#888888"><br>
<br>
Simon<br>
<br>
</font></span></blockquote></div><br>