Re: Some more eshell problems

[Tassilo Horn]

Aidan Gauland <address@hidden> 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.

>> 2. When I update my emacs checkout in eshell, I get this:
>>
>>      $ bzr pull
>>      Using saved parent location: bzr+ssh://address@hidden/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.

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