Re: FiSH Connection fails : mc freezing

[Pavel Roskin <proski gnu org>]

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