This is the mail archive of the
mailing list for the Cygwin project.
rxvt and getpass()
- To: cygwin-apps at sourceware dot cygnus dot com
- Subject: rxvt and getpass()
- From: Steve O <simgenome at yahoo dot com>
- Date: Sat, 10 Mar 2001 20:24:51 -0800 (PST)
- Reply-To: bub at io dot com
Hi and thanks for letting me post to cygwin-apps,
At some point I'd like to see if I could include the
No-X rxvt port into the cygwin distro. Before that
happens, though, I'd like to fix a bug that's been
challenging me for some time.
The tip of the iceberg is that getpass() opens /dev/tty
in order to print the password prompt and to get the
user's response. Opening /dev/tty is equivalent to
getting the handles of the win32 console associated with
the process (as far as I can tell). When using rxvt,
the console is hidden, and so there's no way for the
user to respond to, or even see, the password prompt.
The first order solution is to edit out the code in getpass
that opens /dev/tty, but that's probably not the right
thing to do. Instead, it seems that I should be doing
some extra step to let cygwin know that /dev/tty should
refer to my tty/pty pair. Is there a way I can make the
open("/dev/tty") fail, perhaps with a chmod? Or dup the
fds of my tty into the console handles? I can experiment
with different hacks, but I guess I'm hoping that there's
some obvious approach that I'm unaware of.
Ok, maybe the solution is for rxvt not to have a console
at all. I really like this solution, but in the past
this has led to spurious consoles being created as
processes fork. Is this a feature of windows that
no (non-gui) process shall be without console? Or are
there some assumptions buried in cygwin that there will
always be a console? Or am I just behind the times?
Any help is appreciated.
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.