tramp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sshx protocol from MS Windows occasionally cuts off results in M-x r


From: Michael Albinus
Subject: Re: sshx protocol from MS Windows occasionally cuts off results in M-x rgrep
Date: Wed, 05 May 2021 18:35:37 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Jim Porter <jporterbugs@gmail.com> writes:

Hi Jim,

> Is it possible that there's an issue with how Tramp runs the process?
> In the debug log for Tramp, I see the following commands (shortened
> for readability):
>
>   ssh    -e none -t -t server /bin/sh  && exit || exit
>
>   cd /home/jim/src/tramp/info/ &&  exec <<'[heredoc]'  env [...] /bin/sh
>   (
>   find . [...] -exec grep --color=always \
>   -i -nH --null -e info \{\} +
>   ) </dev/tty
>   [heredoc]
>
> If I run these manually in cmd.exe, the command prompt closes
> immediately. If I'm understanding things correctly, I think that's
> because of the `exit' in the first command and the `exec' in the
> second. If I open a subshell (by running cmd.exe in an existing
> command prompt), the window stays open and I can see the output. I've
> tried a bunch of times, but I'm completely unable to reproduce the
> issue when running in cmd.exe. That suggests to me that the MS Windows
> ssh client is working ok, or at least that any bugs here can be
> avoided if we're careful.

I've tried all these tests (manual invocation of ssh etc pp) already
yesterday, with the same result as you. It works.

Interestingly, there's no such problem when using plink, which uses the
same command sequence. That lets me think it is an ssh client problem,
buffering the output or whatever. But I might be wrong.

> However, I seem to have fixed it locally by enabling
> `direct-async-process'. With that set to t, I always see the correct
> number of results from rgrep. This works well enough that this bug
> won't bother me anymore, but it would be nice to know what's going on.
> Perhaps the differences between direct and indirect async processes
> will help to isolate the bug?

Direct async processes use another logic. Usually, an async process has
the command sequence

--8<---------------cut here---------------start------------->8---
# Call a local shell
C:/Program 
Files/Emacs/emacs-28.0.50-snapshot/libexec/emacs/28.0.50/x86_64-w64-mingw32/cmdproxy.exe

# Call the ssh client.
ssh -q -e none -t -t -o RemoteCommand="/bin/sh  -i" server && exit || exit

# Call a POSIX shell on remote.
exec env TERM='dumb' INSIDE_EMACS='28.0.50,compile,tramp:2.5.1-pre' ENV='' 
HISTFILE=~/.tramp_history PROMPT_COMMAND='' PS1=\#\$\  PS2='' PS3='' /bin/sh  -i

# Call some commands for setup of the remote shell, handle passwords.
[...]

# Call the remote command
cd /home/albinus/src/tramp/info/ &&  exec <<'ea8122f4bf7a71f82c52e3a2ca344578'  
env PS1\=/sshx\:gandalf\:/net/ford/albinus/src/tramp/info/\ \#\$\  
GREP_COLORS\=mt\=01\;31\:fn\=\:ln\=\:bn\=\:se\=\:sl\=\:cx\=\:ne 
GREP_COLOR\=01\;31 INSIDE_EMACS\=28.0.50\,compile\,tramp\:2.5.1-pre 
TERM\=emacs-grep /bin/sh
(
find . -type d ...
) </dev/tty
ea8122f4bf7a71f82c52e3a2ca344578
--8<---------------cut here---------------end--------------->8---

A direct async process has just one call

--8<---------------cut here---------------start------------->8---
ssh -q -e none server cd /home/albinus/src/tramp/info/ && ( env 
TERM\=emacs-grep INSIDE_EMACS\=28.0.50\,compile\,tramp\:2.5.1-pre 
GREP_COLOR\=01\;31 
GREP_COLORS\=mt\=01\;31\:fn\=\:ln\=\:bn\=\:se\=\:sl\=\:cx\=\:ne TMPDIR\=\$HOME 
ENV\=\'\' TMOUT\=0 LC_CTYPE\=\'\' CDPATH\= HISTORY\= MAIL\= MAILCHECK\= 
MAILPATH\= PAGER\=cat autocorrect\= correct\= /bin/sh -c find\ .\ -type\ d\ 
\\\(\ -path\ \\\*/SCCS\ -o\ -path\ \\\*/RCS\ -o\ -path\ \\\*/CVS\ -o\ -path\ 
\\\*/MCVS\ -o\ -path\ \\\*/.src\ -o\ -path\ \\\*/.svn\ -o\ -path\ \\\*/.git\ 
-o\ -path\ \\\*/.hg\ -o\ -path\ \\\*/.bzr\ -o\ -path\ \\\*/_MTN\ -o\ -path\ 
\\\*/_darcs\ -o\ -path\ \\\*/\\\{arch\\\}\ \\\)\ -prune\ -o\ \\\!\ -type\ d\ 
\\\(\ -name\ .\\\#\\\*\ -o\ -name\ \\\*.o\ -o\ -name\ \\\*\\\~\ -o\ -name\ 
\\\*.bin\ -o\ -name\ \\\*.lbin\ -o\ -name\ \\\*.so\ -o\ -name\ \\\*.a\ -o\ 
-name\ \\\*.ln\ -o\ -name\ \\\*.blg\ -o\ -name\ \\\*.bbl\ -o\ -name\ \\\*.elc\ 
-o\ -name\ \\\*.lof\ -o\ -name\ \\\*.glo\ -o\ -name\ \\\*.idx\ -o\ -name\ 
\\\*.lot\ -o\ -name\ \\\*.fmt\ -o\ -name\ \\\*.tfm\ -o\ -name\ \\\*.class\ -o\ 
-name\ \\\*.fas\ -o\ -name\ \\\*.lib\ -o\ -name\ \\\*.mem\ -o\ -name\ 
\\\*.x86f\ -o\ -name\ \\\*.sparcf\ -o\ -name\ \\\*.dfsl\ -o\ -name\ \\\*.pfsl\ 
-o\ -name\ \\\*.d64fsl\ -o\ -name\ \\\*.p64fsl\ -o\ -name\ \\\*.lx64fsl\ -o\ 
-name\ \\\*.lx32fsl\ -o\ -name\ \\\*.dx64fsl\ -o\ -name\ \\\*.dx32fsl\ -o\ 
-name\ \\\*.fx64fsl\ -o\ -name\ \\\*.fx32fsl\ -o\ -name\ \\\*.sx64fsl\ -o\ 
-name\ \\\*.sx32fsl\ -o\ -name\ \\\*.wx64fsl\ -o\ -name\ \\\*.wx32fsl\ -o\ 
-name\ \\\*.fasl\ -o\ -name\ \\\*.ufsl\ -o\ -name\ \\\*.fsl\ -o\ -name\ 
\\\*.dxl\ -o\ -name\ \\\*.lo\ -o\ -name\ \\\*.la\ -o\ -name\ \\\*.gmo\ -o\ 
-name\ \\\*.mo\ -o\ -name\ \\\*.toc\ -o\ -name\ \\\*.aux\ -o\ -name\ \\\*.cp\ 
-o\ -name\ \\\*.fn\ -o\ -name\ \\\*.ky\ -o\ -name\ \\\*.pg\ -o\ -name\ \\\*.tp\ 
-o\ -name\ \\\*.vr\ -o\ -name\ \\\*.cps\ -o\ -name\ \\\*.fns\ -o\ -name\ 
\\\*.kys\ -o\ -name\ \\\*.pgs\ -o\ -name\ \\\*.tps\ -o\ -name\ \\\*.vrs\ -o\ 
-name\ \\\*.pyc\ -o\ -name\ \\\*.pyo\ \\\)\ -prune\ -o\ \ -type\ f\ \\\(\ 
-name\ \\\*\ -o\ -name\ .\\\[\\\!.\\\]\\\*\ -o\ -name\ ..\\\?\\\*\ \\\)\ -exec\ 
grep\ --color\=auto\ -i\ -nH\ --null\ -e\ info\ \\\{\\\}\ \+ )
--8<---------------cut here---------------end--------------->8---

> - Jim

Best regards, Michael.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]