From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thierry Volpiatto Newsgroups: gmane.emacs.devel Subject: Re: Some more eshell problems Date: Fri, 07 Jun 2013 14:39:03 +0200 Organization: Emacs Helm Message-ID: <8761xqaye0.fsf@gmail.com> References: <87ehcn4drw.fsf@thinkpad.tsdh.de> <87ppw5y0dn.fsf@dimension8.tehua.net> <87k3mcamkm.fsf@thinkpad.tsdh.de> <874ndg3vf5.fsf@dimension8.tehua.net> <8761xv7jhq.fsf@thinkpad.tsdh.de> <87y5arc65w.fsf@dimension8.tehua.net> <87hahel63t.fsf_-_@thinkpad.tsdh.de> <87mwr2o9od.fsf@dimension8.tehua.net> <87bo7i1785.fsf@thinkpad.tsdh.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1370608775 21748 80.91.229.3 (7 Jun 2013 12:39:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Jun 2013 12:39:35 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 07 14:39:35 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ukvx8-0004pq-0r for ged-emacs-devel@m.gmane.org; Fri, 07 Jun 2013 14:39:34 +0200 Original-Received: from localhost ([::1]:55658 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ukvx7-00039o-6R for ged-emacs-devel@m.gmane.org; Fri, 07 Jun 2013 08:39:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39724) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ukvx0-00038o-Li for emacs-devel@gnu.org; Fri, 07 Jun 2013 08:39:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ukvwt-0001Zf-V3 for emacs-devel@gnu.org; Fri, 07 Jun 2013 08:39:26 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:44710) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ukvwt-0001ZT-Nv for emacs-devel@gnu.org; Fri, 07 Jun 2013 08:39:19 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ukvwr-0004dl-0f for emacs-devel@gnu.org; Fri, 07 Jun 2013 14:39:17 +0200 Original-Received: from 37.161.211.165 ([37.161.211.165]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 Jun 2013 14:39:17 +0200 Original-Received: from thierry.volpiatto by 37.161.211.165 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 Jun 2013 14:39:17 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 80 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 37.161.211.165 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:mCDNPmkL7dxqY6F/zd5D8Dm9zzY= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:160209 Archived-At: Tassilo Horn writes: > Aidan Gauland writes: > > Hi Aidan, > >>> 1. I'm a bit unsure about what prefixing commands with * actually means. >>> John Wiegley told me on IRC that it means "don't do any special >>> interpretation", and I assumed that includes interpreting commands >>> visually. But still, >>> >>> $ *top >>> >>> shows top in a term buffer. >> >> My understanding is that the * prefix tells Eshell to use the external >> command instead of the built-in lisp command (if any). So, for example, >> ls invokes the lisp function eshell/ls, but *ls invokes /bin/ls. I'll >> have to take some time to check this in the source code. (The command >> parser is a bit of a mess.) > > Ah, ok, that's also possible. But still it would be nice to have > something to suppress all "magic" like visual commands. For example, > I'm very happy with my visual customization of "git log" and friends, > but then it would allow me to work around the visual-while-redirection > bug. Maybe the prefix ** would make sense. If an `eshell/top' function exists, it will be used when using top, otherwise, top and *top will be the same. >>> 2. When I update my emacs checkout in eshell, I get this: >>> >>> $ bzr pull >>> Using saved parent location: bzr+ssh://tsdh@bzr.savannah.gnu.org/emacs/trunk/ >>> No revisions or tags to pull. >>> Killed by signal 1. >>> >>> Doing the same in zsh or bash, I get the same output except for the >>> "Killed by signal 1.". In all three cases, the return code $? is 0. >>> It seems that only happens with bzr commands, not with git or hg >>> commands. So it's probably a bzr problem, right? >> >> OK, that is really weird, and I have no idea where to start debugging >> this, but I'd hazard a guess that it is Eshell weirdness, not bzr. > > Ok. But the commands work anyway, so it's more or less only a cosmetic > problem. Look into /dev/pts you will see the corresponding pts for eshell is ephemeral (start-process), it is IMO the one that is "killed by signal 1" when command exit. You don't have the same in bash/zsh terminal because it exists in /dev/pts. It is why we have to type password at every sudo command, the pts can't be registered. It is my understanding, maybe I am wrong, correct me if so. >>> 3. Sometimes, when I run "git log" or "bzr log" as visual commands, the >>> output is correctly shown in a term buffer, but when I hit q the mode >>> line switches from (Term: char run) to (Term: char no process) and >>> the buffer isn't killed. I have no clue when this happens, but when >>> it does, it seems to stay that way for the whole emacs session. >> >> That sounds like a problem with term (or ansi-term, whichever Eshell >> invokes), but I suppose it's possibly a problem with how Eshell is >> (possibly erratically) invoking (ansi-)term. > > That actually happens really really seldomly. If I get to the cause by > accident, I'll give you more information. > > Bye, > Tassilo > > -- Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997