[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#57129: 29.0.50; Improve behavior of conditionals in Eshell
From: |
Eli Zaretskii |
Subject: |
bug#57129: 29.0.50; Improve behavior of conditionals in Eshell |
Date: |
Sun, 14 Aug 2022 08:07:49 +0300 |
> Cc: larsi@gnus.org, 57129@debbugs.gnu.org
> From: Jim Porter <jporterbugs@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.
- bug#57129: 29.0.50; Improve behavior of conditionals in Eshell, Jim Porter, 2022/08/10
- bug#57129: 29.0.50; Improve behavior of conditionals in Eshell, Jim Porter, 2022/08/10
- bug#57129: 29.0.50; Improve behavior of conditionals in Eshell, Lars Ingebrigtsen, 2022/08/12
- bug#57129: 29.0.50; Improve behavior of conditionals in Eshell, Jim Porter, 2022/08/13
- bug#57129: 29.0.50; Improve behavior of conditionals in Eshell, Eli Zaretskii, 2022/08/13
- bug#57129: 29.0.50; Improve behavior of conditionals in Eshell, Jim Porter, 2022/08/13
- bug#57129: 29.0.50; Improve behavior of conditionals in Eshell,
Eli Zaretskii <=
- bug#57129: 29.0.50; Improve behavior of conditionals in Eshell, Jim Porter, 2022/08/14
- bug#57129: 29.0.50; Improve behavior of conditionals in Eshell, Eli Zaretskii, 2022/08/14
- bug#57129: 29.0.50; Improve behavior of conditionals in Eshell, Jim Porter, 2022/08/14
- bug#57129: 29.0.50; Improve behavior of conditionals in Eshell, Eli Zaretskii, 2022/08/15
- bug#57129: 29.0.50; Improve behavior of conditionals in Eshell, Jim Porter, 2022/08/15
- bug#57129: 29.0.50; Improve behavior of conditionals in Eshell, Eli Zaretskii, 2022/08/15
- bug#57129: 29.0.50; Improve behavior of conditionals in Eshell, Jim Porter, 2022/08/15
- bug#57129: 29.0.50; Improve behavior of conditionals in Eshell, Eli Zaretskii, 2022/08/15
- bug#57129: 29.0.50; Improve behavior of conditionals in Eshell, Jim Porter, 2022/08/15
- bug#57129: 29.0.50; Improve behavior of conditionals in Eshell, Eli Zaretskii, 2022/08/15