GNU bug report logs - #53518
29.0.50; em-extpipe breaks input of sharp-quoted Lisp symbols

Previous Next

Full log

View this message in rfc822 format

From: Jim Porter <jporterbugs <at> gmail.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>, 53518 <at> debbugs.gnu.org
Cc: Michael Albinus <michael.albinus <at> gmx.de>
Subject: bug#53518: 29.0.50; em-extpipe breaks input of sharp-quoted Lisp symbols
Date: Tue, 25 Jan 2022 12:52:36 -0800

On 1/25/2022 12:01 PM, Sean Whitton wrote:
>> In addition to being consistent with how Eshell currently works, this
>> allows you to do things like "echo hi | less -N", where "less -N" is
>> evaluated as an Eshell command and then returns a pseudo-pipe for echo
>> to connect to.
> 
> It's not quite clear to me how this is consistent with how Eshell
> currently works.  When you type "echo hi | cat" is it right to say that
> "cat" is evaluated to produce the thing to which the output of the first
> command is piped?  Perhaps I'm not thinking broadly enough.

In general, I just mean that when running a command "foo" (in a pipeline 
or not), if Eshell finds a Lisp function for "foo", it always calls that 
function. On the other hand, "#'foo" always evaluates to the function 
object itself.

So, since "cat" points to a Lisp function, your summary is pretty close, 
I'd say. However, I think I'd describe it as "cat is evaluated to hook 
up the pipeline into what the user meant". Currently, it works like so:

1. `eshell-parse-command' turns "echo hi | cat" into:
   (eshell-commands
    (progn
      (run-hooks 'eshell-pre-command-hook)
      (catch 'top-level
        (progn
          (eshell-trap-errors
           (eshell-execute-pipeline
            '((eshell-named-command "echo" (list "hi"))
              (eshell-named-command "cat"))))))
      (run-hooks 'eshell-post-command-hook)))

2. Eshell iteratively evaluates that, eventually getting to to the "cat"
   part

3. `eshell-named-command' looks for "cat" and calls the function
   `eshell/cat'

4. `eshell/cat' notices that it's being called in a pipeline and bails
   out, throwing `eshell-replace-command' to convert "cat" into
   "/bin/cat" (or wherever your cat program lives)

5. This gets reevaluated in `eshell-do-eval' and calls
   `eshell-external-command' for "/bin/cat"

6. This calls `eshell-gather-process-output', returning a process
   object with the pipes connected

That is, Eshell evaluates `eshell/cat' (which could do anything, really) 
with the ultimate goal of hooking up the pipeline. Currently that just 
means "call /bin/cat and connect pipes to the external process", but 
`eshell/cat' can do whatever it wants to achieve the result.

For the "pipe to a Lisp function" case, like "echo hi | #'upcase", 
what's actually happening under the hood in my patch it that "#'upcase" 
is evaluated, Eshell sees that the result is a function, and then the 
function is converted into a pseudo-pipe that gets properly hooked up to 
echo.

For a case like "echo hi | less -N", where "less" has a Lisp 
implementation, Eshell evaluates `(eshell/less "-N")', which could 
return a function that gets converted into a pseudo-pipe like above. Or 
(and this is how `eshell/less' will actually work), it returns its own 
pseudo-pipe that's hooked up properly; this case is analogous to 
`eshell-gather-process-output' returning a properly-connected process 
object.

The subtleties of Lisp functions in pipelines will probably be a bit 
easier to understand once I post patches, which should hopefully be this 
week or next. :) The patches work already, but I'm still implementing a 
few more pipeable Eshell commands in Lisp so that I can be sure the core 
implementation is flexible enough to be used for practical cases.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.