[mosh-devel] stripping locale support from mosh

[Keith Winstein]

Edward,

Please feel free to post any issues here of course. I do wonder if
Mosh is really appropriate for your needs -- as it stands, Mosh really
just provides a remote virtual terminal. We don't do remote execution
of commands and we don't convey a byte stream.

You might try remctl instead
(http://www.eyrie.org/~eagle/software/remctl/), although I think it
does still rely on TCP. I'm not sure if your problem is flaky network
or flaky Cygwin, though, and you might think about giving up the
latter if you can.

Good luck,
Keith

On Fri, Oct 5, 2012 at 8:40 PM, Edward Peschko <horos11 at gmail.com> wrote:
> Keith,
>
> Thanks for this - if you don't mind, I'll continue to post if/when I
> find issues.
>
> When I finally get things working, I think that it just may be worth
> it to package all of the changes up into a configure flavor of mosh
> that is specifically geared towards automation - having a robust tool
> to handle automation on as many devices as possible would be a very
> worthwhile thing to have.
>
> That being said, the one thing that I see needing would be to be able
> to run mosh in 'byte serialization' mode, ie: where all the output is
> captured, buffered, and sent over the socket udp fashion - time delay
> on lossy networks isn't a big deal here, what's important is the
> ability to capture the output and parse it automatically by the
> client.
>
> So, is it possible to just as easily disable SSP and just send all output?
>
> Failing that, is there a really rock-solid tcp-to-udp forwarding
> protocol out there? Ideally, I'd have the ssh server forward its
> traffic to a udp server, and then relay that traffic back to a udp
> client that would then forward it to a ssh client, and all trickiness
> with the TCP protocol would be handled by a large buffer server side,
> and network choppiness handled by a very forgiving UDP transfer
> policy. I've tried duat and tcpoverudp, but they don't really impress
> me that much, with ssh connections closing after 2 mins or so of wall
> clock time.
>
> Anyways, any ideas on this would be very much appreciated.
>
> Thanks much,
>
> Ed
>
> On Fri, Oct 5, 2012 at 1:25 AM, Keith Winstein <keithw at mit.edu> wrote:
>> Hi Ed,
>>
>> You can force mosh to start up outside a UTF-8 charset by editing the
>> is_utf8_locale() function (in src/util/locale_utils.cc) to always
>> return true. (Patch attached.)
>>
>> As you can appreciate, it's a lot easier to maintain a terminal
>> emulator for _one_ charset than to try to make it agile and support
>> more than one. (UTF-8 vt220s are not backwards-compatible with 8-bit
>> vt220s, unfortunately, and screen historically has had loads of bugs
>> trying to convert between the two.) I don't think we're really eager
>> to support Mosh in more configurations because it gets complicated
>> quickly.
>>
>> But you're welcome to turn off our paranoid checks if you need to in
>> your configuration. Hope this helps.
>>
>> Best regards,
>> Keith
>>
>> On Fri, Oct 5, 2012 at 4:09 AM, Edward Peschko <horos11 at gmail.com> wrote:
>>> All,
>>>
>>> Again, this is in pursuit of better, more bullet proof connections in
>>> automation. Could mosh perhaps be able to disable locale support, or
>>> make it optional?
>>>
>>> For several applications of mosh (including mine) unfortunately this
>>> is critical - the 'devices' we produce, for example are stripped down
>>> versions of centos and hence DON'T have any locale info installed (in
>>> fact there isn't even the locale binary) and hence the locale
>>> requirement makes using mosh infeasible..
>>>
>>> Having an option to compile mosh with plain-old ascii would be great
>>> here - elsewise I'm not sure how I could use mosh as I envision here.
>>>
>>> Thanks much, and workarounds again are appreciated..
>>>
>>> Ed
>>> _______________________________________________
>>> mosh-devel mailing list
>>> mosh-devel at mit.edu
>>> http://mailman.mit.edu/mailman/listinfo/mosh-devel