From: Jim Porter <jporterbugs@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: larsi@gnus.org, 57129@debbugs.gnu.org
Subject: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell
Date: Mon, 15 Aug 2022 11:08:45 -0700 [thread overview]
Message-ID: <d5cd4361-9004-efdc-2308-958296ca201f@gmail.com> (raw)
In-Reply-To: <83pmh1h2pv.fsf@gnu.org>
On 8/15/2022 9:49 AM, Eli Zaretskii wrote:
> None of these reverts fixes the issue. I tried both the tests in
> eshell-tests.el and the problematic command:
>
> *cat $<echo $eshell-in-pipeline-p | echo> | *cat
Thanks for testing. I might have to get an MS-Windows dev environment
set up to dig into this further. I'm a bit worried that this is related
to bug#55590, where I had to jump through some awkward hoops to fix a
somewhat-related issue with Eshell subcommands. I think that's due to
'eshell-do-eval' being written before lexical binding existed, and so
the variable scoping doesn't work quite as expected. It could be that
you only see this failure when using external commands due to some
differences in timing.
If that's the problem here too, it would be a pain to fix (but it would
likely also mean that this bug has been present for a long time, and my
tests/fixes have just brought it to the surface). As mentioned in
bug#55590, I think it'd be nice to rip out 'eshell-do-eval' and replace
it with the generator.el machinery, since they're conceptually pretty
similar. That's easier said than done though...
>> I did notice one weird issue though, and maybe this has something to do
>> with the problem: on MS Windows, if I run any command with a
>> $<subcommand>, the second and subsequent times, it warns me about
>> changing the temp file, e.g.:
>>
>> 3Zz80A has changed since visited or saved. Save anyway? (yes or no)
>>
>> This probably shouldn't do that, and it could definitely cause issues in
>> the tests, which can't prompt the user for things like that.
>
> I guess this means you somehow reuse the same temporary file on
> MS-Windows? Maybe change the test a bit so that the file name
> definitely differs?
I need to investigate this a bit further, since on GNU/Linux, I get a
new temp file every time. I think that's the behavior we want, or
failing that, we could at least kill the temp file's buffer after we're
done with it. I don't think there's much value in leaving it around.
next prev parent reply other threads:[~2022-08-15 18:08 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-11 2:43 bug#57129: 29.0.50; Improve behavior of conditionals in Eshell Jim Porter
2022-08-11 2:46 ` Jim Porter
2022-08-12 15:22 ` Lars Ingebrigtsen
2022-08-13 5:14 ` Jim Porter
2022-08-13 7:01 ` Eli Zaretskii
2022-08-13 18:56 ` Jim Porter
2022-08-14 5:07 ` Eli Zaretskii
2022-08-14 5:37 ` Jim Porter
2022-08-14 7:30 ` Eli Zaretskii
2022-08-14 21:40 ` Jim Porter
2022-08-15 12:13 ` Eli Zaretskii
2022-08-15 16:14 ` Jim Porter
2022-08-15 16:49 ` Eli Zaretskii
2022-08-15 18:08 ` Jim Porter [this message]
2022-08-15 18:21 ` Eli Zaretskii
2022-08-15 18:30 ` Jim Porter
2022-08-15 18:58 ` Eli Zaretskii
2022-08-15 20:55 ` Paul Eggert
[not found] ` <af0af29b-2362-77db-081e-046158937808@cs.ucla.edu>
2022-08-15 21:22 ` Bruno Haible
2022-08-16 11:04 ` Eli Zaretskii
[not found] ` <835yish2l1.fsf@gnu.org>
2022-08-16 13:35 ` Bruno Haible
[not found] ` <1871347.6tgchFWduM@nimes>
2022-08-16 13:51 ` Eli Zaretskii
[not found] ` <838rnofgad.fsf@gnu.org>
2022-08-16 14:40 ` Bruno Haible
2022-08-16 16:25 ` Eli Zaretskii
[not found] ` <83wnb8dukz.fsf@gnu.org>
2022-08-16 16:54 ` Paul Eggert
[not found] ` <206e38df-2db4-a46a-e0ff-952bc8ab939c@cs.ucla.edu>
2022-08-16 17:04 ` Eli Zaretskii
[not found] ` <83sflwdsr2.fsf@gnu.org>
2022-08-16 17:30 ` Paul Eggert
2022-08-16 17:41 ` Eli Zaretskii
[not found] ` <ceeeaa86-6199-93b1-ff65-bbd3e531e235@cs.ucla.edu>
2022-08-16 17:56 ` Eli Zaretskii
2022-08-16 17:25 ` Paul Eggert
2022-08-16 17:29 ` Bruno Haible
[not found] ` <f329244a-cba7-65cd-2e5d-2630eba3e9e9@cs.ucla.edu>
2022-08-16 17:47 ` Eli Zaretskii
2022-08-16 19:11 ` Paul Eggert
[not found] ` <d95734ab-6bbc-7403-c1f8-fbf742badda4@cs.ucla.edu>
2022-08-16 20:12 ` Bruno Haible
2022-08-17 11:08 ` Eli Zaretskii
[not found] ` <83h72bdt4z.fsf@gnu.org>
2022-08-18 6:05 ` Paul Eggert
[not found] ` <57b8f10f-8e9b-5951-e5ad-8cba2a8cb569@cs.ucla.edu>
2022-08-18 6:44 ` Eli Zaretskii
[not found] ` <2594092.Isy0gbHreE@nimes>
2022-08-16 17:52 ` Eli Zaretskii
2022-08-16 20:06 ` Bruno Haible
[not found] ` <2606289.q0ZmV6gNhb@nimes>
2022-08-17 11:29 ` Eli Zaretskii
2022-08-16 19:59 ` Bruno Haible
[not found] ` <2135151.C4sosBPzcN@nimes>
2022-08-16 20:53 ` Paul Eggert
2022-08-21 16:20 ` Bruno Haible
2022-08-21 16:32 ` Eli Zaretskii
2022-08-21 17:17 ` Bruno Haible
2022-08-22 20:47 ` Paul Eggert
[not found] ` <2dc7ede0-eca7-baf5-f89a-f5d292b80808@cs.ucla.edu>
2022-08-23 0:13 ` Bruno Haible
[not found] ` <3893771.2iPT33SAM4@nimes>
2022-08-23 11:18 ` Eli Zaretskii
[not found] ` <831qt79pjj.fsf@gnu.org>
2022-08-23 14:49 ` Bruno Haible
2022-08-23 16:07 ` Eli Zaretskii
2022-08-20 18:03 ` Jim Porter
2022-08-20 18:14 ` Eli Zaretskii
2022-08-20 18:49 ` Jim Porter
2022-08-24 21:41 ` Jim Porter
2022-08-26 5:10 ` Jim Porter
2023-03-16 5:35 ` Jim Porter
2022-08-14 5:03 ` Sean Whitton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d5cd4361-9004-efdc-2308-958296ca201f@gmail.com \
--to=jporterbugs@gmail.com \
--cc=57129@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=larsi@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.