[DGD] MODE_NOECHO newline

[bart at wotf.org]

What Gurbalib does is a MODE_NOECHO (actually, it does a send_message(0) which
does the same thing) directly after it asks for the password for the first
time. From that point on, it prepends a \n in front of each line, until the
password is accepted, after which it does a MODE_ECHO (actually, a
send_message(1) which does the same thing).

Look at /sys/obj/user.c, at the functions input_name(), input_old_password()
and login_user().

The same approach should be possible with other libs.

Bart.

On Sat, 30 Jul 2016 17:45:17 -0500, Blain wrote
> MODE_ECHO and MODE_NOECHO.
> 
> The latter achieved the intended result of hiding the player's input 
> while imputting a password.
> 
> However, the printed text, such as a paragraph explaining how the password
> should be devised, is being severely indented when it is printed 
> while the mode is MODE_NOECHO.
> 
> I had fixed it briefly by replacing \n with \r\n, but I think that failed
> to fix it later on after I'd made some other changes while troubleshooting.
> 
> My question is:  What differences are there between the two modes 
> that any sane lib should make adjustment for as a rule? On Jul 30, 
> 2016 5:08 PM, "Raymond Jennings" <shentino at gmail.com> wrote:
> 
> > You should be aware that telnet mode in DGD does some automatic processing
> > of output, and that includes line endings.
> >
> > I got burned by this once when I tried to use telnet mode to handle HTTP
> > connections.
> >
> > My advice:  Use binary connections for everything.
> >
> > Now I am curious what you mean about noecho.  Do you mean the telnet option
> > WILL/WONT ECHO?
> >
> > As far as I know, how it works is as follows:
> >
> > Normally, the connection is labelled by DGD as "echo".
> >
> > In the telnet layer, this equates, ironically, to NO ECHO, which means the
> > server is telling the client that it won't do any echoing, which in turn
> > tells the client to do that itself.
> >
> > When DGD sets the connection to "noecho", the server actually sends WILL
> > ECHO and dishonestly tells the client that it will do echoing, but then
> > doesn't actually echo, so the client sends keystrokes without echoing them
> > locally, and they never get echoed by the server either, ergo things like
> > passwords and whatnot never show up on the client's terminal because
> > neither side echoed them.
> >
> > Since a "noecho" connection has the server dishonestly telling the client
> > that it doesn't need to echo locally, this also includes the final newline
> > the client sends when the user hits the Enter key after typing the
> > password.
> >
> > What you have to do is echo the newline manually server-side.
> >
> > The example of the password first has the server send a password prompt:
> >
> > Password:
> >
> > And then the cursor sits after the colon while the user types the password
> > and hits enter.  However, since local echoing has been turned off by server
> > request, it never jumps to the next line unless the server spits out a
> > newline of its own.
> >
> > I hope this explains everything, I was mostly rambling for the sake of the
> > list in general.
> >
> > On Sat, Jul 30, 2016 at 1:49 PM, Blain <blain20 at gmail.com> wrote:
> >
> > > When I switch to noecho mode, the lines following a newline are severely
> > > indented.  To fix it, I have to replace \n with \r\n before sending it to
> > > the user.  This doesn't happen in echo mode.  Any ideas on where to start
> > > looking?  Kernel code and my code seem fine so far.
> > > ____________________________________________
> > > https://mail.dworkin.nl/mailman/listinfo/dgd
> > ____________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/