Skip to content


Cygwin build works in general, but Perl part does not #164

DmitryKoterov opened this Issue · 18 comments

7 participants


I have built cygwin version of mosh. It is not very hard: just install cygwin, all deps from sources and before running ./configure execute the following:

export CPPFLAGS="-I/usr/include/ncurses"
export PKG_CONFIG_PATH="/usr/local/lib/pkgconfig"
autoreconf -fi
make install

Now I run on the server:

# mosh-server
MOSH CONNECT 60001 qbE+SNhaEJpfzFpHcXBwkw

and on the client:

# MOSH_KEY=qbE+SNhaEJpfzFpHcXBwkw mosh-client <server-ip> 60001

And it really works! Even Midnight Commander works fine, with its cursor keys.

BUT I have bad news regarding the mosh perl script.

If I use "mosh" perl script (/usr/bin/mosh), it hangs with a black screen (it also hangs when I run it at the CentOS server, to I have tried to detect why this happens, and seems it hangs at "waitpid $pid, 0;" line - background SSH session which executes detached mosh-server is not terminated until mosh-server is really stopped (despite it is "detached"), so it is never stopped...

Note that the problem is represented not only at the cygwin build, but at CentOS build too.

If I remove "waitpid $pid, 0;" line, the process succeeds and I am dropped into the server's command line.

And another problem: if I run Midnight Commander, cursor keys do not work (they print characters), even if I execute mosh with --predict=never. This problem is also related to the perl script (not to the mosh-client itself), because if I run mosh-client directly, everything (including mc) works perfectly!

Mosh (mobile shell) member

Regarding the waitpid, I'm not sure if this is really a problem with the Perl script per se -- the root cause seems to be that your SSH client isn't exiting when the remote process ends.


I am using Linux for mosh-server, Cygwin for mosh-client.

Mosh hangs with a blue bar when connecting to the server: "mosh: connecting... (xxx s without contact.)" I've tried using both the mosh script, and separately using mosh-server and mosh-client with the same effect.

On the server, I can see the running process "mosh-server new -s -c 8", but this process exits after 60 seconds.

On the server, mosh can connect to itself (mosh localhost). Checked that my ports are open on both client and server (60000 to 61000 UDP).

What else am I missing?


Checked that my ports are open on both client and server (60000 to 61000 UDP).

Did you try an end-to-end UDP connectivity test with netcat or such?


I checked router settings manually, but confirmed using nc just now. Ports are open server-to-client and client-to-server.

I know that I'm not giving anybody much to go off of, so I'll try mosh-client on another system and report back


Ah, the blue-bar symptom was a port issue. My wireless repeater setup tricked me, but I fixed that.

Unfortunately, now my symptoms are:

  1. mosh SERVERNAME: Hangs with blank screen (no blue bar)
  2. mosh SERVERNAME with Line 223 commented out on both client and server: Blank screen (no blue bar)
  3. Separating mosh-server and mosh-client:
    • Server shows "Server now attached to client at CLIENTIP:55614"
    • Client shows "Aborted"
Mosh (mobile shell) member

lionelyyoung, interesting. Can you please confirm you are running the current master (033953d), which has some cygwin and other patches applied? What platform are you running the server and client on?

@keithw keithw added a commit that referenced this issue
@saurik saurik Reverse the direction of the IO::Pty used for ssh.
May address #114.
May address #164.
Mosh (mobile shell) member

Please test the current master -- we believe this may now be fixed.


I've rebuild from master, and now I have under cygwin:

d@PC-D ~
$ mosh d@server-name

d@PC-D ~
$ The authenticity of host 'server-name (<no hostip for proxy command>)' can't be established.
RSA key fingerprint is 2c:6e:64:1f:07:29:6a:11:81:98:23:3f:46:a3:ee:75.
Are you sure you want to continue connecting (yes/no)?

Seems mosh perl scripts finishes before its spawned ssh child process (so I am dropped into command-line). This happens when perl tries to execute <$pty_slave> command.


...I've also detected a strange code in mosh perl script:

exec {$client} ("$client @cmdline |", $ip, $port);

Here are possibly 2 problems:
1. Why "|" at the end of the string? Or it's a special (undocumented) argument for mosh-client which is used to separate ip and port from other arguments?
2. Why @cmdline is inserted directly to the string? What about its quoting?

Possibly should be written as:

exec {$client} $client, @cmdline, "|", $ip, $port;



That line was added by 679b819. We set mosh-client's argv[0] so that the original mosh command line (including hostname) will show up in ps.

The Perl syntax

exec { $x } ($y, $a, $b);

executes the command named by $x, with argv[0] set to $y, and "normal" arguments $a, $b. None of these strings get parsed by the shell. And mosh-client doesn't parse its argv[0] either, so that string "$client @cmdline |" is purely for display.


Caught it.

I've finally fixed mosh perl script and made it work for cygwin. No more PTYs, forks, no broken keys in Midnight Commander, less shell-quotings, less code, more comments etc.

See the first version here:

Mosh (mobile shell) member

Thanks Dmitry -- frustrating as others apparently have this working under cygwin. I appreciate your changes, but don't want to write to the filesystem as part of starting up mosh.


That's not a big problem - I could get rid of it. I'd like to create a C version of this script and totally get rid of Perl dependency. Would it be accepted by you when it will be ready?


Oh, I see, somebody has already done that: #96 (its patched and improved version:

Unfortunately the code still uses PTY and a lot of forks. I'll try to build it under cygwin, but seems allocating a PTY causes problems with key mapping under cygwin. PTY and most of forks could be easily avoided, code could be shorten a bit.


I've tested the C++ wrapper presented at under cygwin, it works perfectly. See comments for pull request #96 . I suppose the cygwin problem is fully solved now.

Keith, if you merge this: and apply comments recommendations from #96 about fgetln(), mosh will be fully-functional under cygwin too!


Dmitry, your version of script ( ) worked for me flawlessly. Thanks a lot!


I hope Keith will merge piannucci's pull request #96 in the future, so there will be no needs for any perl scripts and will be no cygwin problems anymore.


I just released mosh-1.2.4-1 asis on cygwin with the perl wrapper.
The cxxwrapper from #96 is fine, but not needed anymore.
All old problems could not be reproduced anymore as the failing IO::Tty is gone.
Ticket can be closed.

@andersk andersk closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.