see, it's not really Dying. The problem is that it's NOT dying. It works great to a point.
It runs. It sits there, and it prints out that it's finding 'LINE1' then it waits, then 'LINE2' ... Because in my code you see I have it printing the line that it pulls before passing it on.
print "read[$line]\n";
Is in the read_smdr. The problem is, if I, for instance, chop the data, the return is empty. Even though if I print $line, it shows the full 80 character line. If I pass it to another program, as I have in the code here:
system("./parse_smdr", $line);
the new program reports from it's args the first line perfect:
It'll say:
Parse[LINE1]
from the command in parse_smdr that says:
print "Parse[$line]\n";
Like it's supposed to.
Then the second iteration of READ, it'll pass empty string. No matter what. Even if you just run a standard perl command, the command returns as if it was passed an empty variable....
it's VERY bizzarre.
Mind you, that the FIRST TIME the while loop in read_smdr runs it works PERFECT... | [reply]
[d/l]
[select] |
It would help to see the exact code and output from a
failure. I still don't understand 100% but it sounds
like your failure is on the read side -- that you try
reading from the device and get an empty "line". In
the first read examples, you're opening the device with
O_NDELAY. If I remember correctly, on most *nix
systems, the way that behaves with a terminal device
is that it returns nothing if nothing is available on the
terminal at the time of the read. It seems like that behavior may be matching exactly what you're seeing. I also
believe that an open using O_NDELAY may itself
return immediately, before the terminal device is ready,
which could cause problems that only show up when timing
changes.
In general, reading
directly from terminal devices like this is tricky and error
prone. So you may want to revisit exactly what it is you're
trying to achieve -- something else I can't really gather
from the example so far. The last open is cat'ing the
terminal device and reading from that output. That should
do almost the same thing the opens before it are attempting, but it
should avoid the O_NDELAY issues ... I think.
It would help to know the context the terminal device is
bneing read in -- what's being typed there, how that device
relates to the one the program is running on, etc.
| [reply] |
Here's the skinny.
What I REALLY want to do is just cat the file /dev/ttyS0 and read the resulting ascii characters one line at a time. I have already thought about just capturing a buffered stream of characters, which is what I'm going to do next (Just use sysopen and sysread, then capture characters between /ns and pass them on to the next part.)
If anybody has a suggestion on just reading the damn file and calling a command based on the data off that line, let me know.
And thanks for everybody for looking... I'll let you know if it works!
| [reply] |
I tried missing the O_NDELAY by using sysopen with that option. I also tried a basic cat pipe to avoid that as well. It's driving me crazy because,
(And here's the kicker)
IT STILL PRINTS.
$line prints just fine, no matter how many times it goes through. But if I run ANY function on it, no matter what, the return is always empty.
Why would it print okay, but not return from functions okay?
| [reply] |
