Re: tramp methods using synchronous processes?

[Kai Großjohann]

Hm.  The Gmane article you mention sounds as if the problem was
buffering.  Normally, if you write stuff to a file descriptor, the
underlying subsystem may buffer the stuff, in order to be able to write
bigger chunks at a time.  (If you write to a file, it is more efficient
to write complete blocks instead of appending to the same block often.)

Standard input/output are often line buffered, so that stuff is sent
after each newline (instead of waiting for a full block).  This is
especially the case when they go to the tty.

It seems that your W32 shells don't think they are printing to a tty,
and so they see no need to turn on line buffering.

Also see the variable process-connection-type.

However, this is just a wild stab in the dark.  One method to test it
would be to issue many commands to your lua interpreter, until the
buffer is full.  Then it might get sent to the interpreter all at once,
so that it produces a lot of output.

Regarding extending Tramp with a new transfer method, you may wish to
take a look at the SMB code in Tramp.  That has been coded as a transfer
method, as well.  It could even be somewhat similar to what you are
doing, since IIRC it invokes smbclient and then sends commands to it. 
smbclient is also different from a "regular" Unix shell, which is what
another Tramp transfer method expects.

I'm sure that Michael can shed more light on this.

Kai

Eduardo Ochs wrote:
> Hello tramp list,
>
> How do I add a method to tramp that doesn't run an asynchronous
> process?
>
> Ok, let me explain (sorry for the length)...
>
> I'm having to use a crippled w32 environment at a job, and tramp's
> default telnet and ftp methods don't work there due to a bug that I'm
> trying to track down - I have asked for help at the #emacs IRC
> channel, and reported it (actually something that I think that is
> related to it!) at:
>
>   http://article.gmane.org/gmane.emacs.pretest.bugs/10583
>
> but got no answers...
>
> I'm currently using a workaround - that I will describe soon - and I
> thought that adding support for it to tramp as a new method would be a
> good way to become more familiar with tramp's innards... Can you give
> me some pointers and hints to start with?
>
> Here's the workaround. As the default ftp client at this win2k box is
> broken I wrote a Lua script called myftp.lua that uses the support for
> ftp that comes with the "luasocket" library; myftp.lua knows how to
> expand some file names - "machine1:foo" becomes
> "ftp://myuser:address@hidden/foo";, for example -, and
> when myftp.lua is invoked with two arguments it works as a cp that can
> handle both local and remote files - like this -
>
>   lua.exe myftp.lua foo/bar machine1:/home/foo/bar
>   lua.exe myftp.lua machine1:/home/foo/bar foo/bar
>   lua.exe myftp.lua machine1:/home/foo/bar machine2:/tmp/bletch
>
> and when invoked with a single argument it works - now for remote
> files only - either as an "ls -F" or as a "cat" , according to whether
> the filename looks like a directory or as a file.
>
>   lua.exe myftp.lua machine1:/home/foo/
>   lua.exe myftp.lua machine1:/home/bar
>
> I have written a handful of elisp functions for accessing remote files
> using that script, but my functions are infinitely more primitive than
> using tramp or ange-ftp - they create buffers with names like
> "machine1:/home/foo/" or "machine1:/home/bar", in which (yuck!!!)
> buffer-file-name is nil...
>
> Hints? Pointers? Examples?...
> Thanks in advance,
>
>     Eduardo Ochs
>     (format "address@hidden" "eduardoochs" "gmail" "com")
>     http://angg.twu.net/
>
>
>
> P.S.: myftp.lua and its elisp support functions are not at
> <http://angg.twu.net/> yet, but that's just because my home machine is
> broken and at work I'm behind a firewall that blocks ssh connection to
> the outside world... If anyone is interested I can send them by e-mail
> - but I think that they still need some cleaning...
>
>
> _______________________________________________
> Tramp-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/tramp-devel
>
>
>
>