Dennis Newbold writes:

# The reason I want to do this somewhat unusual thing is:  I'm doing a
# Ruby program to automate zipping up certain files on my hard drive,
# and saving them on a remote system via ftp.  It all works fine except
# that, for security reasons, I don't want to hard code the password for
# the ftp login into the script.  So, I had it emit a prompt to the user
# (me), and then do a gets to read in the password.  This also works
# fine, except that the password I type in is echoed to the screen.
# Since I work in an open office with two other guys, this is not really
# an ideal situation.  If I were using the Unix or Linux version of
# Ruby, I could do an ioctl against stdin to set its properties to
# include "noecho".  Don't recall the details, but a few minutes reading
# through a few man pages should clear it up.  Unfortunately, I'm on
# Windows NT, so that probably is not an option.  Any suggestions /
# comments would be appreciated.  Thanks.

Well, since the RubyCentral InstallShield distribution of Ruby (or 
whatever the proper designation is) comes with Ruby/Tk, you could consult 
the Perl/Tk manual for how to pop up a password entry dialog, and then use 
the (Perl/Tk -->) Ruby/Tk chapter in Programming Ruby to do the 
translation. 

I'd look it up for you and try it out, except that I've got other work 
that I have to finish up before I leave, hopefully real soon now. (I don't 
recall if one of the Ruby/Tk widget demos on RAA already has something 
like this. You might want to take a look.) Hopefully someone else can take 
it from here, unless someone has a better idea. 

You could also try to make use of dynamic passwords, where you have a 
simple minded transposition and substitution function based on the current 
24 hour time and day of the month, so that you (almost) never use the same 
password twice in a row. (The function should be used as a compiled 
command so that the source is not sitting around, and allow for a minute 
of slop.) There are lots of other sorts of analogous tricks, such as 
randomly generated challenges that require different responses, for 
thwarting casual observation by password-seeking imposters. 

Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)