Password prompts for remote system echoing and not attaching

Earnie Boyd
Wed Aug 29 21:11:00 GMT 2012

On Wed, Aug 29, 2012 at 3:38 PM, Larry Hall (Cygwin) wrote:
> On 8/29/2012 2:48 PM, Earnie Boyd wrote:
>> On Wed, Aug 29, 2012 at 2:37 PM, Andy Koppe wrote:
>>> On 29 August 2012 19:02, Larry Hall (Cygwin) wrote:
>>>> On 8/29/2012 12:58 PM, Mike Casile wrote:
>>>>> New install of latest cygwin (CYGWIN_NT-6.1-WOW64 1.7.16(0.262/5/3)
>>>>> 2012-07-20
>>>>> 22:55) on a new Windows 7 system. When I do ftp <host>  it prompts for
>>>>> uid, then
>>>>> prompts for pw (normal).  Problem is, password echoes on the screen ...
>>>>> and then
>>>>> it hangs and connection is never made.  If I do ftp -s:<script> <host>
>>>>> ...
>>>>> and
>>>>> the script starts with uid/pw ... it all runs fine. Same with pscp.
>>>>> With
>>>>> putty,
>>>>> no problem because putty gets control and prompts for uid/pw itself.  I
>>>>> am
>>>>> thinking this is a config fat-finger on my part ... but I am out of my
>>>>> depth.
>>>> You have two alternatives here:
>>>>    1. Install the inetutils package so you're using the Cygwin FTP
>>>> client
>>>>       (or pick an alternative Cygwin package offering your favorite FTP
>>>>        client).
>>>>    2. Continue to use the Windows FTP client but only do so from a shell
>>>>       prompt started from cmd.exe (i.e. no Mintty, xterm, etc).
>>> Again: cmd.exe and console windows are different things. Invoking
>>> bash.exe (or tcsh.exe, or zsh.exe, or ...) directly from an Explorer
>>> shortcut or the Run dialog or whatever will work just fine, with
>>> Windows automatically creating a console window for it. No cmd.exe
>>> needed there.
>> Right, the issue is the PTY emulation issue that no one can do
>> anything about.  The Cygwin dependent terminal programs like mintty
>> and rxvt cause the issue because of the buffering used in the pipes
>> opened to native program.  The native programs do not flush properly
>> the I/O and thus you get garbage.  So therefore a native terminal
>> (a.k.a. console window) works because the buffering doesn't occur.
> Yeah, though buffering isn't the problem here.

Incorrect, the buffering is the problem

> It's that the password
> is rendered in the clear as you type it by the Windows FTP client if
> you run it from a Cygwin terminal.

The password types in the clear because the Cygwin terminal did not
receive the control characters necessary to not echo the characters
because the sequences for it are stuck in the buffer.

> This is why I suggested *not*
> running it from a Cygwin terminal if Mike really wants the Windows
> FTP client.

Correct you cannot execute the Windows ftp client in a Cygwin
terminal.  The point Andy was making is that the Windows ftp client
works well within a Cygwin shell in a native Windows terminal.

> Whether the Windows FTP client is run in a console or
> cmd.exe is really, in this case, inconsequential.

And here is a confusion.  A console (a.k.a terminal) is that which
displays characters received in some font.  Cmd.exe is the windows
shell that is executed within the terminal (a.k.a. console).  You can
loosely compare cmd.exe to bash.exe, etc.

> Both will work
> for the work-flow Mike describes.  The key take-away from the original
> post is that the Windows FTP client is being used, not the Cygwin one.

Yes, but so what, Mike can use a Cygwin shell for it but not a Cygwin terminal.

> That's why I mentioned using the Cygwin one as another alternative to
> avoid the observed behavior of the Windows FTP client with Cygwin
> terminals.

Yes, if you prefer to use the Cygwin terminal you must use a Cygwin
client.  But you have a choice to use the native terminal with a
Cygwin shell and native ftp client.  You could also do the following
if you prefer the Cygwin terminal but do not want the Cygwin ftp

cmd /c start ftp

Which will open a native terminal with the ftp client waiting for input.


Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list