stty echo in ash

Rob Landley rob at landley.net
Tue Aug 1 00:39:52 UTC 2006


On Monday 31 July 2006 7:19 pm, David Byron wrote:
> On Monday 31 July 2006 11:49 am, Rob Landley wrote: 
> 
> > Well, to use netcat's new -f option as a minicom replacement, I go:
> > 
> > stty 115200 -F /dev/ttyS0
> > stty raw -echo -ctlecho && nc -f /dev/ttyS0
> > 
> > Does that help?
> 
> No, but I bet it's doing something different for me than it does for you.
> Or maybe that we're talking about two different things.  I still use minicom
> to connect from my linux desktop to my target running busybox so I don't
> understand the part about replacing minicom.  The version of nc I've got on
> my desktop doesn't support -f.

Current svn supports -f.  The stty commands are what's needed to put the tty 
into such a state that a program that copies stdin and stdout to a char 
device doesn't get spurious echoes or wait for a newline before sending text, 
and passes along ctrl-c...

> I grabbed the head of the source tree, configured and built it.
> 
> On my target, when I execute
> 
> ~ # stty raw -echo -ctlecho && nc -f /dev/ttyS0
> 
> what I type is still echoed to the screen, but when I hit enter I get a
> carriage return, no newline and no output, as though what I type isn't being
> treated as a command.  When I hit ctrl-c, I see a dot (.).  The way I got
> the shell back was to telnet in and kill it.

What are you talking to at the far end?

Yeah, you have to kill it from another console.  Netcat doesn't parse escape 
sequences.

> Feels like I'm missing something obvious.

Sounds like your shell is undoing what stty does.  Which shell are you using?

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list