GNU bug report logs -
#3957
split window for remote commands through eshell
Previous Next
Reported by: Colin Williams <lackita <at> gmail.com>
Date: Tue, 28 Jul 2009 19:10:05 UTC
Severity: normal
Done: Michael Albinus <michael.albinus <at> gmx.de>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
Hi Colin,
>> Basically, any time a remote command gets executed through eshell, if
>> the frame is a single window it gets split into two windows.
>> Essentially, this is because tramp does its magic through
>> shell-command, which pops up a window if the output is too large to
>> fit in the minibuffer.
>
> I think the problem is not really in Tramp since Tramp just implements
> shell-command according to its docstring; C-h v shell-command RET:
>
> [...]
> Execute string command in inferior shell; display output, if any.
>
> I.e. the problem is that Eshell shouldn't use shell-command but
> something else.
> [ And probably shell-command should not be a file operation
> (i.e. shouldn't go through find-file-name-handler), instead it should
> use process-file or start-file-process. ]
>
>> I'm currently trying to figure out how to prevent the root split, so
>> things like new frames are blocked as well.
>
> I think the right fix might be to make eshell-external-command (and
> eshell-remote-command) use process-file or start-file-process.
Since Emacs 24.3, eshell-remote-command is not used
anymore. eshell-external-command calls start-file-process. This should
have fixed the issue, could you, please, check? Something like this:
~ $ cd /sudo::
/sudo:root <at> uw001237:/root $ ls -al /
total 155
drwxr-xr-x 22 root root 4096 2013-12-05 2013 .
drwxr-xr-x 22 root root 4096 2013-12-05 2013 ..
drwxr-xr-x 2 root root 4096 2013-10-29 2013 bin
drwxr-xr-x 4 root root 2048 2013-12-05 2013 boot
drwxr-xr-x 16 root root 4360 2014-01-20 12:04 dev
drwxr-xr-x 176 root root 12288 2014-01-14 15:45 etc
drwxr-xr-x 6 root root 4096 2013-01-16 2013 home
lrwxrwxrwx 1 root root 37 2013-12-05 2013 initrd.img -> /boot/initrd.img-3.2.0-58-generic-pae
lrwxrwxrwx 1 root root 37 2013-11-15 2013 initrd.img.old -> /boot/initrd.img-3.2.0-57-generic-pae
drwxr-xr-x 24 root root 4096 2014-01-06 13:16 lib
drwx------ 2 root root 16384 2012-07-23 2012 lost+found
drwxr-xr-x 2 root root 4096 2014-01-14 11:35 media
drwxr-xr-x 2 root root 4096 2012-04-19 2012 mnt
drwxr-xr-x 3 root root 4096 2012-07-23 2012 opt
dr-xr-xr-x 227 root root 0 2014-01-10 10:35 proc
drwx------ 10 root root 4096 2013-11-11 2013 root
drwxr-xr-x 28 root root 1040 2014-01-14 07:14 run
drwxr-xr-x 2 root root 12288 2013-10-29 2013 sbin
drwxr-xr-x 2 root root 4096 2012-03-05 2012 selinux
drwxr-xr-x 2 root root 4096 2012-07-23 2012 srv
drwxr-xr-x 13 root root 0 2014-01-10 10:35 sys
drwxrwxrwt 19 root root 57344 2014-01-20 14:13 tmp
drwxr-xr-x 10 root root 4096 2012-07-23 2012 usr
drwxr-xr-x 14 root root 4096 2014-01-10 10:34 var
lrwxrwxrwx 1 root root 33 2013-12-05 2013 vmlinuz -> boot/vmlinuz-3.2.0-58-generic-pae
lrwxrwxrwx 1 root root 33 2013-11-15 2013 vmlinuz.old -> boot/vmlinuz-3.2.0-57-generic-pae
> Tho for async commands (that end in &), shell-command's behavior to open
> a separate window/buffer for the command's output probably makes a lot
> of sense. So maybe this bug-report is only for remote commands that
> don't end in &.
There is no special handling for asynchronous remote processes in
eshell, they behave like local asynchronous processes. If we want to
treat asynchronous processes differently than the current behaviour, we
might check eshell-do-eval. However, I don't see a need for it. That
would require another bug report.
> Stefan
Best regards, Michael.
This bug report was last modified 11 years and 117 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.