Hi
Yes, you are right, I figured that out myself that there should be no
</dev/ttyX on the "done" line.
This is my current script:
# wait a bit (this is in case it is respawning fast)
sleep 10
# Make sure the boudrate is set correctly
stty -F /dev/ttyUSB0 57600
exec </dev/ttyUSB0
stty igncr
while read -r; do
echo "[$(date)]: $REPLY"
>>/usb/BigDrive/CurrentCost/CurrentCost_$(date +"%Y_%m_%d").log
done
It works fine.
I like your approach as well. Which one do you think uses least resource?
In mine is the .log file opened for writing for every line or is it
kept open until the name changes?
Should I worry about that?
Regards
On 30 March 2010 05:50, Cathey, Jim <[email protected]> wrote:
> You have missed the point of the empty exec,
> which is to change I/O assignment of the entire
> executing script. You don't need (or want) the
> </dev/ttyX on the "done" line anymore. The
> point of the exec was to switch everything
> to that device so that it wouldn't get closed
> and reopened around the stty. Some tty settings
> are persistent across close, some are not. Why
> ask for trouble?
>
> Exec is also your friend on the output side.
> Redirect once, and inside your read loop check
> the day. When it changes do an exec to change
> the output log file, and continue on to log normally,
> and repeat the read loop. Pseudo-shell-code:
>
> fileday = date today
> exec <tty >filedayfile
> stty
> while read ; do
> if day != fileday
> fileday = date today
> exec >filedayfile
> echo line
> done
>
> You're already calling date once inside the loop.
> Put its value in a shell variable and then extract
> the day-of-week from the beginning for the test,
> and use the whole thing for your log. Won't really
> be any slower, if you're worried about that sort
> of thing. (Inside the redirection you can call date
> again if that's easier, it'll only happen once per
> day!)
>
> -- Jim
>
>
>
> -----Original Message-----
> From: Michael Hagedorn [mailto:[email protected]]
> Sent: Saturday, March 27, 2010 12:01 AM
> To: Cathey, Jim
> Cc: [email protected]; Michael Abbott; [email protected]
> Subject: Re: Logging serial port data to file
>
> Ok, here we go:
>
> I didn't compile the dos2unix command into my busybox, therefore I
> didn't try it yet.
>
> tr great command good to know about, but I didn't get it to work
> correctly, I guess once a line has been read a line will be written.
>
> The
>
> exec </dev/ttyUSB0
> stty igncr
>
> while read -r; do
> echo "[$(date)]: $REPLY"
> done </dev/ttyUSB0 >>/usb/BigDrive/CurrentCost/CurrentCost.log
>
> works perfect.
> Thanks for your help.
>
> As for the extra while loop to keep my logger alive if the usb2serial
> has been unplugged and wait to be plugged in again, that didn't work.
> I unplugged the usb2serial and plugged it back in. For some reason it
> then showed up on /dev/ttyUSB1 (normally the script would die and the
> usb would show up as /dev/ttyUSB0 again). I guess the script was
> blocking /dev/ttyUSB0 in some way. Do usb2serial devices have
> identifiers? If yes I could iterate through them to find the correct
> one (I want to log multiple usb2serial devices later on).
>
> I will leave that extra loop out for the moment and try the inittab
> option. How fast is the respawning happing?
>
>
> Ok here is one more question. I would like to have each day go into
> its own file, I tried:
>
> done </dev/ttyUSB0 >>/usb/BigDrive/CurrentCost/CurrentCost$(date
> +"%Y_%m_%d_%M").log
>
> That didn't work (I tried it with a %M in there so that I wouldn't
> have to wait for a day). I guessed that that wouldn't work since the
> output is probably once opened and then just continuously streamed to.
> What would be the best way to do this?
>
> Thanks again for your help
>
> Regards.
>
>
> On 26 March 2010 10:15, Cathey, Jim <[email protected]> wrote:
>> Things in the /etc/inittab are automatically
>> respawned when they fail. That's its main job.
>>
>> Your script closes the file between the stty and
>> the read loop. You are counting on the settings
>> being persistent. That's why I used the exec in
>> my last example.
>>
>> Alternately, the last "done" could be "done </dev/ttyUSB0",
>> and take out the other input redirections. What you
>> want is a single program entity that's operating on
>> the intended device.
>>
>> I think your 10-second retry would work, but be sure
>> that the USB device doesn't end up as your controlling
>> terminal, giving your script a SIGHUP when it's disconnected.
>>
>> You need to read up on the TTY driver, a ^D will likely
>> also end the read loop.
>>
>> -- Jim
>>
>>
>>
>> -----Original Message-----
>> From: Michael Hagedorn [mailto:[email protected]]
>> Sent: Thursday, March 25, 2010 2:00 PM
>> To: [email protected]
>> Cc: Cathey, Jim; Michael Abbott; [email protected]
>> Subject: Re: Logging serial port data to file
>>
>> Thanks a lot for your input, I will try them tonight and report back
>> which one works the best.
>>
>> Another thing is that if somebody pulls out the usb 2 serial adapter
>> the script fails and exits.
>> I want it to continue or restart if the device has been put back.
>>
>> I have come up with this (but haven't tried it yet):
>>
>> while true; do
>>
>> # Make sure the boudrate is set correctly
>> stty -F /dev/ttyUSB0 57600
>>
>> while read -r; do
>> echo "[$(date)]: $REPLY"
>> done </dev/ttyUSB0 >>/usb/BigDrive/CurrentCost/CurrentCost.log
>>
>> # Try again in 10 seconds
>> sleep 10
>> done
>>
>>
>> Rather than trying to read from /dev/ttyUSB0 is there a way to check whether
>> it is connected?
>>
>>
>> Regards
>>
>> On 26 March 2010 06:34, Doug Clapp <[email protected]> wrote:
>>>
>>>
>>> Cathey, Jim wrote:
>>>>>
>>>>> Is there an easy way to disregard lines that contain only control
>>>>> characters or filter the text?
>>>>>
>>>>
>>>> Not trivially. As you've been shown, "tr -d" is your
>>>> buddy.
>>>
>>> Another possibility is to pipe through dos2unix (rather than tr) to remove
>>> the CR characters. Ultimately you have to decide which method works best
>>> for you.
>>>
>>> Doug Clapp
>>
>>
>
>
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
