* bug#71446: 30.0.50; em-extpipe-test-14 fails on MS-Windows
@ 2024-06-09 5:22 Eli Zaretskii
2024-06-09 21:03 ` Jim Porter
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2024-06-09 5:22 UTC (permalink / raw)
To: 71446; +Cc: Jim Porter
The failure is as follows:
Test em-extpipe-test-14 backtrace:
signal(ert-test-failed (((should (eshell-match-output regexp)) :form
ert-fail(((should (eshell-match-output regexp)) :form (eshell-match-
(if (unwind-protect (setq value-2 (apply fn-0 args-1)) (setq form-de
(let (form-description-4) (if (unwind-protect (setq value-2 (apply f
(let ((value-2 'ert-form-evaluation-aborted-3)) (let (form-descripti
(let* ((fn-0 #'eshell-match-output) (args-1 (condition-case err (lis
(let ((ert--infos (cons (cons "Command logs: " #'eshell-get-debug-lo
eshell-match-command-output("tac *<c:/Users/EliZ/AppData/Local/Temp/
(let ((input (replace-regexp-in-string "temp\\([^>]\\|\\'\\)" temp (
(unwind-protect (let ((input (replace-regexp-in-string "temp\\([^>]\
(let ((temp-buffer (generate-new-buffer " *tmp*" t))) (unwind-protec
(progn (let ((temp-buffer (generate-new-buffer " *tmp*" t))) (unwind
(unwind-protect (progn (let ((temp-buffer (generate-new-buffer " *tm
(let* ((coding-system-for-write nil) (temp-file (identity (make-temp
(save-current-buffer (set-buffer eshell-buffer) (let* ((fn-236 #'exe
(unwind-protect (save-current-buffer (set-buffer eshell-buffer) (let
(let ((eshell-buffer (eshell t))) (unwind-protect (save-current-buff
(let ((process-environment (cons "HISTFILE" process-environment)) (e
(progn (let ((process-environment (cons "HISTFILE" process-environme
(unwind-protect (progn (let ((process-environment (cons "HISTFILE" p
(let* ((coding-system-for-write nil) (temp-file (file-name-as-direct
(save-current-buffer (let* ((coding-system-for-write nil) (temp-file
(let ((input "tac *<temp")) (save-current-buffer (let* ((coding-syst
(progn (let ((value-227 (gensym "ert-form-evaluation-aborted-"))) (l
#f(lambda () [t] (progn (let ((value-227 ...)) (let (form-descriptio
#f(compiled-function () #<bytecode -0x10ea5719bcc961a>)()
handler-bind-1(#f(compiled-function () #<bytecode -0x10ea5719bcc961a
ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
ert-run-test(#s(ert-test :name em-extpipe-test-14 :documentation nil
ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
ert-run-tests((not (or (tag :unstable) (tag :nativecomp))) #f(compil
ert-run-tests-batch((not (or (tag :unstable) (tag :nativecomp))))
ert-run-tests-batch-and-exit((not (or (tag :unstable) (tag :nativeco
eval((ert-run-tests-batch-and-exit '(not (or (tag :unstable) (tag :n
command-line-1(("-L" ";." "-l" "ert" "--eval" "(setq treesit-extra-l
command-line()
normal-top-level()
Test em-extpipe-test-14 condition:
Command logs: command: "tac *<c:/Users/EliZ/AppData/Local/Temp/emacs-test-hYLZuB-em-extpipe"
----------------------------------------
[process] started external process `cmdproxy.exe'
d\:/gnu/git/emacs/trunk/nt/cmdproxy.exe -c tac\ \<c\:/Users/EliZ/AppData/Local/Temp/emacs-test-hYLZuB-em-extpipe
----------------------------------------
[process] received output from process `cmdproxy.exe'
tac: standard input: read error
----------------------------------------
[process] sentinel for external process `cmdproxy.exe': "exited abnormally with code 1
"
----------------------------------------
[process] finished external process `cmdproxy.exe'
(ert-test-failed
((should (eshell-match-output regexp)) :form
(eshell-match-output "baz\nbar") :value nil :explanation
(mismatched-output
(command
"tac *<c:/Users/EliZ/AppData/Local/Temp/emacs-test-hYLZuB-em-extpipe\n")
(output "tac: standard input: read error\n") (regexp "baz\nbar"))))
FAILED 6/17 em-extpipe-test-14 (0.133600 sec) at lisp/eshell/em-extpipe-tests.el:180
AFAIU, the problem is that this invokes 'tac' with redirection, but
the redirected file name uses Unix-style forward slashes, which
doesn't work on Windows: the file name after "<" must use backslashes.
I tried to fix that, but the problem is that with-substitute-for-temp
is general, not specific to redirected file names, and OTOH
em-extpipe-test-14 doesn't get at the file name 'temp' until it's too
late. But maybe I' missing something in the tangled web of nested
macros?
I also don't understand all those backslashes in
d\:/gnu/git/emacs/trunk/nt/cmdproxy.exe -c tac\ \<c\:/Users/EliZ/AppData/Local/Temp/emacs-test-hYLZuB-em-extpipe
Are they real or just some artifact of printing the command? If they
are real, and included in the command line, then perhaps my analysis
is incorrect and there are more fundamental problems here.
In GNU Emacs 30.0.50 (build 1367, i686-pc-mingw32) of 2024-06-09 built
on ELIZ-PC
Windowing system distributor 'Microsoft Corp.', version 10.0.22631
System Description: Microsoft Windows 10 Enterprise (v10.0.2009.22631.3593)
Configured using:
'configure -C --prefix=/d/usr --with-wide-int
--without-native-compilation --enable-checking=yes,glyphs 'CFLAGS=-O0
-gdwarf-4 -g3''
Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES NOTIFY W32NOTIFY
PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP XPM ZLIB
Important settings:
value of $LANG: ENU
locale-coding-system: cp1252
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
minibuffer-regexp-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel dos-w32
ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads
w32notify w32 lcms2 multi-tty move-toolbar make-network-process emacs)
Memory information:
((conses 16 45257 13060) (symbols 48 6519 0) (strings 16 16057 3095)
(string-bytes 1 331106) (vectors 16 9308)
(vector-slots 8 108624 10530) (floats 8 23 6) (intervals 40 297 92)
(buffers 896 10))
^ permalink raw reply [flat|nested] 6+ messages in thread* bug#71446: 30.0.50; em-extpipe-test-14 fails on MS-Windows
2024-06-09 5:22 bug#71446: 30.0.50; em-extpipe-test-14 fails on MS-Windows Eli Zaretskii
@ 2024-06-09 21:03 ` Jim Porter
2024-06-15 9:34 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Jim Porter @ 2024-06-09 21:03 UTC (permalink / raw)
To: Eli Zaretskii, 71446; +Cc: spwhitton
On 6/8/2024 10:22 PM, Eli Zaretskii wrote:
> The failure is as follows:
[snip]
> Test em-extpipe-test-14 condition:
> Command logs: command: "tac *<c:/Users/EliZ/AppData/Local/Temp/emacs-test-hYLZuB-em-extpipe"
>
> ----------------------------------------
> [process] started external process `cmdproxy.exe'
>
> d\:/gnu/git/emacs/trunk/nt/cmdproxy.exe -c tac\ \<c\:/Users/EliZ/AppData/Local/Temp/emacs-test-hYLZuB-em-extpipe
> ----------------------------------------
> [process] received output from process `cmdproxy.exe'
>
> tac: standard input: read error
>
> ----------------------------------------
> [process] sentinel for external process `cmdproxy.exe': "exited abnormally with code 1
> "
> ----------------------------------------
> [process] finished external process `cmdproxy.exe'
[snip]
>
> AFAIU, the problem is that this invokes 'tac' with redirection, but
> the redirected file name uses Unix-style forward slashes, which
> doesn't work on Windows: the file name after "<" must use backslashes.
Are you sure? I tested on an MS-Windows system (no dev env there, but I
can run pre-built programs), and forward slashes seem ok. I ran the
following without issue inside cmd.exe:
tac <C:/Users/Jim/Documents/file.txt
cmdproxy.exe -c "tac <C:/Users/Jim/Documents/file.txt"
> I also don't understand all those backslashes in
>
> d\:/gnu/git/emacs/trunk/nt/cmdproxy.exe -c tac\ \<c\:/Users/EliZ/AppData/Local/Temp/emacs-test-hYLZuB-em-extpipe
>
> Are they real or just some artifact of printing the command? If they
> are real, and included in the command line, then perhaps my analysis
> is incorrect and there are more fundamental problems here.
Those should just be an artifact of printing the command. I've changed
that logging to use the current system's quoting style, so you should
hopefully see something like the following in the logs now:
"d:/gnu/[...]/cmdproxy.exe" "-c" "tac
<c:/[...]/emacs-test-hYLZuB-em-extpipe"
As for why it's failing, I'm not totally sure. From the logs, I think
the child process for the command is being invoked correctly, but I'm
not an expert on the extpipe code; I've CCed the author (Sean Whitton),
who might know more.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#71446: 30.0.50; em-extpipe-test-14 fails on MS-Windows
2024-06-09 21:03 ` Jim Porter
@ 2024-06-15 9:34 ` Eli Zaretskii
2024-06-15 18:47 ` Jim Porter
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2024-06-15 9:34 UTC (permalink / raw)
To: Jim Porter; +Cc: spwhitton, 71446-done
> Date: Sun, 9 Jun 2024 14:03:18 -0700
> From: Jim Porter <jporterbugs@gmail.com>
> Cc: spwhitton@spwhitton.name
>
> On 6/8/2024 10:22 PM, Eli Zaretskii wrote:
> > The failure is as follows:
> [snip]
> > Test em-extpipe-test-14 condition:
> > Command logs: command: "tac *<c:/Users/EliZ/AppData/Local/Temp/emacs-test-hYLZuB-em-extpipe"
> >
> > ----------------------------------------
> > [process] started external process `cmdproxy.exe'
> >
> > d\:/gnu/git/emacs/trunk/nt/cmdproxy.exe -c tac\ \<c\:/Users/EliZ/AppData/Local/Temp/emacs-test-hYLZuB-em-extpipe
> > ----------------------------------------
> > [process] received output from process `cmdproxy.exe'
> >
> > tac: standard input: read error
> >
> > ----------------------------------------
> > [process] sentinel for external process `cmdproxy.exe': "exited abnormally with code 1
> > "
> > ----------------------------------------
> > [process] finished external process `cmdproxy.exe'
> [snip]
> >
> > AFAIU, the problem is that this invokes 'tac' with redirection, but
> > the redirected file name uses Unix-style forward slashes, which
> > doesn't work on Windows: the file name after "<" must use backslashes.
>
> Are you sure? I tested on an MS-Windows system (no dev env there, but I
> can run pre-built programs), and forward slashes seem ok.
You are right, they've probably changed this silently in the recent
Windows versions. It definitely didn't work on Windows XP.
> I ran the
> following without issue inside cmd.exe:
>
> tac <C:/Users/Jim/Documents/file.txt
>
> cmdproxy.exe -c "tac <C:/Users/Jim/Documents/file.txt"
Yes, it works outside of Emacs, so now the problem seems to be in the
other obscure details of this test, see below.
> > I also don't understand all those backslashes in
> >
> > d\:/gnu/git/emacs/trunk/nt/cmdproxy.exe -c tac\ \<c\:/Users/EliZ/AppData/Local/Temp/emacs-test-hYLZuB-em-extpipe
> >
> > Are they real or just some artifact of printing the command? If they
> > are real, and included in the command line, then perhaps my analysis
> > is incorrect and there are more fundamental problems here.
>
> Those should just be an artifact of printing the command. I've changed
> that logging to use the current system's quoting style, so you should
> hopefully see something like the following in the logs now:
>
> "d:/gnu/[...]/cmdproxy.exe" "-c" "tac
> <c:/[...]/emacs-test-hYLZuB-em-extpipe"
I now see this:
Command logs: command: "tac *<c:/Users/EliZ/AppData/Local/Temp/emacs-test-vPFymJ-em-extpipe"
----------------------------------------
[process] started external process `cmdproxy.exe'
"d:/gnu/git/emacs/trunk/nt/cmdproxy.exe" "-c" "tac <c:/Users/EliZ/AppData/Local/Temp/emacs-test-vPFymJ-em-extpipe"
----------------------------------------
[process] received output from process `cmdproxy.exe'
tac: standard input: read error
----------------------------------------
[process] sentinel for external process `cmdproxy.exe': "exited abnormally with code 1
"
----------------------------------------
[process] finished external process `cmdproxy.exe'
So 'tac' still fails. But the problem seems to be that running the
tests invokes MSYS tac.exe; if I move it out of the way (which then
invokes the native MinGW port of 'tac'), the test passes. So I think
we can safely close this bug now.
^ permalink raw reply [flat|nested] 6+ messages in thread* bug#71446: 30.0.50; em-extpipe-test-14 fails on MS-Windows
2024-06-15 9:34 ` Eli Zaretskii
@ 2024-06-15 18:47 ` Jim Porter
2024-06-15 19:21 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Jim Porter @ 2024-06-15 18:47 UTC (permalink / raw)
To: 71446, eliz
On 6/15/2024 2:34 AM, Eli Zaretskii wrote:
> So 'tac' still fails. But the problem seems to be that running the
> tests invokes MSYS tac.exe; if I move it out of the way (which then
> invokes the native MinGW port of 'tac'), the test passes. So I think
> we can safely close this bug now.
Thanks. I wonder if there's something we could do here to support the
MSYS tac.exe, but I'm not sure what that would be.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#71446: 30.0.50; em-extpipe-test-14 fails on MS-Windows
2024-06-15 18:47 ` Jim Porter
@ 2024-06-15 19:21 ` Eli Zaretskii
2024-06-15 19:53 ` Jim Porter
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2024-06-15 19:21 UTC (permalink / raw)
To: Jim Porter; +Cc: 71446
> Date: Sat, 15 Jun 2024 11:47:46 -0700
> From: Jim Porter <jporterbugs@gmail.com>
>
> On 6/15/2024 2:34 AM, Eli Zaretskii wrote:
> > So 'tac' still fails. But the problem seems to be that running the
> > tests invokes MSYS tac.exe; if I move it out of the way (which then
> > invokes the native MinGW port of 'tac'), the test passes. So I think
> > we can safely close this bug now.
>
> Thanks. I wonder if there's something we could do here to support the
> MSYS tac.exe, but I'm not sure what that would be.
The MSYS tac works. It just somehow fails to read from redirected
file in this specific case, when invoked outside of MSYS Bash. Hmm...
Ahh, found the problem: for some reason this version of 'tac' needs
Unix EOLs in the file. So I have now fixed the test.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-06-15 19:53 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-06-09 5:22 bug#71446: 30.0.50; em-extpipe-test-14 fails on MS-Windows Eli Zaretskii
2024-06-09 21:03 ` Jim Porter
2024-06-15 9:34 ` Eli Zaretskii
2024-06-15 18:47 ` Jim Porter
2024-06-15 19:21 ` Eli Zaretskii
2024-06-15 19:53 ` Jim Porter
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.