I follow Paul Eggert's steps:
me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib
$ sh -x ./gnulib-tool --create-testdir --dir=/tmp/testdirr --verbose terminfo
+ progname=./gnulib-tool
+ func_gnulib_dir
+ case "$progname" in
++ pwd
+ self_abspathname=/e/workspace/github.com/gnu/gnulib/./gnulib-tool
+ test -h /e/workspace/github.com/gnu/gnulib/./gnulib-tool
++ echo /e/workspace/github.com/gnu/gnulib/./gnulib-tool
++ sed -e 's,/[^/]*$,,'
+ gnulib_dir=/e/workspace/github.com/gnu/gnulib/.
+ case "$GNULIB_TOOL_IMPL" in
+ exec /e/workspace/github.com/gnu/gnulib/./gnulib-tool.py
--create-testdir --dir=/tmp/testdirr --verbose terminfo
Module list with included dependencies (indented):
absolute-header
alignasof
alignasof-tests
assert-h
assert-h-tests
attribute
c-ctype
c-ctype-tests
c99
ctype
ctype-tests
extensions
extern-inline
gen-header
havelib
include_next
intprops
intprops-tests
inttypes
inttypes-incomplete
inttypes-tests
isblank
isblank-tests
limits-h
limits-h-tests
multiarch
snippet/_Noreturn
snippet/arg-nonnull
snippet/c++defs
snippet/warn-on-use
ssize_t
std-gnu11
stdbool
stdbool-tests
stddef
stddef-tests
stdint
stdint-tests
stdlib
stdlib-tests
sys_types
sys_types-tests
terminfo
terminfo-h
terminfo-tests
test-framework-sh
test-framework-sh-tests
unistd
unistd-tests
verify
verify-tests
wchar
wchar-tests
File list:
build-aux/config.rpath
lib/_Noreturn.h
lib/arg-nonnull.h
lib/assert.in.h
lib/attribute.h
lib/c++defs.h
lib/c-ctype.c
lib/c-ctype.h
lib/ctype.in.h
lib/intprops-internal.h
lib/intprops.h
lib/inttypes.in.h
lib/isblank.c
lib/limits.in.h
lib/stddef.in.h
lib/stdint.in.h
lib/stdlib.in.h
lib/sys_types.in.h
lib/terminfo.h
lib/tparm.c
lib/tputs.c
lib/unistd.c
lib/unistd.in.h
lib/verify.h
lib/warn-on-use.h
lib/wchar.in.h
m4/00gnulib.m4
m4/absolute-header.m4
m4/assert_h.m4
m4/c-bool.m4
m4/codeset.m4
m4/ctype_h.m4
m4/curses.m4
m4/extensions.m4
m4/extern-inline.m4
m4/gnulib-common.m4
m4/host-cpu-c-abi.m4
m4/include_next.m4
m4/inttypes.m4
m4/isblank.m4
m4/lib-ld.m4
m4/lib-link.m4
m4/lib-prefix.m4
m4/limits-h.m4
m4/locale-fr.m4
m4/multiarch.m4
m4/off64_t.m4
m4/off_t.m4
m4/pid_t.m4
m4/ssize_t.m4
m4/std-gnu11.m4
m4/stdalign.m4
m4/stddef_h.m4
m4/stdint.m4
m4/stdlib_h.m4
m4/sys_types_h.m4
m4/terminfo.m4
m4/unistd_h.m4
m4/warn-on-use.m4
m4/wchar_h.m4
m4/wchar_t.m4
m4/wint_t.m4
m4/zzgnulib.m4
tests/init.sh
tests/macros.h
tests/signature.h
tests/test-alignasof.c
tests/test-assert.c
tests/test-c-ctype.c
tests/test-ctype.c
tests/test-init.sh
tests/test-intprops.c
tests/test-inttypes.c
tests/test-isblank.c
tests/test-limits-h.c
tests/test-stdbool.c
tests/test-stddef.c
tests/test-stdint.c
tests/test-stdlib.c
tests/test-sys_types.c
tests/test-sys_wait.h
tests/test-terminfo.c
tests/test-unistd.c
tests/test-verify-try.c
tests/test-verify.c
tests/test-verify.sh
tests/test-wchar.c
executing aclocal -I glm4
executing autoconf
executing autoheader
executing touch config.h.in
executing automake --add-missing --copyconfigure.ac:8: installing
'build-aux/compile'configure.ac:4: installing
'build-aux/install-sh'configure.ac:4: installing 'build-aux/missing'
gllib/Makefile.am: installing 'build-aux/depcomp'
executing aclocal -I ../glm4
executing autoconf
executing autoheader
executing touch config.h.in
executing automake --add-missing --copy
parallel-tests: installing '../build-aux/test-driver'
patching file build-aux/test-driver
/e/workspace/github.com/gnu/gnulib/gnulib-tool.py: *** could not patch
test-driver script
/e/workspace/github.com/gnu/gnulib/gnulib-tool.py: *** Stop.
*could not patch test-driver script*, so crazy, I am very painful, friends,
do you know?
On Thu, Jul 4, 2024 at 7:38 PM Paul Eggert <egg...@cs.ucla.edu> wrote:
> On 7/4/24 09:17, Collin Funk wrote:
> > As long as a
> > Python version ≥ 3.7 is installed everything should be fine on that
> > end:
>
> Yes, though sometimes Python is misinstalled.
>
> When I run "sh -x ./gnulib-tool --list", the last thing it does is:
>
> exec /home/eggert/src/gnu/gnulib/./gnulib-tool.py --list
>
> and when I run "sh -x /home/eggert/src/gnu/gnulib/./gnulib-tool.py
> --list", the last thing it does is:
>
> exec python3 /home/eggert/src/gnu/gnulib-savannah/./.gnulib-tool.py --list
>
> so there should be not much going on other than running Python. Perhaps
> the bug reporter could try running these "sh -x" commands and letting is
> know what happens.
>
>
> PS. There's a lot of machinery in those shell scripts for the minor
> benefit of letting gnulib-tool be a symlink in your $PATH to the real
> gnulib-tool. How about if we drop support for this? That'd simplify
> startup quite a bit (if we're lucky it'll even fix the reporter's bug or
> at least make it easier to diagnose), and there is a better way to get
> the benefits of that minor feature that doesn't involve so much
> problematic shell rigamarole.
>
> Something like the attached patch, perhaps? I haven't installed it.
>
>
> PPS. Why do we have both gnulib-tool.py and .gnulib-tool.py? Is this
> commented in the source code?
