Subject: Re: bug#62578: 30.0.50; [PATCH] Add regression tests for synchronous processes in Eshell

From: Jim Porter <[email-masked]>
Date: Sat, 1 Apr 2023 00:16:38 -0700

On 3/31/2023 11:07 PM, Eli Zaretskii wrote:
>> Date: Fri, 31 Mar 2023 21:41:09 -0700
>> From: Jim Porter <[email-masked]>
>>
>> +(ert-deftest esh-proc-test/synchronous-proc/simple/interactive ()
>> +  "Test that synchronous processes work in an interactive shell."
>> +  (skip-unless (executable-find "echo"))
> 
> This will always skip on MS-DOS, since "echo" is not available as an
> external program OOTB, only if GNU Coreutils are installed.  And even
> if Coreutils _are_ installed, a command that invokes "echo" will most
> probably invoke the shell builtin instead.

My main goal here is to test synchronous subprocesses on platforms 
*other than* MS-DOS, since these new tests aren't really necessary on 
MS-DOS itself: there are plenty of existing Eshell tests that create 
processes, and they'd *all* use synchronous subprocesses on MS-DOS.

As for calling a shell builtin, Eshell should translate "*echo" to 
"/path/to/echo" (or "C:/path/to/echo.exe") before calling it, so it 
shouldn't use a shell builtin here. You're right though that the tests 
probably require GNU Coreutils to be installed (this is also true of 
quite a few existing Eshell tests though).

>> +  (skip-unless (and (executable-find "echo")
>> +                    (executable-find "rev")))
> 
> Likewise here: "rev" is not expected to be available on MS-DOS.

To make this work in more places, I could switch "rev" to something 
that's actually in GNU Coreutils. Maybe "wc".

> I think you need to rethink these tests in a way that uses different
> commands.  My suggestion is to use the Emacs executable, since that is
> always available when running these tests.

Since these tests are meant to check the "synchronous subprocess" code 
in Eshell on non-MS-DOS platforms, I'd say it's ok. However, I can 
change my patch if you prefer. I could either:

1) Add a comment to the tests explaining that they're just meant to 
simulate some of MS-DOS's limitations on non-MS-DOS systems, or

2) Rework these tests so they work the same on both MS-DOS and other 
systems.

Personally, I lean softly towards (1), partly because the Eshell test 
suite probably breaks in quite a few other places on MS-DOS anyway. 
However, it shouldn't be too hard to do (2) instead.

What do you think?