Simple Shell Script programming Problem.

Hi there. Im trying to use a Linux Box to control a simple water sprinkling system. The water sprinkler needs simple text commands via a serial port followed by a carriage return char. If I use a simple command like echo "command" > /dev/ttyS0 the command is sent OK, but its followed by a line feed plus carriage return, and the line feed char causes the sprinkler to reject the command. I can turn off the line feed with echo -n but it also turns off the carriage ret char as well. There must be a simple way to do this. thanks MD

On Sat, 20 Dec 2003 at 00:31 GMT, Maurie Daly wrote: > Hi there. > Im trying to use a Linux Box to control a simple water sprinkling > system. > The water sprinkler needs simple text commands via a serial port > followed by a carriage return char. > > If I use a simple command like > > echo "command" > /dev/ttyS0 the command is sent OK, but its followed > by a line feed plus carriage return, and the line feed char causes the > sprinkler to reject the command. > > I can turn off the line feed with echo -n but it also turns off the > carriage ret char as well. printf "%s\r" "command" -- Chris F.A. Johnson http://cfaj.freeshell.org =================================================================== My code (if any) in this post is copyright 2003, Chris F.A. Johnson and may be copied under the terms of the GNU General Public License

mauried@tpg.com.au (Maurie Daly) wrote: >Hi there. >Im trying to use a Linux Box to control a simple water sprinkling >system. >The water sprinkler needs simple text commands via a serial port >followed by a carriage return char. > >If I use a simple command like > >echo "command" > /dev/ttyS0 the command is sent OK, but its followed >by a line feed plus carriage return, and the line feed char causes the >sprinkler to reject the command. > >I can turn off the line feed with echo -n but it also turns off the >carriage ret char as well. > >There must be a simple way to do this. > >thanks >MD If you do "stty -aF /dev/ttyS0" and inspect the results you will almost certainly discover something like the following line, opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel The offending parameter is "onlcr", which the man page for stty will tell you means, [-]onlcr translate newline to carriage return-newline Hence, if that parameter is set, and stty reports "onlcr" as opposed to "-onlcr", the serial port driver sends CRNL whenever it sees NL. So the trick is to use stty to turn that off before you start sending data to the serial port. stty -onlcr < /dev/ttyS0 Another way might be to just turn off all output post processing stty -opost < /dev/ttyS0 -- Floyd L. Davidson <http://web.newsguy.com/floyd_davidson> Ukpeagvik (Barrow, Alaska) floyd@barrow.com

On Sat, 20 Dec 2003 00:31:16 GMT, Maurie Daly <mauried@tpg.com.au> wrote: > > > Hi there. > Im trying to use a Linux Box to control a simple water sprinkling > system. > The water sprinkler needs simple text commands via a serial port > followed by a carriage return char. > > If I use a simple command like > > echo "command" > /dev/ttyS0 the command is sent OK, but its followed > by a line feed plus carriage return, and the line feed char causes the > sprinkler to reject the command. > > I can turn off the line feed with echo -n but it also turns off the > carriage ret char as well. > > There must be a simple way to do this. > > thanks > MD > echo -e "command\r" AC

On 20 Dec 2003 02:39:23 GMT, "Chris F.A. Johnson" <c.fa.johnson@rogers.com> wrote: >On Sat, 20 Dec 2003 at 00:31 GMT, Maurie Daly wrote: >> Hi there. >> Im trying to use a Linux Box to control a simple water sprinkling >> system. >> The water sprinkler needs simple text commands via a serial port >> followed by a carriage return char. >> >> If I use a simple command like >> >> echo "command" > /dev/ttyS0 the command is sent OK, but its followed >> by a line feed plus carriage return, and the line feed char causes the >> sprinkler to reject the command. >> >> I can turn off the line feed with echo -n but it also turns off the >> carriage ret char as well. > >printf "%s\r" "command" > >-- > Chris F.A. Johnson http://cfaj.freeshell.org > Thanks Chris, Ive been away from Unix too long (you forget these things.) MD

On Sat, 20 Dec 2003 at 03:14 GMT, Alan Connor wrote: > On Sat, 20 Dec 2003 00:31:16 GMT, Maurie Daly <mauried@tpg.com.au> wrote: >> >> >> Hi there. >> Im trying to use a Linux Box to control a simple water sprinkling >> system. >> The water sprinkler needs simple text commands via a serial port >> followed by a carriage return char. >> >> If I use a simple command like >> >> echo "command" > /dev/ttyS0 the command is sent OK, but its followed >> by a line feed plus carriage return, and the line feed char causes the >> sprinkler to reject the command. >> >> I can turn off the line feed with echo -n but it also turns off the >> carriage ret char as well. >> >> There must be a simple way to do this. >> >> thanks >> MD >> > > echo -e "command\r" You mean echo -ne "command\r". $ echo -e "command\r" | od -c 0000000 c o m m a n d \r \n 0000011 $ echo -ne "command\r" | od -c 0000000 c o m m a n d \r 0000010 -- Chris F.A. Johnson http://cfaj.freeshell.org =================================================================== My code (if any) in this post is copyright 2003, Chris F.A. Johnson and may be copied under the terms of the GNU General Public License

Maurie Daly wrote: > Hi there. > Im trying to use a Linux Box to control a simple water sprinkling > system. > The water sprinkler needs simple text commands via a serial port > followed by a carriage return char. > > If I use a simple command like > > echo "command" > /dev/ttyS0 the command is sent OK, but its followed > by a line feed plus carriage return, and the line feed char causes the > sprinkler to reject the command. > > I can turn off the line feed with echo -n but it also turns off the > carriage ret char as well. > > There must be a simple way to do this. echo -n -e "command\r" ECHO(1) FSF ECHO(1) NAME echo - display a line of text SYNOPSIS echo [OPTION]... [STRING]... DESCRIPTION Echo the STRING(s) to standard output. -n do not output the trailing newline -e enable interpretation of the backslash-escaped characters \r is the "backslash-escaped" sequence for "carriage return" -- Lew Pitcher Master Codewright and JOAT-in-training Registered Linux User #112576 (http://counter.li.org/) Slackware - Because I know what I'm doing.

In article <t0c3sb.sfr.ln@merlin.l6s4x6-4.ca>, Lew Pitcher <lpitcher@sympatico.ca> wrote: > Maurie Daly wrote: > > Hi there. > > Im trying to use a Linux Box to control a simple water sprinkling > > system. > > The water sprinkler needs simple text commands via a serial port > > followed by a carriage return char. > > > > If I use a simple command like > > > > echo "command" > /dev/ttyS0 the command is sent OK, but its followed > > by a line feed plus carriage return, and the line feed char causes the > > sprinkler to reject the command. > > > > I can turn off the line feed with echo -n but it also turns off the > > carriage ret char as well. > > > > There must be a simple way to do this. > > echo -n -e "command\r" Careful -- if you just run "echo" you'll usually get your shell's implementation of it, which doesn't necessarily match echo.1 . To have them match, either run /bin/echo or check your shell's man page. Of course, if you've fudged things to run /bin/echo before the builtin 'echo', then all bets are off -- -eben ebQenW1@EtaRmpTabYayU.rIr.OcoPm home.tampabay.rr.com/hactar rm -f /bin/laden

ebenONE@tampabay.ARE-ARE.com.unmunge (Hactar) writes: > In article <t0c3sb.sfr.ln@merlin.l6s4x6-4.ca>, > Lew Pitcher <lpitcher@sympatico.ca> wrote: > > Maurie Daly wrote: > > > Hi there. > > > Im trying to use a Linux Box to control a simple water sprinkling > > > system. > > > The water sprinkler needs simple text commands via a serial port > > > followed by a carriage return char. > > > > > > If I use a simple command like > > > > > > echo "command" > /dev/ttyS0 the command is sent OK, but its followed > > > by a line feed plus carriage return, and the line feed char causes the > > > sprinkler to reject the command. > > > > > > I can turn off the line feed with echo -n but it also turns off the > > > carriage ret char as well. > > > > > > There must be a simple way to do this. > > > > echo -n -e "command\r" > > Careful -- if you just run "echo" you'll usually get your shell's > implementation of it, which doesn't necessarily match echo.1 . To > have them match, either run /bin/echo or check your shell's man > page. Of course, if you've fudged things to run /bin/echo before > the builtin 'echo', then all bets are off Yes, better to use printf(1). Joe

In article <m3zndlu3je.fsf@invalid.address>, <joe@invalid.address> wrote: > ebenONE@tampabay.ARE-ARE.com.unmunge (Hactar) writes: > > > In article <t0c3sb.sfr.ln@merlin.l6s4x6-4.ca>, > > Lew Pitcher <lpitcher@sympatico.ca> wrote: > > > > > > echo -n -e "command\r" > > > > Careful -- if you just run "echo" you'll usually get your shell's > > implementation of it, which doesn't necessarily match echo.1 . To > > have them match, either run /bin/echo or check your shell's man > > page. Of course, if you've fudged things to run /bin/echo before > > the builtin 'echo', then all bets are off > > Yes, better to use printf(1). It's hard to tell if you're trolling. But just in case you're not: [eben@pc eben]$ type printf printf is a shell builtin [eben@pc eben]$ which printf /usr/bin/printf -- -eben ebQenW1@EtaRmpTabYayU.rIr.OcoPm home.tampabay.rr.com/hactar VIRGO: All Virgos are extremely friendly and intelligent - except for you. Expect a big surprise today when you wind up with your head impaled upon a stick. -- Weird Al, _Your Horoscope for Today_

ebenONE@tampabay.ARE-ARE.com.unmunge (Hactar) writes: > In article <m3zndlu3je.fsf@invalid.address>, <joe@invalid.address> wrote: > > ebenONE@tampabay.ARE-ARE.com.unmunge (Hactar) writes: > > > > > In article <t0c3sb.sfr.ln@merlin.l6s4x6-4.ca>, > > > Lew Pitcher <lpitcher@sympatico.ca> wrote: > > > > > > > > echo -n -e "command\r" > > > > > > Careful -- if you just run "echo" you'll usually get your > > > shell's implementation of it, which doesn't necessarily match > > > echo.1 . To have them match, either run /bin/echo or check your > > > shell's man page. Of course, if you've fudged things to run > > > /bin/echo before the builtin 'echo', then all bets are off > > > > Yes, better to use printf(1). > > It's hard to tell if you're trolling. But just in case you're not: > > [eben@pc eben]$ type printf > printf is a shell builtin > [eben@pc eben]$ which printf > /usr/bin/printf No, I'm not trolling. Whether it's a shell builtin or an external program, it behaves in a more predictable manner than echo does. The fact that you have to specify any control characters with printf means that you don't have to worry about the portability problems with echo. Joe

In article <m3vfo9tvv8.fsf@invalid.address>, <joe@invalid.address> wrote: > ebenONE@tampabay.ARE-ARE.com.unmunge (Hactar) writes: > > In article <m3zndlu3je.fsf@invalid.address>, <joe@invalid.address> wrote: > > > > > > Yes, better to use printf(1). > > > > It's hard to tell if you're trolling. But just in case you're not: > > > > [eben@pc eben]$ type printf > > printf is a shell builtin > > [eben@pc eben]$ which printf > > /usr/bin/printf > > No, I'm not trolling. Whether it's a shell builtin or an external > program, it behaves in a more predictable manner than echo does. The > fact that you have to specify any control characters with printf means > that you don't have to worry about the portability problems with echo. More consistent across implementations, sure. I still wouldn't use printf(1) to find out how the builtin printf behaves. -- -eben ebQenW1@EtaRmpTabYayU.rIr.OcoPm home.tampabay.rr.com/hactar Are you confident that you appear to be professional in your electronic communication? Consider this: A: No Q: Can I top post? from nick@xx.co.uk

ebenONE@tampabay.ARE-ARE.com.unmunge (Hactar) writes: > In article <m3vfo9tvv8.fsf@invalid.address>, <joe@invalid.address> wrote: > > ebenONE@tampabay.ARE-ARE.com.unmunge (Hactar) writes: > > > In article <m3zndlu3je.fsf@invalid.address>, > > <joe@invalid.address> wrote: > > > > > > > > Yes, better to use printf(1). > > > > > > It's hard to tell if you're trolling. But just in case you're > > > not: > > > > > > [eben@pc eben]$ type printf > > > printf is a shell builtin > > > [eben@pc eben]$ which printf > > > /usr/bin/printf > > > > No, I'm not trolling. Whether it's a shell builtin or an external > > program, it behaves in a more predictable manner than echo > > does. The fact that you have to specify any control characters > > with printf means that you don't have to worry about the > > portability problems with echo. > > More consistent across implementations, sure. I still wouldn't use > printf(1) to find out how the builtin printf behaves. I don't understand this, since I never suggested doing that. What I said was it's more predictable than echo. As always, you have to try it, or read the relevant man page for whatever platform(s) you want it to work on. However, you'll have less trouble doing that with printf than you will with echo. Joe