unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* amd@gnu.org: eshell and external commands
@ 2007-08-05  3:05 Richard Stallman
  2007-08-08 22:55 ` Chong Yidong
  0 siblings, 1 reply; 10+ messages in thread
From: Richard Stallman @ 2007-08-05  3:05 UTC (permalink / raw)
  To: emacs-devel

Would someone please debug this, and ack?

From: "Alfred M. Szmidt" <ams@gnu.org>
To: emacs-devel@gnu.org
Message-Id: <20070709182148.E2DD8301EB@Psilocybe.Update.UU.SE>
Date: Mon,  9 Jul 2007 20:21:48 +0200 (CEST)
X-detected-kernel: Linux 2.6 (newer, 1)
Subject: eshell and external commands
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ams@gnu.org
List-Id: "Emacs development discussions." <emacs-devel.gnu.org>
List-Unsubscribe: <http://lists.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <http://lists.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=subscribe>
Sender: emacs-devel-bounces+rms=gnu.org@gnu.org
Errors-To: emacs-devel-bounces+rms=gnu.org@gnu.org
X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4)

Often when executing a external command, eshell gets a bit confused.
For example, when doing `ls -B' (-B will cause eshell to call the
external ls):

~ $ ls -lB
~ $ total 169316
drwxr-xr-x  5 ams ams     4096 2007-06-14 22:42 Backup
drwxr-xr-x 26 ams ams     8192 2007-07-04 13:04 Backup.tmp
drwxr-xr-x  2 ams ams     4096 2007-06-04 20:41 bin
drwxr-xr-x  2 ams ams     4096 2007-07-02 08:48 Desktop
-rw-------  1 ams ams     2120 2007-06-28 14:31 diary
drwxr-xr-x 12 ams ams     4096 2007-05-18 00:44 docs
drwxr-xr-x  3 ams ams     4096 2007-07-08 13:19 elisp
lrwxrwxrwx  1 ams ams       11 2007-05-23 23:12 emacs -> s/vcs/emacs
-rw-r--r--  1 ams ams   173896 2007-07-07 22:47 emms
lrwxrwxrwx  1 ams ams       15 2007-05-23 23:12 inetutils -> s/vcs/inetutils
drwxr-xr-x  5 ams ams     4096 2007-05-24 20:09 info
-rw-r--r--  1 ams ams      313 2007-07-08 13:20 #*mail*#9338FhM#
-rw-r--r--  1 ams ams    17749 2007-06-16 01:41 multi-mode.el
drwxr-xr-x 11 ams ams     4096 2007-06-23 15:03 Music
drwxr-xr-x  3 ams ams     4096 2007-06-15 03:06 Music.tmp
drwxr-xr-x  4 ams ams     4096 2007-06-16 01:00 News
drwxr-xr-x  5 ams ams     4096 2007-07-01 23:54 notes
-rw-r--r--  1 ams ams     5051 2007-07-08 13:18 resume
-rw-------  1 ams ams  6198546 2007-07-02 23:38 RMAIL
-r--------  1 ams ams 81400163 2006-07-13 12:19 RMAIL-2005.tar.bz2
-r--------  1 ams ams 27744447 2007-05-23 19:09 RMAIL-2007.tar.bz2
-rw-------  1 ams ams      183 2007-03-28 03:48 RMAIL.empty
-rw-------  1 ams ams  9037761 2007-07-02 21:00 RMAIL.inbox
-rw-------  1 ams ams   436632 2007-07-02 21:00 RMAIL.inbox-kemisten
-rw-------  1 ams ams    21201 2007-06-30 00:23 RMAIL.inbox-update
-rw-------  1 ams ams        0 2007-05-23 19:09 RMAIL.inbox-uu
-r--------  1 ams ams 47801466 2006-07-13 11:49 RMAIL-kemisten.tar.bz2
-rw-------  1 ams ams      183 2007-06-13 20:38 RMAIL.local
-rw-------  1 ams ams    68149 2007-06-09 00:21 RMAIL.outbox
-rw-------  1 ams ams        0 2007-05-23 19:09 RMAIL.outbox-kemisten
-rw-------  1 ams ams        0 2007-05-23 19:09 RMAIL.spam
drwxr-xr-x  5 ams ams     4096 2007-07-01 22:07 s
-rw-------  1 ams ams    99929 2007-07-08 12:36 sketch
drwxr-xr-x  2 ams ams     4096 2007-07-01 21:53 t
-rw-r--r--  1 ams ams     1441 2007-07-08 13:14 todo
-rw-r--r--  1 ams ams    18204 2007-07-08 13:16 tunes
_!_           [point is here now]

But, when inovoking the external command directly, /bin/ls -lB, it
works as it should,

~ $ /bin/ls -lB
total 169316
drwxr-xr-x  5 ams ams     4096 2007-06-14 22:42 Backup
drwxr-xr-x 26 ams ams     8192 2007-07-04 13:04 Backup.tmp
drwxr-xr-x  2 ams ams     4096 2007-06-04 20:41 bin
drwxr-xr-x  2 ams ams     4096 2007-07-02 08:48 Desktop
-rw-------  1 ams ams     2120 2007-06-28 14:31 diary
drwxr-xr-x 12 ams ams     4096 2007-05-18 00:44 docs
drwxr-xr-x  3 ams ams     4096 2007-07-08 13:19 elisp
lrwxrwxrwx  1 ams ams       11 2007-05-23 23:12 emacs -> s/vcs/emacs
-rw-r--r--  1 ams ams   173896 2007-07-07 22:47 emms
lrwxrwxrwx  1 ams ams       15 2007-05-23 23:12 inetutils -> s/vcs/inetutils
drwxr-xr-x  5 ams ams     4096 2007-05-24 20:09 info
-rw-r--r--  1 ams ams     2596 2007-07-08 13:23 #*mail*#9338FhM#
-rw-r--r--  1 ams ams    17749 2007-06-16 01:41 multi-mode.el
drwxr-xr-x 11 ams ams     4096 2007-06-23 15:03 Music
drwxr-xr-x  3 ams ams     4096 2007-06-15 03:06 Music.tmp
drwxr-xr-x  4 ams ams     4096 2007-06-16 01:00 News
drwxr-xr-x  5 ams ams     4096 2007-07-01 23:54 notes
-rw-r--r--  1 ams ams     5051 2007-07-08 13:18 resume
-rw-------  1 ams ams  6198546 2007-07-02 23:38 RMAIL
-r--------  1 ams ams 81400163 2006-07-13 12:19 RMAIL-2005.tar.bz2
-r--------  1 ams ams 27744447 2007-05-23 19:09 RMAIL-2007.tar.bz2
-rw-------  1 ams ams      183 2007-03-28 03:48 RMAIL.empty
-rw-------  1 ams ams  9037761 2007-07-02 21:00 RMAIL.inbox
-rw-------  1 ams ams   436632 2007-07-02 21:00 RMAIL.inbox-kemisten
-rw-------  1 ams ams    21201 2007-06-30 00:23 RMAIL.inbox-update
-rw-------  1 ams ams        0 2007-05-23 19:09 RMAIL.inbox-uu
-r--------  1 ams ams 47801466 2006-07-13 11:49 RMAIL-kemisten.tar.bz2
-rw-------  1 ams ams      183 2007-06-13 20:38 RMAIL.local
-rw-------  1 ams ams    68149 2007-06-09 00:21 RMAIL.outbox
-rw-------  1 ams ams        0 2007-05-23 19:09 RMAIL.outbox-kemisten
-rw-------  1 ams ams        0 2007-05-23 19:09 RMAIL.spam
drwxr-xr-x  5 ams ams     4096 2007-07-01 22:07 s
-rw-------  1 ams ams    99929 2007-07-08 12:36 sketch
drwxr-xr-x  2 ams ams     4096 2007-07-01 21:53 t
-rw-r--r--  1 ams ams     1441 2007-07-08 13:14 todo
-rw-r--r--  1 ams ams    18204 2007-07-08 13:16 tunes
~ $ _!_

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: amd@gnu.org: eshell and external commands
  2007-08-05  3:05 amd@gnu.org: eshell and external commands Richard Stallman
@ 2007-08-08 22:55 ` Chong Yidong
  2007-08-09  6:23   ` John Wiegley
  0 siblings, 1 reply; 10+ messages in thread
From: Chong Yidong @ 2007-08-08 22:55 UTC (permalink / raw)
  To: John Wiegley; +Cc: Alfred M. Szmidt, rms, emacs-devel

> Often when executing a external command, eshell gets a bit confused.
> For example, when doing `ls -B' (-B will cause eshell to call the
> external ls)
>
> But, when inovoking the external command directly, /bin/ls -B, it
> works as it should

The bug arises in the part of eshell-send-input that chooses whether
to use eshell-eval-command or eval to evaluate the command code.
Normally, it uses the more lightweight `eval' if the command is to be
invoked directly, but this loses if the "falling back on an external
program" behavior is activated.  When eshell-eval-command is used, it
seems to set things up so that the (deferred) command output goes in
the correct place.

The following patch fixes this.  However, maybe it is too drastic
because it imposes the use of eshell-eval-command on *every* build-in
command.

What do you think?


*** emacs/lisp/eshell/esh-mode.el.~1.28.2.1.~	2007-08-08 18:44:33.000000000 -0400
--- emacs/lisp/eshell/esh-mode.el	2007-08-08 18:45:49.000000000 -0400
***************
*** 727,735 ****
  		      (run-hooks 'eshell-input-filter-functions)
  		      (and (catch 'eshell-terminal
  			     (ignore
! 			      (if (eshell-invoke-directly cmd input)
! 				  (eval cmd)
! 				(eshell-eval-command cmd input))))
  			   (eshell-life-is-too-much)))))
  	      (quit
  	       (eshell-reset t)
--- 727,733 ----
  		      (run-hooks 'eshell-input-filter-functions)
  		      (and (catch 'eshell-terminal
  			     (ignore
! 			      (eshell-eval-command cmd input)))
  			   (eshell-life-is-too-much)))))
  	      (quit
  	       (eshell-reset t)

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: amd@gnu.org: eshell and external commands
  2007-08-08 22:55 ` Chong Yidong
@ 2007-08-09  6:23   ` John Wiegley
  2007-08-09 15:58     ` Chong Yidong
  0 siblings, 1 reply; 10+ messages in thread
From: John Wiegley @ 2007-08-09  6:23 UTC (permalink / raw)
  To: Chong Yidong; +Cc: Alfred M. Szmidt, rms, emacs-devel

Chong Yidong <cyd@stupidchicken.com> writes:

> The following patch fixes this.  However, maybe it is too drastic
> because it imposes the use of eshell-eval-command on *every* build-in
> command.

This is how Eshell used to behave.  It's is a bit drastic, because
eshell-eval-command is much, much slower than plain eval.

I'm prefer to find a fix which preservers the faster behavior for all cases
except those which break.

John

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: amd@gnu.org: eshell and external commands
  2007-08-09  6:23   ` John Wiegley
@ 2007-08-09 15:58     ` Chong Yidong
  2007-08-09 18:44       ` John Wiegley
  0 siblings, 1 reply; 10+ messages in thread
From: Chong Yidong @ 2007-08-09 15:58 UTC (permalink / raw)
  To: John Wiegley; +Cc: Alfred M. Szmidt, rms, emacs-devel

John Wiegley <johnw@newartisans.com> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> The following patch fixes this.  However, maybe it is too drastic
>> because it imposes the use of eshell-eval-command on *every* build-in
>> command.
>
> This is how Eshell used to behave.  It's is a bit drastic, because
> eshell-eval-command is much, much slower than plain eval.

I thought so at first, but after trying out, I don't notice any
observable slowdown for using eshell-eval-command for the eshell/*
lisp commands.

> I'm prefer to find a fix which preservers the faster behavior for all cases
> except those which break.

Another simple possibility is to make the code that falls back on
external commands perform eshell/wait on the external process, but
this has obvious drawbacks too.

I don't know how to hack the code to implement the deferment behavior
for "fallback to external programs" commands.  Do you have an idea how
to do it?

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: amd@gnu.org: eshell and external commands
  2007-08-09 15:58     ` Chong Yidong
@ 2007-08-09 18:44       ` John Wiegley
  2007-08-09 19:03         ` Chong Yidong
  0 siblings, 1 reply; 10+ messages in thread
From: John Wiegley @ 2007-08-09 18:44 UTC (permalink / raw)
  To: Chong Yidong; +Cc: Alfred M. Szmidt, rms, emacs-devel

Chong Yidong <cyd@stupidchicken.com> writes:

> I thought so at first, but after trying out, I don't notice any observable
> slowdown for using eshell-eval-command for the eshell/* lisp commands.

This is likely due to the speed of your machine.  When I was using my old
Pentium III laptop, the slowdown was so exaggerated that I finally sought the
cause -- which resulted in this fix.

> I don't know how to hack the code to implement the deferment behavior for
> "fallback to external programs" commands.  Do you have an idea how to do it?

You know, something you could do is to traverse the Lisp tree at the point of
decision looking for the symbol `eshell-external-command'.  If it's found, use
eshell-eval-command rather than eval.  That way, the slowdown is only suffered
for external commands, which are going to be slow anyway because of the
necessary invocation of an external process.

John

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: amd@gnu.org: eshell and external commands
  2007-08-09 18:44       ` John Wiegley
@ 2007-08-09 19:03         ` Chong Yidong
  2007-08-09 19:18           ` John Wiegley
  0 siblings, 1 reply; 10+ messages in thread
From: Chong Yidong @ 2007-08-09 19:03 UTC (permalink / raw)
  To: John Wiegley; +Cc: Alfred M. Szmidt, rms, emacs-devel

John Wiegley <johnw@newartisans.com> writes:

>> I don't know how to hack the code to implement the deferment
>> behavior for "fallback to external programs" commands.  Do you have
>> an idea how to do it?
>
> You know, something you could do is to traverse the Lisp tree at the
> point of decision looking for the symbol `eshell-external-command'.
> If it's found, use eshell-eval-command rather than eval.  That way,
> the slowdown is only suffered for external commands, which are going
> to be slow anyway because of the necessary invocation of an external
> process.

I don't understand this suggestion.  Since eshell-plain-command can
call eshell-external-command, wouldn't this affect everything?

The approach I was trying for was to put some code in eshell-do-opt,
before the throw to 'eshell-external:

(defun eshell-do-opt (name options body-forms)
  ...
  (if (setq
       ext-command
       (catch 'eshell-ext-command
           ....))
      (throw 'eshell-external
	     (eshell-external-command ext-command args))
    last-value))

(Or, alternatively, in eshell-lisp-command where this nonlocal exit is
caught.)

This code would need to prevent the eshell prompt from being emitted
until the external process is complete, like how the 'eshell-defer
mechanism works in eshell-resume-eval for "normal" external commands.
However, I don't know eshell well enough to make this work.  I tried
adding the return value of eshell-external-command to
eshell-last-async-proc but that doesn't work for some reason.  Do you
know what needs to be done to make it work?

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: amd@gnu.org: eshell and external commands
  2007-08-09 19:03         ` Chong Yidong
@ 2007-08-09 19:18           ` John Wiegley
  2007-10-16 15:38             ` Chong Yidong
  0 siblings, 1 reply; 10+ messages in thread
From: John Wiegley @ 2007-08-09 19:18 UTC (permalink / raw)
  To: Chong Yidong; +Cc: Alfred M. Szmidt, rms, emacs-devel

Chong Yidong <cyd@stupidchicken.com> writes:

> This code would need to prevent the eshell prompt from being emitted until
> the external process is complete, like how the 'eshell-defer mechanism works
> in eshell-resume-eval for "normal" external commands.  However, I don't know
> eshell well enough to make this work.  I tried adding the return value of
> eshell-external-command to eshell-last-async-proc but that doesn't work for
> some reason.  Do you know what needs to be done to make it work?

Ok, I have to give this some serious thought, which I cannot do just now
because I'm about to move to Grenada.  After a week or so has gone by and I've
settled in, then I can focus enough to find the right answer.

John

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: amd@gnu.org: eshell and external commands
  2007-08-09 19:18           ` John Wiegley
@ 2007-10-16 15:38             ` Chong Yidong
  2007-10-17  1:09               ` John Wiegley
  0 siblings, 1 reply; 10+ messages in thread
From: Chong Yidong @ 2007-10-16 15:38 UTC (permalink / raw)
  To: John Wiegley; +Cc: Alfred M. Szmidt, rms, emacs-devel

John Wiegley <johnw@newartisans.com> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> This code would need to prevent the eshell prompt from being emitted until
>> the external process is complete, like how the 'eshell-defer mechanism works
>> in eshell-resume-eval for "normal" external commands.  However, I don't know
>> eshell well enough to make this work.  I tried adding the return value of
>> eshell-external-command to eshell-last-async-proc but that doesn't work for
>> some reason.  Do you know what needs to be done to make it work?
>
> Ok, I have to give this some serious thought, which I cannot do just now
> because I'm about to move to Grenada.  After a week or so has gone by and I've
> settled in, then I can focus enough to find the right answer.

Hi John,

Any further thoughts on this problem?

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: amd@gnu.org: eshell and external commands
  2007-10-16 15:38             ` Chong Yidong
@ 2007-10-17  1:09               ` John Wiegley
  2007-10-17  2:08                 ` Chong Yidong
  0 siblings, 1 reply; 10+ messages in thread
From: John Wiegley @ 2007-10-17  1:09 UTC (permalink / raw)
  To: Chong Yidong; +Cc: Alfred M. Szmidt, rms, emacs-devel

Chong Yidong <cyd@stupidchicken.com> writes:

> John Wiegley <johnw@newartisans.com> writes:
>
>> Ok, I have to give this some serious thought, which I cannot do just now
>> because I'm about to move to Grenada.  After a week or so has gone by and I've
>> settled in, then I can focus enough to find the right answer.
>
> Hi John,
>
> Any further thoughts on this problem?

Yes, after looking into it, I've discovered that there is a facility for
countering this very behavior.  For commands -- like ls -- which need special
care, the command must be added to `eshell-complex-commands'.  I have seen
this behavior only from ls so far, so I think it should be added directly to
that variable's default value in esh-cmd.el.

  (defcustom eshell-complex-commands '("ls")
    "*A list of commands names or functions, that determine complexity.
  That is, if a command is defined by a function named eshell/NAME,
  and NAME is part of this list, it is invoked as a complex command.
  Complex commands are always correct, but run much slower.  If a
  command works fine without being part of this list, then it doesn't
  need to be.
  
  If an entry is a function, it will be called with the name, and should
  return non-nil if the command is complex."
    :type '(repeat :tag "Commands"
                   (choice (string :tag "Name")
                           (function :tag "Predicate")))
    :group 'eshell-cmd)

John

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: amd@gnu.org: eshell and external commands
  2007-10-17  1:09               ` John Wiegley
@ 2007-10-17  2:08                 ` Chong Yidong
  0 siblings, 0 replies; 10+ messages in thread
From: Chong Yidong @ 2007-10-17  2:08 UTC (permalink / raw)
  To: John Wiegley; +Cc: Alfred M. Szmidt, rms, emacs-devel

John Wiegley <johnw@newartisans.com> writes:

>> Any further thoughts on this problem?
>
> Yes, after looking into it, I've discovered that there is a facility for
> countering this very behavior.  For commands -- like ls -- which need special
> care, the command must be added to `eshell-complex-commands'.  I have seen
> this behavior only from ls so far, so I think it should be added directly to
> that variable's default value in esh-cmd.el.

Thanks.  I've checked this change into CVS.

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2007-10-17  2:08 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-08-05  3:05 amd@gnu.org: eshell and external commands Richard Stallman
2007-08-08 22:55 ` Chong Yidong
2007-08-09  6:23   ` John Wiegley
2007-08-09 15:58     ` Chong Yidong
2007-08-09 18:44       ` John Wiegley
2007-08-09 19:03         ` Chong Yidong
2007-08-09 19:18           ` John Wiegley
2007-10-16 15:38             ` Chong Yidong
2007-10-17  1:09               ` John Wiegley
2007-10-17  2:08                 ` Chong Yidong

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).