[mosh-devel] [PATCH, 2nd attempt] do not treat remote command options as mosh options

Keith Winstein keithw at MIT.EDU
Fri May 25 13:26:48 EDT 2012


This looks fine, thanks for submitting.

As we discussed on IRC, I don't want to make changes to the Perl
script without making the same change to the C++ version (in pending
pull request, https://github.com/keithw/mosh/pull/96) because (a) we
are moving to the C++ version soon and (b) I don't want to annoy the
people who have been working hard on that.

But perhaps either you can port this to the C++ version (I have not
given that a close read yet) or I will try to match this behavior when
integrating the C++ code.

Thanks again,
Keith

On Sun, May 20, 2012 at 10:18 AM, Michael Tokarev <mjt at tls.msk.ru> wrote:
> Currently, mosh treats any arguments that starts with a minus
> sign as its options (up to lone "--" which terminates option
> processing explicitly), so, for example, the following is not
> accepted:
>
>  mosh remotehost uname -r
>
> (mosh treats -r as its option and complains).  But this is very
> natural way of specifying remote commands with options -- all
> other utilities that spawns other commands -- eg, ssh, strace,
> valgrind, chroot, etc -- all stops their option processing once
> the command to run is encountered, leaving the rest of the line
> to that command.
>
> Do the same in mosh.  In there, we swallow up to two first
> non-option args in @argv, and on eating second we reset @ARGV
> so that GetOptions() finishes.  After that, we combine our
> up to 2 first args in @argv with the rest of @ARGV, if any.
>
> This allwos to specify options after the "mosh" command itself,
> or after the hostname to connect to, but everything which is
> specified after the remote command to run is not interpreted
> by GetOptions() anymore and passed as-is to the remote side.
>
> This may actually break some unusual workarounds of the original
> misdesign: construct like
>
>  mosh remotehost uname -- -r
>
> will not work as it works now, because the "--" terminator is
> misplaced.  But it is not how mosh command is documented anyway.
>
> Signed-off-by: Michael Tokarev <mjt at tls.msk.ru>
> ---
>  scripts/mosh |   19 ++++++++++++++++++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/mosh b/scripts/mosh
> index 829c399..ed7e64c 100755
> --- a/scripts/mosh
> +++ b/scripts/mosh
> @@ -80,6 +80,20 @@ sub predict_check {
>   }
>  }
>
> +# options processing.  We recognize our options right after "mosh" command,
> +# or after the hostname to connect to (first non-optional argument), but not
> +# after the remote command.  Hence we may eat up to 2 non-options in
> +# &handle_nonopt(), and skip the rest.
> +my @argv;
> +sub handle_nonopt() {
> +  print "nonopt: @_\n";
> +  push @argv, @_;
> +  if (scalar @argv == 2) {
> +    push @argv, @ARGV;
> +    @ARGV = ();
> +  }
> +}
> +Getopt::Long::Configure('permute');
>  GetOptions( 'client=s' => \$client,
>            'server=s' => \$server,
>            'predict=s' => \$predict,
> @@ -90,7 +104,10 @@ GetOptions( 'client=s' => \$client,
>            'ssh=s' => \$ssh,
>            'help' => \$help,
>            'version' => \$version,
> -           'fake-proxy!' => \my $fake_proxy ) or die $usage;
> +           'fake-proxy!' => \my $fake_proxy,
> +           '<>' => \&handle_nonopt ) or die $usage;
> +# in case some args remains in @ARGV, join them with @argv.
> + at ARGV = ( @argv, @ARGV );
>
>  die $usage if ( defined $help );
>  die $version_message if ( defined $version );
> --
> 1.7.10
>
> _______________________________________________
> mosh-devel mailing list
> mosh-devel at mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel




More information about the mosh-devel mailing list