GNU bug report logs - #57129
29.0.50; Improve behavior of conditionals in Eshell

Previous Next

Full log

Message #26 received at 57129 <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, 57129 <at> debbugs.gnu.org
Subject: Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell
Date: Sun, 14 Aug 2022 08:07:49 +0300

> Cc: larsi <at> gnus.org, 57129 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> Date: Sat, 13 Aug 2022 11:56:20 -0700
> 
> On 8/13/2022 12:01 AM, Eli Zaretskii wrote:
> > One of the tests in esh-var-tests.el failed on MS-Windows; I fixed it,
> > although I'm not sure it's a correct fix, because the Eshell manual
> > seems to say that a built-in implementation of a command should be
> > preferred by default?
> 
> Sorry about that. I think that's the right fix for that case. Maybe it 
> would make sense to set 'eshell-prefer-lisp-functions' to t for most of 
> the Eshell tests to improve reproducibility on various platforms; tests 
> that want an external command can just put a "*" in front of the command 
> name.

But then this fragment from the Eshell manual:

     The command can be either an Elisp function or an external command.
  Eshell looks first for an alias (*note Aliases::) with the same name as
  the command, then a built-in (*note Built-ins::) or a function with the
  same name; if there is no match, it then tries to execute it as an
  external command.

seems to be inaccurate?  Since 'format' exists as a built-in command,
why did Eshell in this case invoke the external command instead?

> I'm surprised that test fails on MS Windows, since it *should* be 
> testing internal Eshell logic that's not platform-specific. Based on the 
> failure, it looks like one of the following commands is returning the 
> wrong value:
> 
>    echo {echo $eshell-in-pipeline-p | echo} | *cat
>    echo ${echo $eshell-in-pipeline-p | echo} | *cat
>    *cat $<echo $eshell-in-pipeline-p | echo> | *cat
> 
> All of these should return 'first'.

The first two do; the last one returns nothing.

> That test is just checking that, 
> when you're in a subcommand ({...}, ${...}, or $<...>), the value of 
> 'eshell-in-pipeline-p' shouldn't be influenced by the pipeline in the 
> "super-command". Some built-in Eshell commands consult 
> 'eshell-in-pipeline-p', and if it had the wrong value, they might do the 
> wrong thing.

So how to investigate this failure further?

> If nothing else, it would probably be helpful to set up ERT explainers 
> so that the error messages are easier to understand. As it is now, 
> they're not very explanatory.

Indeed, more explanations in this and other tests will be most
welcome.

Thanks.

Previous Next

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