GNU bug report logs - #54603
29.0.50; [PATCH] Eshell's external pipe module interferes with other argument parsing hooks

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 54603 in the body.
You can then email your comments to 54603 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; [PATCH] Eshell's external pipe module interferes with other
 argument parsing hooks
Date: Sun, 27 Mar 2022 19:21:17 -0700

[Message part 1 (text/plain, inline)]

From "emacs -Q --eval '(eshell)':

  ~ $ (eq 'foo nil)
  Expecting completion of delimiter ' ...

  M-: (unload-feature 'em-extpipe)

  ~ $ (eq 'foo nil)
  ;; No output, since it returns nil. This is correct.

(As an ironic twist, you'd normally be able to run "(unload-feature 
'em-extpipe)" as a command in Eshell, but this bug prevents that from 
working.)

I don't fully understand all the details of the code in 
lisp/eshell/em-extpipe.el yet, but I think this is the culprit:

                         (while (or (eshell-parse-lisp-argument)
                                    (eshell-parse-backslash)
                                    (eshell-parse-double-quote)
                                    (eshell-parse-literal-quote)))

In particular, since there are 3 single-quotes, 
`eshell-parse-literal-quote' throws an `eshell-incomplete' error, which 
gums up the works.

The attached patch resolves the issue for me, but I'm not sure if it's 
the best strategy. 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.)

[1] See `eshell-parse-delimiter' for an example of how that might be 
implemented.
[2] Well, maybe there's room for debate on what the right behavior here is.

[0001-Make-Eshell-s-extpipe-more-lenient-when-looking-for-.patch (text/plain, attachment)]

Message #8 received at 54603 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 54603 <at> debbugs.gnu.org, John Wiegley <johnw <at> gnu.org>
Subject: Re: bug#54603: 29.0.50; [PATCH] Eshell's external pipe module
 interferes with other argument parsing hooks
Date: Thu, 31 Mar 2022 13:46:09 +0200

Jim Porter <jporterbugs <at> gmail.com> writes:

> The attached patch resolves the issue for me, but I'm not sure if it's
> the best strategy. 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:

I think that sounds like a good idea (but I don't use eshell regularly,
so I don't really have much of an opinion here).  Perhaps John does;
added to the CCs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #11 received at 54603 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 54603 <at> debbugs.gnu.org, John Wiegley <johnw <at> gnu.org>,
 Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#54603: 29.0.50; [PATCH] Eshell's external pipe module
 interferes with other argument parsing hooks
Date: Thu, 31 Mar 2022 09:26:28 -0700

On 3/31/2022 4:46 AM, Lars Ingebrigtsen wrote:
> Jim Porter <jporterbugs <at> gmail.com> writes:
> 
>> The attached patch resolves the issue for me, but I'm not sure if it's
>> the best strategy. 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:
> 
> I think that sounds like a good idea (but I don't use eshell regularly,
> so I don't really have much of an opinion here).  Perhaps John does;
> added to the CCs.

CCing Sean as well, who implemented the extpipe module.

(I probably should have done that in the initial report, but I'm not 
sure the right way to CC people when I'm mailing bug-gnu-emacs@; if the 
CCed person replies normally, wouldn't it make a new bug number? I'm 
sure this is in the debbugs documentation though, so I should sit down 
and read it sometime.)

Message #14 received at 54603 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: larsi <at> gnus.org, 54603 <at> debbugs.gnu.org, johnw <at> gnu.org,
 spwhitton <at> spwhitton.name
Subject: Re: bug#54603: 29.0.50;
 [PATCH] Eshell's external pipe module interferes with other argument
 parsing hooks
Date: Thu, 31 Mar 2022 19:50:57 +0300

> From: Jim Porter <jporterbugs <at> gmail.com>
> Date: Thu, 31 Mar 2022 09:26:28 -0700
> Cc: 54603 <at> debbugs.gnu.org, John Wiegley <johnw <at> gnu.org>,
>  Sean Whitton <spwhitton <at> spwhitton.name>
> 
> (I probably should have done that in the initial report, but I'm not 
> sure the right way to CC people when I'm mailing bug-gnu-emacs@; if the 
> CCed person replies normally, wouldn't it make a new bug number?

No, not as long as they respond with the same Subject.

Message #17 received at 54603 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 54603 <at> debbugs.gnu.org,
 John Wiegley <johnw <at> gnu.org>, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#54603: 29.0.50; [PATCH] Eshell's external pipe module
 interferes with other argument parsing hooks
Date: Thu, 31 Mar 2022 19:35:48 +0200

Jim Porter <jporterbugs <at> gmail.com> writes:

Hi Jim,

> (I probably should have done that in the initial report, but I'm not
> sure the right way to CC people when I'm mailing bug-gnu-emacs@; if
> the CCed person replies normally, wouldn't it make a new bug number?
> I'm sure this is in the debbugs documentation though, so I should sit
> down and read it sometime.)

In the initial report, use an "X-Debbugs-Cc" header. See
admin/notes/bugtracker.

Best regards, Michael.

Message #20 received at 54603 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Jim Porter <jporterbugs <at> gmail.com>, 54603 <at> debbugs.gnu.org
Subject: Re: 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

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

Message #23 received at 54603 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>, 54603 <at> debbugs.gnu.org
Subject: Re: bug#54603: 29.0.50; [PATCH] Eshell's external pipe module
 interferes with other argument parsing hooks
Date: Thu, 31 Mar 2022 13:58:11 -0700

On 3/31/2022 11:26 AM, Sean Whitton wrote:
> 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?

I'm not so sure. That would mean "'foo" in "echo 'foo" is treated as a 
Lisp form, but Eshell expects you to use "#'" (or "(" or "`") to 
introduce a Lisp form. As I understand it, that's so that typos don't do 
such surprising things. There's a good chance that a user typing "echo 
'foo" actually meant "echo 'foo'".

Because of that, in general, once you've moved point to partway inside a 
Lisp form, you can't use `eshell-parse-lisp-argument'. Maybe that should 
be changed? It's a bit surprising that you have to sharp-quote symbols 
in Eshell if you're not already inside a Lisp form (especially when 
those symbols aren't necessarily functions). Still, the typo-protection 
of the current implementation seems like a good feature...

That said, this isn't the only situation where "unbalanced" single 
quotes can occur in an Eshell command. For example, see this command:

  echo $(list "one" "two")(:s'o'x')

This creates a list of two strings, and then performs a regexp 
substitution from "o" to "x", so the output is:

  ("xne" "twx")

Under Emacs 27/28, this works correctly, but it fails in 29 for the same 
reason as the original issue. The extpipe module could account for this 
and try to parse argument predicates/modifiers so that it knows when to 
stay out of things, but then what about configurations where that module 
is disabled? (And for that matter, a third-party Eshell module could 
cause conflicts in a similar manner.)

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

From my point of view, since the only difference between using an 
"Eshell pipe" and an extpipe is that the pipe operator has a "*", I'd 
expect the commands to work largely the same, except that the extpipe is 
faster. When I see a command like 'echo $(message "[%s]" "hi") *| cat', 
I usually think of it as a two-phase operation: expansions/subcommands 
are expanded first, and then the final command is executed. In that 
model, the expansions would still be "in Eshell".

On the other hand, maybe there's enough practical use for passing the 
raw command string to `sh' that there should be a very simple way of 
invoking it (and without having to mess around with escaping interior 
quotes, as you would if you used `sh -c' manually). Maybe the parsing 
would be more robust if it used special sigils for the start/end of the 
external command? I suppose that's similar to your original proposal of 
using !! or || to introduce an external pipeline, so maybe it's not 
feasible to go this route.

Another possibility would be to keep the current behavior (or close to 
it), but to reconstruct the command to pass to `sh' during Eshell's 
rewrite phase. I'm not quite sure if that would actually work, but if it 
did, it would allow other argument parsers to run normally without 
extpipe needing to know what parsers to try. Perhaps if we kept around 
the substring that each argument parser consumed, it would be possible 
to reconstruct the relevant bits for extpipe's purposes?

More generally though, maybe there are really two different use cases?

1) Eshell's built-in pipelines are slow because they go through Emacs 
buffers.

2) It would be convenient to invoke a whole command (or some large part 
of a command) using `sh' syntax.

For (1), Eshell could opportunistically use external pipelines without 
any special syntax. It should be possible to tell just by looking at the 
parsed command form if "foo | bar" connects two external processes on 
the same host, and then perform the appropriate rewrite to connect the 
processes efficiently (e.g. using `sh -c'). This would happen after 
expansion of variables/subcommands, so to the user it would work just 
like any other Eshell command, but it would be faster.

For (2), we'd need a convenient syntax for forwarding some command 
string to `sh'. Something like your proposed !! or || syntax, or maybe 
something to wrap around part of a command? (Or maybe an even something 
like an interactive `eshell-externalize' function that replaces the 
selected region with the correct `sh' invocation?)

And finally, sorry for bringing up these issues months after bug#46351. 
At the time, I didn't really understand the internals of Eshell, so I 
didn't have anything of substance to say then. Since then I've delved a 
bit *too* deep into Eshell's internals while trying to prove to myself 
that my implementation of Lisp function pipelines is 
sufficiently-flexible. :)

Message #26 received at 54603 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Jim Porter <jporterbugs <at> gmail.com>, 54603 <at> debbugs.gnu.org
Subject: Re: bug#54603: 29.0.50; [PATCH] Eshell's external pipe module
 interferes with other argument parsing hooks
Date: Thu, 31 Mar 2022 14:55:41 -0700

Hello,

On Thu 31 Mar 2022 at 01:58PM -07, Jim Porter wrote:

> I'm not so sure. That would mean "'foo" in "echo 'foo" is treated as a
> Lisp form, but Eshell expects you to use "#'" (or "(" or "`") to
> introduce a Lisp form. As I understand it, that's so that typos don't do
> such surprising things. There's a good chance that a user typing "echo
> 'foo" actually meant "echo 'foo'".

Right okay.  We can just skip over entire Lisp forms when we find them.
I don't think there could be a non-highly esoteric shell command for
standard POSIX shells -- which is what this feature is for -- which that
would break.  Like this:

>> diff --git a/lisp/eshell/em-extpipe.el b/lisp/eshell/em-extpipe.el
>> index eb5b3bfe1d..0787ab791b 100644
>> --- a/lisp/eshell/em-extpipe.el
>> +++ b/lisp/eshell/em-extpipe.el
>> @@ -99,7 +99,7 @@ eshell-parse-external-pipeline
>>                       (let* ((found
>>                               (save-excursion
>>                                 (re-search-forward
>> -                                "\\(?:#?'\\|\"\\|\\\\\\)" bound t)))
>> +                                "\\(?:(\\|#?'\\|\"\\|\\\\\\)" bound t)))
>>                              (next (or (and found (match-beginning 0))
>>                                        bound)))
>>                         (if (re-search-forward pat next t)
>>

Something in my init.el is breaking the extpipe tests atm, but I ad hoc
tested one of your cases for this bug and it works.  Could you confirm?

> That said, this isn't the only situation where "unbalanced" single
> quotes can occur in an Eshell command. For example, see this command:
>
>    echo $(list "one" "two")(:s'o'x')
>
> This creates a list of two strings, and then performs a regexp
> substitution from "o" to "x", so the output is:
>
>    ("xne" "twx")
>
> Under Emacs 27/28, this works correctly, but it fails in 29 for the
> same reason as the original issue. The extpipe module could account
> for this and try to parse argument predicates/modifiers so that it
> knows when to stay out of things, but then what about configurations
> where that module is disabled? (And for that matter, a third-party
> Eshell module could cause conflicts in a similar manner.)

I think the correct thing is for extpipe to do something sensible with
all the Eshell syntax that is enabled by default.  We should call the
relevant parsing function to skip over these predicates/modifiers too.

If you're changing the list of modules then you might have to drop
extpipe as part of that process -- that's just inherent in how Eshell
modules work.  There's always going to be a limit to how much syntax you
can have enabled at once.

-- 
Sean Whitton

Message #29 received at 54603 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>, 54603 <at> debbugs.gnu.org
Subject: Re: bug#54603: 29.0.50; [PATCH] Eshell's external pipe module
 interferes with other argument parsing hooks
Date: Thu, 31 Mar 2022 15:19:58 -0700

On 3/31/2022 2:55 PM, Sean Whitton wrote:
> On Thu 31 Mar 2022 at 01:58PM -07, Jim Porter wrote:
> 
>> I'm not so sure. That would mean "'foo" in "echo 'foo" is treated as a
>> Lisp form, but Eshell expects you to use "#'" (or "(" or "`") to
>> introduce a Lisp form. As I understand it, that's so that typos don't do
>> such surprising things. There's a good chance that a user typing "echo
>> 'foo" actually meant "echo 'foo'".
> 
> Right okay.  We can just skip over entire Lisp forms when we find them.
> I don't think there could be a non-highly esoteric shell command for
> standard POSIX shells -- which is what this feature is for -- which that
> would break.  Like this:
> 
>>> diff --git a/lisp/eshell/em-extpipe.el b/lisp/eshell/em-extpipe.el
>>> index eb5b3bfe1d..0787ab791b 100644
>>> --- a/lisp/eshell/em-extpipe.el
>>> +++ b/lisp/eshell/em-extpipe.el
>>> @@ -99,7 +99,7 @@ eshell-parse-external-pipeline
>>>                        (let* ((found
>>>                                (save-excursion
>>>                                  (re-search-forward
>>> -                                "\\(?:#?'\\|\"\\|\\\\\\)" bound t)))
>>> +                                "\\(?:(\\|#?'\\|\"\\|\\\\\\)" bound t)))
>>>                               (next (or (and found (match-beginning 0))
>>>                                         bound)))
>>>                          (if (re-search-forward pat next t)
>>>
> 
> Something in my init.el is breaking the extpipe tests atm, but I ad hoc
> tested one of your cases for this bug and it works.  Could you confirm?

The first test case -- "(eq 'foo nil)" -- works, but the second doesn't:

  ~ $ echo $(list "one" "two")(:s'o'x')
  Invalid read syntax: ")", 1, 33

Similarly:

  ~ $ echo *(:gs'o'x')
  Invalid read syntax: ")", 1, 16

I guess this is because it's now trying to read the argument modifier as 
a Lisp form. Normally, `eshell-parse-lisp-argument' would ignore that 
bit, since the `(' starting the modifier isn't at the beginning of an 
argument. This could probably be resolved with some additional logic 
(setting `eshell-current-argument' as appropriate?), but I hope there's 
a cleaner way that doesn't involve reimplementing 
`eshell-parse-argument' within `eshell-parse-external-pipeline'.

Message #32 received at 54603 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Jim Porter <jporterbugs <at> gmail.com>, 54603 <at> debbugs.gnu.org
Subject: Re: bug#54603: 29.0.50; [PATCH] Eshell's external pipe module
 interferes with other argument parsing hooks
Date: Thu, 31 Mar 2022 15:48:33 -0700

Hello,

On Thu 31 Mar 2022 at 03:19pm -07, Jim Porter wrote:

> This could probably be resolved with some additional logic (setting
> `eshell-current-argument' as appropriate?), but I hope there's a
> cleaner way that doesn't involve reimplementing
> `eshell-parse-argument' within `eshell-parse-external-pipeline'.

Well, quite.

Thank you for testing.  In the meantime, I've thought it all through
some more, and I think that your original idea of catching the
'eshell-incomplete is the right thing, assuming all tests pass.

I think the error should be caught inside the `or', though?  The idea
would be that if eshell-incomplete is thrown within one of the
disjuncts, that disjunct should return nil.

-- 
Sean Whitton

Message #35 received at 54603 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Jim Porter <jporterbugs <at> gmail.com>
Cc: 54603 <at> debbugs.gnu.org, John Wiegley <johnw <at> gnu.org>
Subject: Re: bug#54603: 29.0.50; [PATCH] Eshell's external pipe module
 interferes with other argument parsing hooks
Date: Thu, 31 Mar 2022 15:55:56 -0700

Hello,

On Thu 31 Mar 2022 at 01:46pm +02, Lars Ingebrigtsen wrote:

> Jim Porter <jporterbugs <at> gmail.com> writes:
>
>> The attached patch resolves the issue for me, but I'm not sure if it's
>> the best strategy. 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:
>
> I think that sounds like a good idea (but I don't use eshell regularly,
> so I don't really have much of an opinion here).  Perhaps John does;
> added to the CCs.

As discussed down thread, this would kind of be a different feature --
one purpose of the extpipe syntax is to make it easy to have the
operating system shell interpret complex shell syntax rather than
Eshell.

Jim has an idea about making ordinary Eshell pipes automatically use the
external shell where possible, which would satisfy this usecase better
if it works out, I think.

-- 
Sean Whitton

Message #38 received at 54603 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>, 54603 <at> debbugs.gnu.org
Subject: Re: bug#54603: 29.0.50; [PATCH] Eshell's external pipe module
 interferes with other argument parsing hooks
Date: Thu, 31 Mar 2022 16:31:53 -0700

[Message part 1 (text/plain, inline)]

On 3/31/2022 3:48 PM, Sean Whitton wrote:
> Thank you for testing.  In the meantime, I've thought it all through
> some more, and I think that your original idea of catching the
> 'eshell-incomplete is the right thing, assuming all tests pass.
> 
> I think the error should be caught inside the `or', though?  The idea
> would be that if eshell-incomplete is thrown within one of the
> disjuncts, that disjunct should return nil.

Hmm, that's an interesting thought. Maybe this code could be more 
particular about what parse function it calls. Since each of the 
function calls here:

                         (while (or (eshell-parse-lisp-argument)
                                    (eshell-parse-backslash)
                                    (eshell-parse-double-quote)
                                    (eshell-parse-literal-quote)))

correspond to a particular token here (earlier in the source):

                               (re-search-forward
                                "\\(?:(\\|#?'\\|\"\\|\\\\\\)" bound t)))

perhaps it would be better to match the function call to the 
corresponding token. That is, if we see a "#?", we call 
`eshell-parse-lisp-argument', and so on. See the attached patch, which 
works in my tests (and passes all the existing Eshell unit tests).

[0001-Make-Eshell-s-extpipe-more-lenient-when-looking-for-.patch (text/plain, attachment)]

Message #41 received at 54603 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Jim Porter <jporterbugs <at> gmail.com>, 54603 <at> debbugs.gnu.org
Subject: Re: bug#54603: 29.0.50; [PATCH] Eshell's external pipe module
 interferes with other argument parsing hooks
Date: Fri, 01 Apr 2022 14:16:13 -0700

[Message part 1 (text/plain, inline)]

Hello,

On Thu 31 Mar 2022 at 04:31PM -07, Jim Porter wrote:

> On 3/31/2022 3:48 PM, Sean Whitton wrote:
>> 
>> I think the error should be caught inside the `or', though?  The idea
>> would be that if eshell-incomplete is thrown within one of the
>> disjuncts, that disjunct should return nil.
>
> Hmm, that's an interesting thought. Maybe this code could be more 
> particular about what parse function it calls. Since each of the 
> function calls here:
>
>                           (while (or (eshell-parse-lisp-argument)
>                                      (eshell-parse-backslash)
>                                      (eshell-parse-double-quote)
>                                      (eshell-parse-literal-quote)))
>
> correspond to a particular token here (earlier in the source):
>
>                                 (re-search-forward
>                                  "\\(?:(\\|#?'\\|\"\\|\\\\\\)" bound t)))
>
> perhaps it would be better to match the function call to the 
> corresponding token.

Thank you for this suggestion, but I think that findbeg1 is more
readable, and actually perhaps more efficient, if we maintain the 
(while (or ...)) structure.

So I would like to install the attached patch to resolve this bug.

-- 
Sean Whitton

[0001-em-extpipe-Catch-eshell-incomplete-thrown-while-pars.patch (text/x-patch, attachment)]

Message #44 received at 54603 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>, 54603 <at> debbugs.gnu.org
Subject: Re: bug#54603: 29.0.50; [PATCH] Eshell's external pipe module
 interferes with other argument parsing hooks
Date: Fri, 1 Apr 2022 18:31:13 -0700

On 4/1/2022 2:16 PM, Sean Whitton wrote:
> Thank you for this suggestion, but I think that findbeg1 is more
> readable, and actually perhaps more efficient, if we maintain the
> (while (or ...)) structure.
> 
> So I would like to install the attached patch to resolve this bug.

Thanks, this patch looks good to me, though I didn't actually build with 
it. Just let me know if you'd like me to test it out.

Message #47 received at 54603 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 54603 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#54603: 29.0.50; [PATCH] Eshell's external pipe module
 interferes with other argument parsing hooks
Date: Sat, 02 Apr 2022 16:09:21 +0200

Jim Porter <jporterbugs <at> gmail.com> writes:

>> Thank you for this suggestion, but I think that findbeg1 is more
>> readable, and actually perhaps more efficient, if we maintain the
>> (while (or ...)) structure.
>> So I would like to install the attached patch to resolve this bug.
>
> Thanks, this patch looks good to me, though I didn't actually build
> with it. Just let me know if you'd like me to test it out.

I've now pushed Sean's patch to Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #52 received at 54603 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Jim Porter <jporterbugs <at> gmail.com>
Cc: 54603 <at> debbugs.gnu.org
Subject: Re: bug#54603: 29.0.50; [PATCH] Eshell's external pipe module
 interferes with other argument parsing hooks
Date: Sat, 02 Apr 2022 08:52:05 -0700

Hello,

On Sat 02 Apr 2022 at 04:09pm +02, Lars Ingebrigtsen wrote:

> Jim Porter <jporterbugs <at> gmail.com> writes:
>
>>> Thank you for this suggestion, but I think that findbeg1 is more
>>> readable, and actually perhaps more efficient, if we maintain the
>>> (while (or ...)) structure.
>>> So I would like to install the attached patch to resolve this bug.
>>
>> Thanks, this patch looks good to me, though I didn't actually build
>> with it. Just let me know if you'd like me to test it out.
>
> I've now pushed Sean's patch to Emacs 29.

Sweet, thanks both!

-- 
Sean Whitton

Previous Next

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