Hi, Hans! > On the other hand, I think it would not be necessary to make SSH accept all > input on it`s stdin, would it ? The passphrase should be sufficient.
I don't understand. SSH already accepts all input of the remote program on stdin. Only password, passphrase and confirmations (e.g. for unknown host key) are asked on /dev/tty. > I tried to examine the code of OpenSSH 2.3.0p1 and to insert an -I > switch, but it seems to be quite complicated to me. > > BTW, who did "invent" this switch ? Google left me completely clueless. I think it was Pavel Machek. But the problem with such patches is that they have a very limited audience. Very small percentage of MC users will recompile ssh just to get FiSH to work with passwords. And most importantly, it is not needed. It is possible to redirect child's /dev/tty from a C program by using pseudoterminals, although I don't know how to do it in the shell. > As one of the arguments a variable "from_stdin" is passed, but I did whether > figure out where this variable is set nor where it is defined, it seems to be > always 0. Let's concentrate on "how do we do it right", not on "how do we hack ssh". > > It is possible to control /dev/tty of ssh if it's run in a pseudoterminal, > > similar to how MC runs the subshell. Still it will require that mc > > I did not get SSH to allocate a pseudoterminal, it refuses if it is not the > controlling tty. I think we are talking about different things. I meant that MC should create the pseudoterminal, not SSH. If it were impossible, then I would not be able to run ssh from MC with subshell support. MC controls all input of ssh in this case. > I tried even to surpress SSH`s output of the password request, no success. > After having compiled it for about some 20 times, I gave up (for now...). I agree that using /dev/tty is not very user-friendly. But it makes it possible to distinguish between 5 channels of communication (3 channels for the remote program and 2 local channels). Maybe ssh could use file descriptors above stderr (i.e. 3) for local communication if they are open on startup, but it's a theme for an ssh mailing list. > However, I`m not sure if this could resolve the problem, as the password has > to be fed to SSH in the right moment anyway. My only question was whether MC should stand in the middle or let the user to communicate with ssh directly. > > Another solution would be to hide the panels and run ssh on the same tty > > as MC. The panels would be restored when the remote fish server answers. > > This would not be pretty, but it would completely eliminate the need to > > redirect /dev/tty and capture/feed anything. > > How would this work ? I found no possibility to hide the panels temporarily ? > Hacking required ? The panels are hidden when you press Ctrl-O and when a program is run from the command line. Some code is already in place, but hacking is definitely required. Let's just limit it to MC. -- Regards, Pavel Roskin _______________________________________________ Mc mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc
