Re: Some more eshell problems

[Thierry Volpiatto]

Tassilo Horn <address@hidden> writes:

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

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

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