Re: echo enhancement leads to confused legacy script tools...

Andreas Schwab [EMAIL PROTECTED] writes: There's a little history here. POSIX 1003.2-1992 said that echo has implementation-defined behavior if given any options, or if any Are you sure about any option? The current spec only talks about -n. Yes, I have the printed copy of POSIX

Autoconf test failure caused by Bash bug with { ... } unwritable

, not 0. Fix: 2007-11-02 Paul Eggert [EMAIL PROTECTED] * execute_cmd.c (execute_command_internal): Consider a redirection failure to be a failure in the last compound command. * tests/redir7.sub: Test for this bug. --- execute_cmd.c~ 2007-11-02 13:01:35.789664000

'exec /dev/null' fails if ulimit -n 6

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown'

Bash loops and otherwise mishandles long lines

Here's how to reproduce the problem: (printf 'ln ' perl -e 'print xx(2**31)' printf ' ' perl -e 'print xx(2**30)' printf '\n' ) bigscript bash bigscript On my x86-64 host, Bash loops, seemingly forever. I expect it's using a 32-bit integer to keep track of line lengths, somewhere. This bug

Re: locale specific ordering in EN_US -- why is aAbByYzZ?

On 06/28/2013 09:48 AM, Paolo Bonzini wrote: I may even agree, but the fact remains that until you fix it in glibc, you have not fixed it. As long as glibc doesn't change, there's no point in changing everything else. Unfortunately, one reason to change glibc is: Ouch! all these GNU

Bash should look at INSIDE_EMACS not just EMACS

/emacs/Interactive-Shell.html this variable is obsolescent and software is supposed to use the variable INSIDE_EMACS instead. Repeat-By: Run a future version of Emacs, which does not set EMACS, and run Bash as a subshell of it. Fix: 2015-03-30 Paul Eggert egg

Bash 4.4-rc1 incompatibility with future Emacs $EMACS

75d409f43d09d1323416db90121bc6bf54cbc3ff Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@cs.ucla.edu> Date: Fri, 8 Apr 2016 11:22:39 -0700 Subject: [PATCH] Fix compatibility problem with INSIDE_EMACS etc. The checks for deciding whether bash is being run in a GNU Emacs shell window have been t

Re: bug#54785: for floating point, printf should use double like in C instead of long double

Vincent Lefevre wrote in : $ zsh -fc '/usr/bin/printf "%a\n" $((43./2**22))' 0xa.c00025cp-20 instead of 0xa.cp-20 To summarize, this test case is: printf '%a\n' 1.0251998901367188e-05 and the problem is that converting 1.0251998901367188e-05 to long

Re: bug#65659: RFC: changing printf(1) behavior on %b

On 2023-08-31 08:35, Eric Blake wrote: Typing-wise, %#s as a synonym for %b is probably going to be easier (less shell escaping needed). Is there any interest in a patch to coreutils or bash that would add such a synonym, to make it easier to leave that functionality in place for POSIX Issue 9

test -lt inconsistent about white space

nsistent: Bash should treat trailing whitespace the same way it treats leading whitespace, and should accept all of doit's 'test' commands, as Dash does. Proposed patch attached.From bb2403a3ae6a39631777a7deea3d7f8128fff764 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 28 Oct

Re: test -lt inconsistent about white space

On 2023-10-28 18:41, Oğuz wrote: Why? The same commands fail on bosh, yash, and zsh too. I don't know what bosh is. zsh and yash prohibit trailing spaces in integers, but allow leading spaces: % test ' 3' -lt ' 4' % test ' 3 ' -lt ' 4 ' test: integer expression expected: 3

Re: test -lt inconsistent about white space

On 2023-10-29 03:18, Oğuz wrote: I think the intented behavior was skipping both leading and trailing horizontal whitespace, which makes sense as a QOL feature, and switching over to strtoimax changed this. If that's the intent, which is self-consistent but which disagrees with all other

Re: test -lt inconsistent about white space

On 2023-10-30 08:09, Chet Ramey wrote: The fact that this whitespace issue hasn't been reported since then shows how obscure it is. Yes, I noticed it only because coreutils 'test' was incompatible with Bash. (It was also incompatible with everybody else!) I recently changed bleeding-edge

Re: bug#54785: for floating point, printf should use double like in C instead of long double

On 4/25/22 11:22, Chet Ramey wrote: Thanks for the input. You're welcome. Whenever you decide what to do about this, could you please let us know? I'd like coreutils printf to stay compatible with Bash printf. Thanks.

Re: bug#54785: for floating point, printf should use double like in C instead of long double

On 4/11/22 11:52, Chet Ramey wrote: On 4/9/22 3:31 PM, Paul Eggert wrote: It sounds like there are three cases. 1. If the `L' modifier is supplied, as an extension (POSIX doesn't allow    length modifiers for the printf utility), use long double. This would    work in both default

Re: Parallelization of shell scripts for 'configure' etc.

On 6/13/22 18:25, Dale R. Worley wrote: It seems to me that bash provides the needed tools -- "( ... ) &" lets you run things in parallel. Similarly, if you've got a lot of small tasks with a complex web of dependencies, you can encode that in a "makefile". It seems to me that the heavy work

Parallelization of shell scripts for 'configure' etc.

In many Gnu projects, the 'configure' script is the biggest barrier to building because it takes s long to run. Is there some way that we could improve its performance without completely reengineering it, by improving Bash so that it can parallelize 'configure' scripts? For ideas about

Re: Parallelization of shell scripts for 'configure' etc.

On 6/14/22 18:55, Ángel wrote: Do you have any handy example of configure that takes too long to run? Sure. Coreutils, emacs. Pretty much any nontrivial configure script takes longer than it should. I understand that parallelization of shell scripts is nontrivial.

Re: Parallelization of shell scripts for 'configure' etc.

On 6/14/22 10:11, Nick Bowler wrote: The resulting config.h is correct but pa.sh took almost 1 minute to run the configure script, about ten times longer than dash takes to run the same script. More than half of that time appears to be spent just loading the program into pa.sh, before a single

Re: bug#54785: for floating point, printf should use double like in C instead of long double

On 4/29/22 13:04, Chet Ramey wrote: I think I'm going to stick with the behavior I proposed, fixing the POSIX conformance issue and preserving backwards compatibility, until I hear more about whether backwards compatibility is an issue here. Come to think of it, as far as POSIX is concerned

Re: bug#54785: for floating point, printf should use double like in C instead of long double

On 4/30/22 05:48, Vincent Lefevre wrote: Yes, but to be clear, POSIX says: shall be evaluated as if by the strtod() function if the corresponding conversion specifier is a, A, e, E, f, F, g, or G so the number should be regarded as a double-precision number (type double). Yes, but

[PATCH] Don't dump core if localtime returns NULL

* examples/loadables/stat.c (stattime): * examples/loadables/strftime.c (strftime_builtin): * lib/readline/examples/histexamp.c (main): * parse.y (decode_prompt_string): Do something reasonable if localtime returns NULL. This can happen, for example, if someone sets the system clock to such an

[PATCH] Work around GNU/Linux timestamp glitch

Without this patch, Bash can hand out user-visible timestamps that are out of order, because on GNU/Linux the 'time' function uses a different clock than file timestamps and the 'gettimeofday' function. See . * include/posixtime.h (getnow):

Re: [PATCH] Work around GNU/Linux timestamp glitch

On 3/23/23 17:51, Koichi Murase wrote: By the way, you should prepare patches based on the devel branch of Bash. Thanks for letting me know; I'll resend based on devel.

Re: Bash not portable to C23

On 3/23/23 18:23, Lawrence Velázquez wrote: On Thu, Mar 23, 2023, at 9:16 PM, Paul Eggert wrote: I see that Bash won't compile with a C23 compiler, since it still uses old-style function definitions which C23 no longer supports. Is there any effort and/or interest in fixing this portability

Bash not portable to C23

I see that Bash won't compile with a C23 compiler, since it still uses old-style function definitions which C23 no longer supports. Is there any effort and/or interest in fixing this portability problem in Bash? It's OK these days to assume C89 or later, so it's OK for Bash to switch to

[PATCH v2 2/2] Work around GNU/Linux timestamp glitch

Without this patch, Bash can hand out user-visible timestamps that are out of order, because on GNU/Linux the 'time' function uses a different clock than file timestamps and the 'gettimeofday' function. The out-of-order timestamps can lead to user-confusion.

[PATCH v2 1/2] Don't dump core if localtime returns NULL

* examples/loadables/stat.c (stattime): * examples/loadables/strftime.c (strftime_builtin): * lib/readline/examples/histexamp.c (main): * parse.y (decode_prompt_string): * support/man2html.c (print_sig): Do something reasonable if localtime returns NULL. This can happen, for example, if someone

[PATCH] Port lib/sh/tmpfile.c to hosts without mkdtemp

* lib/sh/tmpfile.c (sh_mktmpdir) [!USE_MKDTEMP]: Fix use of undeclared var 'fd'. --- lib/sh/tmpfile.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/lib/sh/tmpfile.c b/lib/sh/tmpfile.c index 18582b10..610bd3dc 100644 --- a/lib/sh/tmpfile.c +++ b/lib/sh/tmpfile.c @@

Re: Bash not portable to C23

On 2023-03-24 12:04, Chet Ramey wrote: However, Bash's devel branch still has old-style function definitions and therefore won't compile with a strict C23 compiler. For example, get_variable_value in variables.c is old-style. I assume there would be interest in fixing remaining areas where

[PATCH 3/4] Port unwind protection to C23

Do not assume that all pointers have the same representation at the machine level and that address space is linear, as the C standard does not guarantee this and it is not true on a few unusual platforms. Fixing this also uncovered a bug on conventional 64-bit platforms, where the call

[PATCH 2/4] Remove no-longer-used K cruft

Since we now assume C89 function prototypes anyway, remove no-longer-used cruft that is used only for ports to compilers requiring K style. --- aclocal.m4 | 35 + builtins/common.c | 23 ++ builtins/mkbuiltins.c | 4 ---

[PATCH 4/4] Assume __STDC__ if it merely assumes C89 or later

There's no longer any point to worrying about K compilers as the code won't work with them anyway. Simplify the code by omitting __STDC__ tests when that merely is checking for C89 or later, as we assume C89 prototypes now. --- aclocal.m4| 15 --- builtins/enable.def

[PATCH] Pacify gcc -Wpointer-to-int-cast

* lib/sh/random.c (genseed): Use a different type, to pacify GCC "warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]" on platforms with 64-bit pointers and 32-bit int. --- lib/sh/random.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 1/4] Port more functions etc. to C23

Port more function definitions and declarations to C23. This includes adding a return type when it defaulted to int. Add some casts to and from GENERIC_LIST * that are needed now that the list functions are prototyped. This does not finish the job, as some trickier functions still won't work with

Re: [PATCH 3/4] Port unwind protection to C23

On 2023-03-26 21:17, Martin D Kealey wrote: While C has never guaranteed that pointers all have the same size & alignment, POSIX does provide this guarantee, although indirectly (it has to be true for dlsym() to work, for example). My commit message was a bit misleading, as the problem is not

Re: Bash printf should diagnose integer overflow

On 3/18/24 07:40, Chet Ramey wrote: Thanks for the patches. They introduce a number of regressions, some due to the different overflow handling; several not. I urge everyone who submits non-trivial patches to run the test suite (`make tests') on their patched versions before sending them in. I

Re: Bash printf should diagnose integer overflow

On 2024-03-21 13:31, Chet Ramey wrote: Interesting. I can't reproduce this. Using the commit to which your patches apply, without applying any of them, on a fresh Virtualbox Fedora 39 install, I get consistent `make tests' output every time. I just now tried the latest devel commit

Re: Bash printf should diagnose integer overflow

s some reason a patch shouldn't be applied please let me know so that I can stop worrying about that subissue.From ccf906084c3aaf7cd75f0ee1e035986af7d58a82 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 18 Mar 2024 13:44:27 -0700 Subject: [PATCH 01/10] Improve use of HAVE_C_BOOL MIME-Ve

Re: Bash printf should diagnose integer overflow

09:33:32 -0400. From 4ca64cfc3de1d9cf75490b85891e88fbf0405538 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 13 Mar 2024 17:00:17 -0700 Subject: [PATCH 1/5] printf now diagnoses underlying printf failure * builtins/printf.def (printf_builtin): Report an error if printf returns -1, even

Bash printf should diagnose integer overflow

machinery for . These patches can be applied to Bash's devel branch (commit 54f3ed2278025081f897b9bd958fcf099fd5be18 dated Mon Mar 4 14:59:33 2024 -0500) by using the command "git am".From 1f961bac5445929dc86ca8814b94548b16034337 Mon Sep 17 00:00:00 2001 From: Pa