Re: Multi from Windows Box

[Daniel Stolz]

Kai Großjohann wrote:
> Daniel Stolz <address@hidden> writes:
> > >     
> >   
> > > Do you think that tramp-open-connection-multi should use a different
> > > variable,
> > >     
> > No.  I think a great solution would be if command.com works as
> > tramp-sh-program.  Then everything else is seamless.
> >   
This won't work as I see below.
> >   
>
> Please note that Tramp assumes to be talking to a Bourne-ish¹ shell.
> All commands that Tramp contains are tailored for that shell.  It
> doesn't make sense to change this to command.com syntax, as
> command.com is unlikely to be present on the remote system...
I didn't meant to suggest that.  I meant more the other way around (i.e.
change command.com to talk Bourne)
> But _in that function_, only very specific commands are sent to the
> shell.  Therefore, it _might_ work to use command.com in that
> function.  (But not in the other places.)
I misunderstood this.  I thought you meant tramp-sh-program was only used
tramp-wide in a couple of places.
> Well, it might work to use command.com in
> tramp-open-connection-multi, but it might fail to use command.com in
> the other places where tramp-sh-program is used.
Again. I misunderstood.
> That's why I suggested another variable.  Of course, I would document
> things properly.
I didn't mean to imply you would not.  I was thinking the fix would be non-multi-specific
(i.e. global change to tramp-sh-program) so it should be documented that
way, i.e. all Windows users, whether or not they use multi, should change
tramp-sh-program.
>   I could even have the new variable default to
> command.com on Windows systems.
>From my perspective, this seems to be the correct solution

>>¹ Is that the right way to (funnily) say Bourne-like?
Yes.  I got it wrong.


Rethinking a bit, something will probably have to be done with tramp-sh-program.
 Or else it should be noted that some features of Tramp (those that use tramp-sh-program)
are unavailable to Windows users.