bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#54603: 29.0.50; [PATCH] Eshell's external pipe module interferes wit


From: Sean Whitton
Subject: bug#54603: 29.0.50; [PATCH] Eshell's external pipe module interferes with other argument parsing hooks
Date: Thu, 31 Mar 2022 11:26:26 -0700
User-agent: Emacs/29.0.50 (x86_64-pc-linux-gnu)

Hello Jim,

On Sun 27 Mar 2022 at 07:21PM -07, Jim Porter wrote:

> The attached patch resolves the issue for me, but I'm not sure if it's
> the best strategy.

Thank you for looking into this.  I think however that the bug is not in
the em-extpipe.el, and so your patch is probably not the best fix.

The call to `eshell-parse-lisp-argument' is meant to handle precisely
your case.  It isn't doing atm, and I think it might actually be a bug
over in that function.  To see this, with point on the first nonblank
char of each of these lines, do 'M-: (eshell-parse-lisp-argument) RET':

    #'foo

    'foo

In the first case it successfully parses it and skips point forward, but
in the latter case it does not.  But I think it should, right?

> If possible, I think it would be better for
> `eshell-parse-external-pipeline' to solely focus on finding the
> external pipe operators ("*|", "*<", and "*>")[1] and then for
> `eshell-rewrite-external-pipeline' to prepare the command string to
> pass to sh. This would also have the advantage[2] of making it
> possible to support a richer set of Eshell features with external
> pipes, such as the following:
>
>    ~ $ echo $(message "[%s]" "hi") *| cat
>    zsh:1: command not found: message
>
> (If you remove the "*", this outputs "[hi]", and it should be
> technically possible to make this work with external pipes too, provided
> it executes the Lisp code before generating the command string for sh.)

In this case I would want the whole '$(message ..'  construction to go
to the external shell.  Although extpipe supports some combinations of
piping Eshell in and out of the external shell, fundamentally it's more
about making it easier to bypass Eshell features than to make complex
usage of them.  It's also simpler to understand as a user.  If you do
want more involved combinations of Eshell and external shell commands,
you can always do the 'sh -c' wrapping yourself.

-- 
Sean Whitton





reply via email to

[Prev in Thread] Current Thread [Next in Thread]