Re: Some more eshell problems

[Aidan Gauland <aidalgol@amuri.net>]

Tassilo Horn <tsdh@gnu.org> writes:

> While we're at it, here are some other things:
>
> 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.)

> 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.

> 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.

--Aidan