[PATCH] Makefile.in: add missing intl dependency for unwind_prot.o
As reported by Robert Scott in https://github.com/NixOS/nixpkgs/pull/245066
without the change `make -j8` build of `make` occasionally fails to
buildin parallel. The simplest reproducer is:
$$ ./configure
$$ make unwind_prot.o
...
In file included from unwind_prot.c:51:
In file included from ./bashintl.h:30:
./include/gettext.h:27:11: fatal error: 'libintl.h' file not found
# include
^~~
1 error generated.
make: *** [Makefile:106: unwind_prot.o] Error 1
The change adds missing ttransitive `${LIBINTL_H}` dependency for
unwind_prot.o.
---
Makefile.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile.in b/Makefile.in
index 0b4df73a..15edc389 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -1432,6 +1432,7 @@ siglist.o: bashintl.h ${LIBINTL_H} $(BASHINCDIR)/gettext.h
subst.o: bashintl.h ${LIBINTL_H} $(BASHINCDIR)/gettext.h
test.o: bashintl.h ${LIBINTL_H} $(BASHINCDIR)/gettext.h
trap.o: bashintl.h ${LIBINTL_H} $(BASHINCDIR)/gettext.h
+unwind_prot.o: bashintl.h ${LIBINTL_H} $(BASHINCDIR)/gettext.h
variables.o: bashintl.h ${LIBINTL_H} $(BASHINCDIR)/gettext.h
version.o: bashintl.h ${LIBINTL_H} $(BASHINCDIR)/gettext.h
xmalloc.o: bashintl.h ${LIBINTL_H} $(BASHINCDIR)/gettext.h
--
2.41.0
Re: slash appended to tab so its two // at end
On 7/24/23 2:57 PM, alex xmb ratchev wrote: partly cosmetic its not foo/ and foo/// will yield different paths Completely cosmetic. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: slash appended to tab so its two // at end
On Mon, Jul 24, 2023, 7:30 PM Chet Ramey wrote: > On 7/19/23 1:44 PM, Grisha Levit wrote: > > On Wed, Jul 19, 2023 at 12:57 PM Grisha Levit > wrote: > >> Also I think this is not a bug -- readline is asked to append a slash > >> to directory names and it does so. > > > > It's easy enough to avoid printing the indicator slash if we just > > printed a path already ending in a slash. It's an improvement > > cosmetically but I think correctness can be argued either way. > > It's cosmetic only. Multiple non-leading slashes in a pathname are > equivalent to a single slash. The only exception is when there are > exactly two leading slashes. > partly cosmetic its not foo/ and foo/// will yield different paths i just found it plain .. under the level .. btw i didnt get the begin slashes story greets https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_271 > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ > >
Re: [PATCH] fix bind -X quoting
On Mon, Jul 24, 2023, 7:13 PM Chet Ramey wrote: > On 7/19/23 12:47 PM, Grisha Levit wrote: > > On Wed, Jul 19, 2023 at 10:47 AM Chet Ramey wrote: > >> Thanks for the report. It seems like your patch is incomplete, though. > >> After applying it: > >> > >> $ bind -x '"\eX": echo "x"' > >> $ bind -X > >> "\eX": "echo "x"" > >> > >> We probably need to suppress printing the double quotes around `out' if > >> print_readably < 0. > > > > Oh good point. I guess we'd need to also print a backslash if the > > first character of the command is a quote. > > Quoted command lines are tricky. Like a regular readline key binding, a > command name that starts with a double quote is assumed to be a single > double-quoted string (like any other macro), where the double quotes get > stripped before calling rl_generic_bind. Practically, this means that you > can -- and have historically been able to -- run > > bind -x '"\eX": "echo x y z"' > > and have `echo x y z' executed when you type M-X. > > Not only does this not permit quoted command names with arguments, you have > to detect the difference between a quoted string and a quoted command name > after all that information has been lost. Changing this means backwards- > incompatible changes to bind_keyseq_to_unix_command. > > You could do it if you allowed, say > > bind -x '"\eX": \"command with spaces\" \"x\"' > in my shell awk coding story , thers the quotes to get escquoted escape_deep_level deep i d wanna see such a helper function opt1 quote types opt2 if to surround string arg/s with quoted , and mainopt3 escape " ( in this case ) defaultly 1 deep but variable .. the higher the deep level number is , the more backslashes and whatever valid will appear .. basic code gen function and then stripped the backslashes before calling rl_generic_bind, but > that's not exactly backwards compatible either. > > And since the bash code parses the command like you passed it to `eval', > you can't have readline quoting double-quotes in the command string with > backslashes. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ > > >
Re: slash appended to tab so its two // at end
On 7/19/23 1:44 PM, Grisha Levit wrote: On Wed, Jul 19, 2023 at 12:57 PM Grisha Levit wrote: Also I think this is not a bug -- readline is asked to append a slash to directory names and it does so. It's easy enough to avoid printing the indicator slash if we just printed a path already ending in a slash. It's an improvement cosmetically but I think correctness can be argued either way. It's cosmetic only. Multiple non-leading slashes in a pathname are equivalent to a single slash. The only exception is when there are exactly two leading slashes. https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_271 -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: segfault in for(()) loop
On 7/24/23 11:58 AM, vc--- via Bug reports for the GNU Bourne Again SHell wrote: Bash Version: 5.2 Patch Level: 15 Release Status: release Description: Segmentation fault in 'for ((...))' loop Repeat-By: z='';for((;$z;));do echo;done without spaces in ;$z; in bash 5.1.4 -- works ok, in bash 5.2.15 -- segmentation fault Thanks for the report. This was fixed several months ago. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [PATCH] fix bind -X quoting
On 7/19/23 12:47 PM, Grisha Levit wrote: On Wed, Jul 19, 2023 at 10:47 AM Chet Ramey wrote: Thanks for the report. It seems like your patch is incomplete, though. After applying it: $ bind -x '"\eX": echo "x"' $ bind -X "\eX": "echo "x"" We probably need to suppress printing the double quotes around `out' if print_readably < 0. Oh good point. I guess we'd need to also print a backslash if the first character of the command is a quote. Quoted command lines are tricky. Like a regular readline key binding, a command name that starts with a double quote is assumed to be a single double-quoted string (like any other macro), where the double quotes get stripped before calling rl_generic_bind. Practically, this means that you can -- and have historically been able to -- run bind -x '"\eX": "echo x y z"' and have `echo x y z' executed when you type M-X. Not only does this not permit quoted command names with arguments, you have to detect the difference between a quoted string and a quoted command name after all that information has been lost. Changing this means backwards- incompatible changes to bind_keyseq_to_unix_command. You could do it if you allowed, say bind -x '"\eX": \"command with spaces\" \"x\"' and then stripped the backslashes before calling rl_generic_bind, but that's not exactly backwards compatible either. And since the bash code parses the command like you passed it to `eval', you can't have readline quoting double-quotes in the command string with backslashes. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
segfault in for(()) loop
Configuration Information [Automatically generated, do not change]: Machine: amd64 OS: freebsd13.1 Compiler: cc Compilation CFLAGS: -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing uname output: FreeBSD delta.hostmaster.ua 13.1-RELEASE-p5 FreeBSD 13.1-RELEASE-p5 #0 releng/13.1-753d65a19-dirty: Wed Feb 1 23:24:16 EET 2023 b...@canada.hostmaster.ua:/usr/obj/usr/src/amd64.amd64/sys/CUSTOM amd64 Machine Type: amd64-portbld-freebsd13.1 Bash Version: 5.2 Patch Level: 15 Release Status: release Description: Segmentation fault in 'for ((...))' loop Repeat-By: z='';for((;$z;));do echo;done without spaces in ;$z; in bash 5.1.4 -- works ok, in bash 5.2.15 -- segmentation fault
Re: fg tcsetpgrp() SIGTTIN/SIGTTOU race
On 7/18/23 11:50 PM, Earl Chew wrote: Interestingly dash/ash does not exhibit this behaviour. Looking at the implementation since 1994 shows that it issues SIGCONT unconditionally after TIOCSPGRP: https://svnweb.freebsd.org/base/head/bin/sh/jobs.c?revision=1556&view=markup#l175 https://svnweb.freebsd.org/base/head/bin/sh/jobs.c?revision=1556&view=markup#l207 The prior art suggested by dash/ash is that bash should send SIGCONT unconditionally after tcsetpgrp() when moving a program to the foreground. Thanks for the report. Let's try it, since sending SIGCONT to a process should not have any negative side effects. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [Documentation] Parameter expansion: missing colon in example
On 7/21/23 2:37 PM, private--- via Bug reports for the GNU Bourne Again
SHell wrote:
Hello,
The example on parameter expansion[1] should perhaps read :
$ echo ${v:-unset}
instead of :
$ echo ${v-unset}
There should probably be more examples showing the differences between the
- and :- operators with different values of v, so I'll add some.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [PATCH] normalization tweaks for macOS
On 7/20/23 7:52 PM, Grisha Levit wrote: I wonder if you'd be interested in changes to the function that would skip escaping ASCII characters that aren't glob-special as well. I _think_ it would just be a slight variation of the code that already does this for regexes but I haven't thought about the edge cases carefully yet. I agree that it would only be a slight variation on that code, and so I added that case. It will be in the next devel branch push. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
