Botched assertion in malloc]

[paul]

CConfiguration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: i386-redhat-linux-gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' 
-DCONF_VENDOR='redhat' -DSHELL -DHAVE_CONFIG_H  -I.  -I. -I./include -I./lib 
-D_GNU_SOURCE  -O2 -g -pipe -march=i386 -mcpu=i686
uname output: Linux bat 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 athlon 
i386 GNU/Linux
Machine Type: i386-redhat-linux-gnu

Bash Version: 2.05b
Patch Level: 0
Release Status: release

Description:
[Detailed description of the problem, suggestion, or complaint.]

malloc: stringvec.c:188: assertion botched
malloc: block on free list clobbered
Stopping myself...-bash: [: =: unary operator expected


Repeat-By:

Logging in via SSH



___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Command substitution fails in here-document delimiter.

[Paul Gilmartin]

bbug1
Description: Binary data

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

[Paul Eggert]

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 double 
prints the too-precise "0xa.c00025cp-20", whereas you want it to 
convert to double (which matches what most other programs do) and to 
print "0xa.cp-20" or equivalent.



(Note that ksh uses long double internally, but does not ensure the
round trip back to long double


Yes, ksh messes up here. However, it's more important for Coreutils 
printf to be compatible with the GNU shell, and Bash uses long double:


$ echo $BASH_VERSION
5.1.8(1)-release
$ /usr/bin/printf --version | head -n1
printf (GNU coreutils) 8.32
$ printf '%a\n' 1.0251998901367188e-05
0xa.c00025cp-20
$ /usr/bin/printf '%a\n' 1.0251998901367188e-05
0xa.c00025cp-20



I suggest to parse the argument as a "long double" only if the "L"
length modifier is provided, like in C.

Thanks, good idea.

I checked, and this also appears to be a POSIX conformance issue. POSIX 
 says that floating point operands "shall be evaluated as if by the 
strtod() function". This means double, not long double.


Whatever decision we make here, we should be consistent with Bash so 
I'll cc this email to bug-bash.


I propose that we change both coreutils and Bash to use 'double' rather 
than 'long double' here, unless the user specifies the L modifier (e.g., 
"printf '%La\n' ...". I've written up a patch (attached) to Bash 5.2 
alpha to do that. Assuming the Bash maintainer likes this proposal, I 
plan to implement something similar for Coreutils printf.diff '-x*~' -pru bash-5.2-alpha/builtins/printf.def bash-5.2-alpha-double/builtins/printf.def
--- bash-5.2-alpha/builtins/printf.def	2021-12-29 13:09:20.0 -0800
+++ bash-5.2-alpha-double/builtins/printf.def	2022-04-09 12:02:35.330476097 -0700
@@ -215,13 +215,14 @@ static uintmax_t getuintmax PARAMS((void
 
 #if defined (HAVE_LONG_DOUBLE) && HAVE_DECL_STRTOLD && !defined(STRTOLD_BROKEN)
 typedef long double floatmax_t;
-#  define FLOATMAX_CONV	"L"
+#  define USE_LONG_DOUBLE 1
 #  define strtofltmax	strtold
 #else
 typedef double floatmax_t;
-#  define FLOATMAX_CONV	""
+#  define USE_LONG_DOUBLE 0
 #  define strtofltmax	strtod
 #endif
+static double getdouble PARAMS((void));
 static floatmax_t getfloatmax PARAMS((void));
 
 static intmax_t asciicode PARAMS((void));
@@ -247,7 +248,7 @@ printf_builtin (list)
  WORD_LIST *list;
 {
   int ch, fieldwidth, precision;
-  int have_fieldwidth, have_precision;
+  int have_fieldwidth, have_precision, use_Lmod;
   char convch, thisch, nextch, *format, *modstart, *precstart, *fmt, *start;
 #if defined (HANDLE_MULTIBYTE)
   char mbch[25];		/* 25 > MB_LEN_MAX, plus can handle 4-byte UTF-8 and large Unicode characters*/
@@ -422,8 +423,12 @@ printf_builtin (list)
 
 	  /* skip possible format modifiers */
 	  modstart = fmt;
+	  use_Lmod = 0;
 	  while (*fmt && strchr (LENMODS, *fmt))
-	fmt++;
+	{
+	  use_Lmod |= USE_LONG_DOUBLE && *fmt == 'L';
+	  fmt++;
+	}
 	
 	  if (*fmt == 0)
 	{
@@ -694,11 +699,24 @@ printf_builtin (list)
 #endif
 	  {
 		char *f;
-		floatmax_t p;
 
-		p = getfloatmax ();
-		f = mklong (start, FLOATMAX_CONV, sizeof(FLOATMAX_CONV) - 1);
-		PF (f, p);
+		if (use_Lmod)
+		  {
+		floatmax_t p;
+
+		p = getfloatmax ();
+		f = mklong (start, "L", 1);
+		PF (f, p);
+		  }
+		else
+		  {
+		double p;
+
+		p = getdouble ();
+		f = mklong (start, "", 0);
+		PF (f, p);
+		  }
+
 		break;
 	  }
 
@@ -1248,35 +1266,40 @@ getuintmax ()
   return (ret);
 }
 
+#define getfloat(ret, convert) \
+  char *ep; \
+  if (garglist == 0) \
+return 0; \
+  if (garglist->word->word[0] == '\'' || garglist->word->word[0] == '"') \
+return asciicode (); \
+  errno = 0; \
+  (ret) = (convert) (garglist->word->word, &ep); \
+  if (*ep) \
+{ \
+  sh_invalidnum (garglist->word->word); \
+  /* Same thing about POSIX.2 conversion error requirements. */ \
+  if (0) \
+(ret) = 0; \
+  conversion_error = 1; \
+} \
+  else if (errno == ERANGE) \
+printf_erange (garglist->word->word); \
+  garglist = garglist->next
+
+static double
+getdouble ()
+{
+  double ret;
+  getfloat (ret, strtod);
+  return ret;
+}
+
 static floatmax_t
 getfloatmax ()
 {
   floatmax_t ret;
-  char *ep;
-
-  if (garglist == 0)
-return (0);
-
-  if (garglist->word->word[0] == '\'' || garglist->word->word[0] == '"')
-return asciicode ();
-
-  errno = 0;
-  ret = strtofltmax (garglist->word->word, &ep);
-
-  if (*ep)
-{
-  sh_invalidnum (garglist->word->word);
-#if 0
-  /* Same thing about POSIX.2 conversion error requirements. */
-  ret = 0;
-#endif
-  conversion_error = 1;
-}
-  else if (errno == ERANGE)
-printf_erange (garglist->word->word);
-
-  ga

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

[Paul Eggert]

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 and posix modes.

2. In posix mode, use strtod() and double.

3. In default mode, use the existing code to get the highest possible
    precision, as the code has done for over 20 years.


That'll fix the POSIX compatibility bug. However, it may be better for 
Bash to just do (1) if 'L' is supplied and (2) otherwise, even if this 
is less precise than (3). Doing it this simpler way will likely be more 
useful for the small number of people who care whether 'printf' uses 
'double' or 'long double' internally (and nobody else will care).


Doing it this way is what BSD sh does, and it's good to be compatible 
with BSD sh. Similarly for dash and for other shells.


It's also what other GNU programs do. For example, on x86-64:

  $ awk 'BEGIN {printf "%.100g\n", 0.1}'
  0.155511151231257827021181583404541015625
  $ emacs -batch -eval '(message "%.100g" 0.1)'
  0.155511151231257827021181583404541015625
  $ printf "%.100g\n" 0.1
  0.100013552527156068805425093160010874271392822265625

printf is the outlier here, and although its answer is closer to the 
mathematical value, that's not as useful as being closer to what most 
other apps do.


Perhaps it was OK for sh printf to use long double 20 years ago. I even 
had a hand in implementing that.[1] But nowadays it feels like a 
misfire. The overwhelming majority of apps that have developed over the 
past 20 years that use newer languages like JavaScript and Java, do not 
support 'long double'; when interoperating with these apps, using 'long 
double' in Bash printf likely causes more trouble than it cures.


[1]: 
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=830de2708207b7e48464e4778b55e582bac49832

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

[Paul Eggert]

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

[Paul Eggert]

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 Bash doesn't need to 
change what it does. POSIX doesn't require that the shelll printf 
command be compiled with any particular environment. It would conform to 
POSIX, for example, if Bash's printf were compiled with an IBM floating 
point implementation rather than with an IEEE floating point 
implementation, so long as Bash's printf parses floating-point strings 
the way strtod is supposed to parse strings on an IBM mainframe. 
Similarly, Bash's printf can use an 80-bit floating point format if 
available; it will still conform to POSIX.


So this isn't a POSIX conformance issue; only a compatibility issue. Is 
it more important for the Bash printf to behave like most other shells 
and other programs, or is it more important for Bash printf to behave 
like it has for the last 18 years or so?

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

[Paul Eggert]

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 POSIX does not require the C type 'double' and the C function 
strtod to be implemented via IEEE-754 64-bit floating point. POSIX 
allows 'double' and 'strtod' to be implemented via x86-64 
extended-precision (80-bit) floating point, or by any other 
floating-point type that satisfies some (weak) properties. I see no 
requirement that the shell must be implemented as if by the standard c99 
command with the default options.


The POSIX requirements on the implementation of 'double' and 'strtod' 
are so lax that Bash 'printf' could even use IEEE-754 32-bit floating 
point, if it wanted to. One could build Bash with 'gcc -mlong-double=32 
-mdouble=32' assuming these options work, and the result would conform 
to POSIX. (Not that I'm suggesting this!)




Concerning the compatibility, the question is: with what?


I agree that it'd be a net win for Bash to use plain 'double' here; your 
discussion of the various compatibility plusses of doing that is 
compelling to me.

Parallelization of shell scripts for 'configure' etc.

[Paul Eggert]

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 this, please see PaSh-JIT:

Kallas K, Mustafa T, Bielak J, Karnikis D, Dang THY, Greenberg M, 
Vasilakis N. Practically correct, just-in-time shell script 
parallelization. Proc OSDI 22. July 2022. 
https://nikos.vasilak.is/p/pash:osdi:2022.pdf


I've wanted something like this for *years* (I assigned a simpler 
version to my undergraduates but of course it was too much to expect 
them to implement it) and I hope some sort of parallelization like this 
can get into production with Bash at some point (or some other shell if 
Bash can't use this idea).

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

[Paul Eggert]

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 is rebuilding how "configure" scripts
are constructed based on which items can be run in parallel.


Yes, all that could be done in theory, but it'd take a lot of hacking 
and it's been decades and it hasn't happened.


I'd rather have shell scripts "just work" in parallel with a minimum of 
fuss.

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

[Paul Eggert]

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 shell command is
actually executed.


Ouch. Thanks for looking into this, and sorry it took so much of your 
time. It appears that PaSh itself isn't suitable for prime-time use. 
This isn't too surprising, though, as it's a research project and I 
wouldn't expect it to compete with production shells. The main question 
here is whether the ideas of PaSh are good ones for improving Bash.

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

[Paul Eggert]

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.

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

[Paul Eggert]

* 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 absurdly high value so that tm_year cannot
represent the year, and localtime returns NULL with
errno == EOVERFLOW.
---
 examples/loadables/stat.c |  2 ++
 examples/loadables/strftime.c |  7 ++
 lib/readline/examples/histexamp.c |  6 +++--
 parse.y   | 40 ++-
 4 files changed, 42 insertions(+), 13 deletions(-)

diff --git a/examples/loadables/stat.c b/examples/loadables/stat.c
index 1e60e7b6..cc722c05 100644
--- a/examples/loadables/stat.c
+++ b/examples/loadables/stat.c
@@ -271,6 +271,8 @@ stattime (t, timefmt)
 
   fmt = timefmt ? timefmt : DEFTIMEFMT;
   tm = localtime (&t);
+  if (!tm)
+return itos (t);
 
   ret = xmalloc (TIMELEN_MAX);
 
diff --git a/examples/loadables/strftime.c b/examples/loadables/strftime.c
index f4e194e6..656ecdeb 100644
--- a/examples/loadables/strftime.c
+++ b/examples/loadables/strftime.c
@@ -81,6 +81,13 @@ strftime_builtin (list)
 secs = NOW;
 
   t = localtime (&secs);
+  if (!t)
+{
+  builtin_error ("%s: %s",
+list && list->word->word ? list->word->word : "now",
+_("timestamp out of range"));
+  return (EXECUTION_FAILURE);
+}
 
   tbsize = strlen (format) * 4;
   tbuf = 0;
diff --git a/lib/readline/examples/histexamp.c 
b/lib/readline/examples/histexamp.c
index 309d769b..b321dd0b 100644
--- a/lib/readline/examples/histexamp.c
+++ b/lib/readline/examples/histexamp.c
@@ -97,9 +97,11 @@ main (argc, argv)
  if (the_list)
for (i = 0; the_list[i]; i++)
  {
+   struct tm *tm;
tt = history_get_time (the_list[i]);
-   if (tt)
- strftime (timestr, sizeof (timestr), "%a %R", localtime(&tt));
+   tm = tt ? localtime (&tt) : 0;
+   if (tm)
+ strftime (timestr, sizeof (timestr), "%a %R", tm);
else
  strcpy (timestr, "??");
printf ("%d: %s: %s\n", i + history_base, timestr, 
the_list[i]->line);
diff --git a/parse.y b/parse.y
index 1d12e639..1d188101 100644
--- a/parse.y
+++ b/parse.y
@@ -5775,7 +5775,12 @@ decode_prompt_string (string)
 #endif
  tm = localtime (&the_time);
 
- if (c == 'd')
+ if (!tm)
+   {
+ strcpy (timebuf, "??");
+ n = 2;
+   }
+ else if (c == 'd')
n = strftime (timebuf, sizeof (timebuf), "%a %b %d", tm);
  else if (c == 't')
n = strftime (timebuf, sizeof (timebuf), "%H:%M:%S", tm);
@@ -5801,19 +5806,32 @@ decode_prompt_string (string)
  (void) time (&the_time);
  tm = localtime (&the_time);
  string += 2;  /* skip { */
- timefmt = xmalloc (strlen (string) + 3);
- for (t = timefmt; *string && *string != '}'; )
-   *t++ = *string++;
- *t = '\0';
+ t = string;
+ while (*string && *string != '}')
+   string++;
  c = *string;  /* tested at add_string */
- if (timefmt[0] == '\0')
+ 
+ if (tm)
+   {
+ size_t timefmtlen = string - t;
+ timefmt = xmalloc (timefmtlen + 3);
+ memcpy (timefmt, t, timefmtlen);
+ timefmt[timefmtlen] = '\0';
+ 
+ if (timefmt[0] == '\0')
+   {
+ timefmt[0] = '%';
+ timefmt[1] = 'X'; /* locale-specific current time */
+ timefmt[2] = '\0';
+   }
+ n = strftime (timebuf, sizeof (timebuf), timefmt, tm);
+ free (timefmt);
+   }
+ else
{
- timefmt[0] = '%';
- timefmt[1] = 'X'; /* locale-specific current time */
- timefmt[2] = '\0';
+ strcpy (timebuf, "??");
+ n = 2;
}
- n = strftime (timebuf, sizeof (timebuf), timefmt, tm);
- free (timefmt);
 
  if (n == 0)
timebuf[0] = '\0';
-- 
2.39.2

[PATCH] Work around GNU/Linux timestamp glitch

[Paul Eggert]

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): New function.
All calls to 'time' changed to use this function.
* support/man2html.c (print_sig): Prefer gettimeofday if available.

(This patch assumes my recent patch proposed for localtime
.)
---
 general.h|  2 +-
 include/posixtime.h  | 10 ++
 lib/readline/history.c   |  4 +++-
 lib/readline/posixtime.h | 10 ++
 parse.y  |  6 +++---
 support/man2html.c   |  8 +++-
 6 files changed, 34 insertions(+), 6 deletions(-)

diff --git a/general.h b/general.h
index 8064c50e..9b082cbc 100644
--- a/general.h
+++ b/general.h
@@ -245,7 +245,7 @@ typedef int sh_builtin_func_t PARAMS((WORD_LIST *)); /* 
sh_wlist_func_t */
 
 #endif /* SH_FUNCTION_TYPEDEF */
 
-#define NOW((time_t) time ((time_t *) 0))
+#define NOWgetnow ()
 #define GETTIME(tv)gettimeofday(&(tv), NULL)
 
 /* Some defines for calling file status functions. */
diff --git a/include/posixtime.h b/include/posixtime.h
index e70ebec6..a7b2957a 100644
--- a/include/posixtime.h
+++ b/include/posixtime.h
@@ -52,6 +52,16 @@ struct timeval
 extern int gettimeofday PARAMS((struct timeval *, void *));
 #endif
 
+static inline time_t
+getnow (void)
+{
+  /* Avoid time (NULL), which can disagree with gettimeofday and with
+ filesystem timestamps.  */
+  struct timeval now;
+  gettimeofday (&now, 0);
+  return now.tv_sec;
+}
+
 /* These exist on BSD systems, at least. */
 #if !defined (timerclear)
 #  define timerclear(tvp)  do { (tvp)->tv_sec = 0; (tvp)->tv_usec = 0; } 
while (0)
diff --git a/lib/readline/history.c b/lib/readline/history.c
index 81d4c168..d141e942 100644
--- a/lib/readline/history.c
+++ b/lib/readline/history.c
@@ -48,6 +48,7 @@
 #include "history.h"
 #include "histlib.h"
 
+#include "posixtime.h"
 #include "xmalloc.h"
 
 #if !defined (errno)
@@ -261,7 +262,8 @@ hist_inittime (void)
   time_t t;
   char ts[64], *ret;
 
-  t = (time_t) time ((time_t *)0);
+  t = getnow ();
+
 #if defined (HAVE_VSNPRINTF)   /* assume snprintf if vsnprintf exists 
*/
   snprintf (ts, sizeof (ts) - 1, "X%lu", (unsigned long) t);
 #else
diff --git a/lib/readline/posixtime.h b/lib/readline/posixtime.h
index e70ebec6..a7b2957a 100644
--- a/lib/readline/posixtime.h
+++ b/lib/readline/posixtime.h
@@ -52,6 +52,16 @@ struct timeval
 extern int gettimeofday PARAMS((struct timeval *, void *));
 #endif
 
+static inline time_t
+getnow (void)
+{
+  /* Avoid time (NULL), which can disagree with gettimeofday and with
+ filesystem timestamps.  */
+  struct timeval now;
+  gettimeofday (&now, 0);
+  return now.tv_sec;
+}
+
 /* These exist on BSD systems, at least. */
 #if !defined (timerclear)
 #  define timerclear(tvp)  do { (tvp)->tv_sec = 0; (tvp)->tv_usec = 0; } 
while (0)
diff --git a/parse.y b/parse.y
index 1d188101..6f9c626f 100644
--- a/parse.y
+++ b/parse.y
@@ -84,7 +84,7 @@ typedef void *alias_t;
 #  ifndef _MINIX
 #include 
 #  endif
-#  include 
+#  include "posixtime.h"
 #  if defined (TM_IN_SYS_TIME)
 #include 
 #include 
@@ -5769,7 +5769,7 @@ decode_prompt_string (string)
case '@':
case 'A':
  /* Make the current time/date into a string. */
- (void) time (&the_time);
+ the_time = getnow ();
 #if defined (HAVE_TZSET)
  sv_tz ("TZ"); /* XXX -- just make sure */
 #endif
@@ -5803,7 +5803,7 @@ decode_prompt_string (string)
  if (string[1] != '{') /* } */
goto not_escape;
 
- (void) time (&the_time);
+ the_time = getnow ();
  tm = localtime (&the_time);
  string += 2;  /* skip { */
  t = string;
diff --git a/support/man2html.c b/support/man2html.c
index e6f441b4..6f552388 100644
--- a/support/man2html.c
+++ b/support/man2html.c
@@ -452,8 +452,14 @@ print_sig(void)
struct tm *timetm;
time_t  clock;
 
-   datbuf[0] = '\0';
+#ifdef HAVE_GETTIMEOFDAY
+   struct timeval tv;
+   gettimeofday (&tv, NULL);
+   clock = tv.tv_sec;
+#else
clock = time(NULL);
+#endif
+   datbuf[0] = '\0';
timetm = localtime(&clock);
strftime(datbuf, MED_STR_MAX, TIMEFORMAT, timetm);
printf(signature, manpage, datbuf);
-- 
2.39.2

Bash not portable to C23

[Paul Eggert]

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 new-style function definitions. Indeed, most GNU projects I'm 
familiar with assume many C99 constructs.

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

[Paul Eggert]

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

[Paul Eggert]

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 problem in Bash?


I believe this was done a few months ago on the devel branch.

https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=a61ffa78ede6df4d1127fddd2e8a1a77a7186ea1


Oh, thanks, I was looking at the wrong branch.

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 Bash won't port to C23?

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

[Paul Eggert]

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.
https://sourceware.org/bugzilla/show_bug.cgi?id=30200

This fixes a bug reported against Bash in 2020 by felix
https://lists.gnu.org/archive/html/bug-bash/2020-04/msg00072.html

* include/posixtime.h (getnow): New function.
All calls to 'time' changed to use this function.
* support/man2html.c (print_sig): Prefer gettimeofday if available.
---
 general.h  |  2 +-
 include/posixtime.h| 10 ++
 lib/readline/history.c |  4 +++-
 parse.y|  6 +++---
 support/man2html.c |  8 +++-
 5 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/general.h b/general.h
index fa57251a..2232fabd 100644
--- a/general.h
+++ b/general.h
@@ -242,7 +242,7 @@ typedef int sh_builtin_func_t (WORD_LIST *); /* 
sh_wlist_func_t */
 
 #endif /* SH_FUNCTION_TYPEDEF */
 
-#define NOW((time_t) time ((time_t *) 0))
+#define NOWgetnow ()
 #define GETTIME(tv)gettimeofday(&(tv), NULL)
 
 /* Some defines for calling file status functions. */
diff --git a/include/posixtime.h b/include/posixtime.h
index 319cb168..7b0fc035 100644
--- a/include/posixtime.h
+++ b/include/posixtime.h
@@ -52,6 +52,16 @@ struct timeval
 extern int gettimeofday (struct timeval * restrict, void * restrict);
 #endif
 
+static inline time_t
+getnow (void)
+{
+  /* Avoid time (NULL), which can disagree with gettimeofday and with
+ filesystem timestamps.  */
+  struct timeval now;
+  gettimeofday (&now, 0);
+  return now.tv_sec;
+}
+
 /* These exist on BSD systems, at least. */
 #if !defined (timerclear)
 #  define timerclear(tvp)  do { (tvp)->tv_sec = 0; (tvp)->tv_usec = 0; } 
while (0)
diff --git a/lib/readline/history.c b/lib/readline/history.c
index 42580301..9dc90147 100644
--- a/lib/readline/history.c
+++ b/lib/readline/history.c
@@ -48,6 +48,7 @@
 #include "history.h"
 #include "histlib.h"
 
+#include "posixtime.h"
 #include "xmalloc.h"
 
 #if !defined (errno)
@@ -261,7 +262,8 @@ hist_inittime (void)
   time_t t;
   char ts[64], *ret;
 
-  t = (time_t) time ((time_t *)0);
+  t = getnow ();
+
 #if defined (HAVE_VSNPRINTF)   /* assume snprintf if vsnprintf exists 
*/
   snprintf (ts, sizeof (ts) - 1, "X%lu", (unsigned long) t);
 #else
diff --git a/parse.y b/parse.y
index b758756a..2a61eb8c 100644
--- a/parse.y
+++ b/parse.y
@@ -85,7 +85,7 @@ typedef void *alias_t;
 #  ifndef _MINIX
 #include 
 #  endif
-#  include 
+#  include "posixtime.h"
 #  if defined (TM_IN_SYS_TIME)
 #include 
 #include 
@@ -5976,7 +5976,7 @@ decode_prompt_string (char *string)
case '@':
case 'A':
  /* Make the current time/date into a string. */
- (void) time (&the_time);
+ the_time = getnow ();
 #if defined (HAVE_TZSET)
  sv_tz ("TZ"); /* XXX -- just make sure */
 #endif
@@ -6010,7 +6010,7 @@ decode_prompt_string (char *string)
  if (string[1] != '{') /* } */
goto not_escape;
 
- (void) time (&the_time);
+ the_time = getnow ();
  tm = localtime (&the_time);
  string += 2;  /* skip { */
  t = string;
diff --git a/support/man2html.c b/support/man2html.c
index 58165796..61f05f10 100644
--- a/support/man2html.c
+++ b/support/man2html.c
@@ -452,8 +452,14 @@ print_sig(void)
struct tm *timetm;
time_t  clock;
 
-   datbuf[0] = '\0';
+#if HAVE_GETTIMEOFDAY
+   struct timeval tv;
+   gettimeofday (&tv, NULL);
+   clock = tv.tv_sec;
+#else
clock = time(NULL);
+#endif
+   datbuf[0] = '\0';
timetm = localtime(&clock);
if (timetm)
  strftime(datbuf, MED_STR_MAX, TIMEFORMAT, timetm);
-- 
2.39.2

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

[Paul Eggert]

* 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 sets the system
clock to such an absurdly high value so that tm_year cannot
represent the year, and localtime returns NULL with
errno == EOVERFLOW.
---
 examples/loadables/stat.c |  2 ++
 examples/loadables/strftime.c |  7 +++
 lib/readline/examples/histexamp.c |  6 --
 parse.y   | 35 +--
 support/man2html.c|  5 -
 5 files changed, 41 insertions(+), 14 deletions(-)

diff --git a/examples/loadables/stat.c b/examples/loadables/stat.c
index 3ca1a589..3ca2417a 100644
--- a/examples/loadables/stat.c
+++ b/examples/loadables/stat.c
@@ -261,6 +261,8 @@ stattime (time_t t, const char *timefmt)
 
   fmt = timefmt ? timefmt : DEFTIMEFMT;
   tm = localtime (&t);
+  if (!tm)
+return itos (t);
 
   ret = xmalloc (TIMELEN_MAX);
 
diff --git a/examples/loadables/strftime.c b/examples/loadables/strftime.c
index e6c8141e..43fb3839 100644
--- a/examples/loadables/strftime.c
+++ b/examples/loadables/strftime.c
@@ -80,6 +80,13 @@ strftime_builtin (WORD_LIST *list)
 secs = NOW;
 
   t = localtime (&secs);
+  if (!t)
+{
+  builtin_error ("%s: %s",
+list && list->word->word ? list->word->word : "now",
+_("timestamp out of range"));
+  return (EXECUTION_FAILURE);
+}
 
   tbsize = strlen (format) * 4;
   tbuf = 0;
diff --git a/lib/readline/examples/histexamp.c 
b/lib/readline/examples/histexamp.c
index 309d769b..b321dd0b 100644
--- a/lib/readline/examples/histexamp.c
+++ b/lib/readline/examples/histexamp.c
@@ -97,9 +97,11 @@ main (argc, argv)
  if (the_list)
for (i = 0; the_list[i]; i++)
  {
+   struct tm *tm;
tt = history_get_time (the_list[i]);
-   if (tt)
- strftime (timestr, sizeof (timestr), "%a %R", localtime(&tt));
+   tm = tt ? localtime (&tt) : 0;
+   if (tm)
+ strftime (timestr, sizeof (timestr), "%a %R", tm);
else
  strcpy (timestr, "??");
printf ("%d: %s: %s\n", i + history_base, timestr, 
the_list[i]->line);
diff --git a/parse.y b/parse.y
index 639912b6..b758756a 100644
--- a/parse.y
+++ b/parse.y
@@ -5982,7 +5982,12 @@ decode_prompt_string (char *string)
 #endif
  tm = localtime (&the_time);
 
- if (c == 'd')
+ if (!tm)
+   {
+ strcpy (timebuf, "??");
+ tslen = 2;
+   }
+ else if (c == 'd')
tslen = strftime (timebuf, sizeof (timebuf), "%a %b %d", tm);
  else if (c == 't')
tslen = strftime (timebuf, sizeof (timebuf), "%H:%M:%S", tm);
@@ -6008,19 +6013,27 @@ decode_prompt_string (char *string)
  (void) time (&the_time);
  tm = localtime (&the_time);
  string += 2;  /* skip { */
- timefmt = xmalloc (strlen (string) + 3);
- for (t = timefmt; *string && *string != '}'; )
-   *t++ = *string++;
- *t = '\0';
+ t = string;
+ while (*string && *string != '}')
+   string++;
  c = *string;  /* tested at add_string */
- if (timefmt[0] == '\0')
+
+ if (tm)
+   {
+ size_t timefmtlen = string - t;
+ timefmt = xmalloc (timefmtlen + 3);
+ memcpy (timefmt, t, timefmtlen);
+ timefmt[timefmtlen] = '\0';
+ if (timefmtlen == 0)
+   strcpy (timefmt, "%X"); /* locale-specific current time */
+ tslen = strftime (timebuf, sizeof (timebuf), timefmt, tm);
+ free (timefmt);
+   }
+ else
{
- timefmt[0] = '%';
- timefmt[1] = 'X'; /* locale-specific current time */
- timefmt[2] = '\0';
+ strcpy (timebuf, "??");
+ tslen = 2;
}
- tslen = strftime (timebuf, sizeof (timebuf), timefmt, tm);
- free (timefmt);
 
  if (tslen == 0)
timebuf[0] = '\0';
diff --git a/support/man2html.c b/support/man2html.c
index e6f441b4..58165796 100644
--- a/support/man2html.c
+++ b/support/man2html.c
@@ -455,7 +455,10 @@ print_sig(void)
datbuf[0] = '\0';
clock = time(NULL);
timetm = localtime(&clock);
-   strftime(datbuf, MED_STR_MAX, TIMEFORMAT, timetm);
+   if (timetm)
+ strftime(datbuf, MED_STR_MAX, TIMEFORMAT, timetm);
+   else
+ strcpy(datbuf, "??");
  

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

[Paul Eggert]

* 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
@@ -311,13 +311,12 @@ sh_mktmpdir (const char *nameroot, int flags)
   do
 {
   filename = sh_mktmpname (nameroot, flags);
-  fd = mkdir (filename, 0700);
-  if (fd == 0)
+  if (mkdir (filename, 0700) == 0)
break;
   free (filename);
   filename = (char *)NULL;
 }
-  while (fd < 0 && errno == EEXIST);
+  while (errno == EEXIST);
 
   return (filename);
 #endif /* !USE_MKDTEMP */
-- 
2.39.2

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

[Paul Eggert]

* 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 a/lib/sh/random.c b/lib/sh/random.c
index 1faeacae..16877430 100644
--- a/lib/sh/random.c
+++ b/lib/sh/random.c
@@ -91,7 +91,7 @@ genseed (void)
   u_bits32_t iv;
 
   gettimeofday (&tv, NULL);
-  iv = (u_bits32_t)seedrand;   /* let the compiler truncate */
+  iv = (uintptr_t)seedrand;/* let the compiler truncate */
   iv = tv.tv_sec ^ tv.tv_usec ^ getpid () ^ getppid () ^ current_user.uid ^ iv;
   return (iv);
 }
-- 
2.39.2

[PATCH 3/4] Port unwind protection to C23

[Paul Eggert]

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 'add_unwind_protect
(pop_scope, should_keep ? "1" : 0)' eventually casts a nonnull
pointer to to an int that is tested against zero to see whether
the pointer was null; this does not work if pointers are 64 bits,
ints are 32 bits, and half the nonnull pointer happens to be all
bits zero.

Strictly speaking, the old code wasn't portable even to C89 on
hypothetical platforms.  However, C23 makes this more urgent since
it removes support for K&R-style function declarations.

Use the generic function type void (*) (void *) for all unwind
cleanups.  When an existing cleanup doesn't already have that
type, change the type if the function is used only as a cleanup,
and add a shim function otherwise.  If the shim is used in more
than one compilation unit, put the shim function next to the
cleanup as an extern function; otherwise, put the shim in the
compilation unit as a static function.

Although this does not finish the job of porting to C23,
one step at a time.

* builtins/mkbuiltins.c, general.h, readline/rltypedefs.h
(_FUNCTION_DEF, Function, VFunction, CPFunction, CPPFunction):
Remove; no longer used, as they are no longer needed.
Their meaning changes in C23 anyway.
* configure.ac (AC_TYPE_INTPTR_T): Use this.
* execute_cmd.c (execute_command_internal):
Remove a 'volatile' that didn't type check and appears to
be a typo anyway.  Perhaps 'void *volatile' was meant, but
in that case the 'volatile' appears to be unnecessary anyway.
* general.h (STREQ, STREQN): Now inline functions instead of
macros; needed for unwind_prot.c now that it passes void *
to STREQ.
* unwind_prot.c (UNWIND_ELT): Use a prototype for head.cleanup.
arg.v is now void *, not char *; this simplifies use.
(without_interrupts): Remove, as this vestigial function just
got in the way of type checking.
---
 builtins/command.def  |   2 +-
 builtins/evalfile.c   |   4 +-
 builtins/evalstring.c |  35 +---
 builtins/fc.def   |  10 +++-
 builtins/jobs.def |   2 +-
 builtins/mkbuiltins.c |   1 -
 builtins/read.def |  35 +---
 builtins/source.def   |   6 +-
 configure.ac  |   1 +
 dispose_cmd.c |  10 
 dispose_cmd.h |   2 +
 execute_cmd.c | 117 +++---
 execute_cmd.h |   3 +
 general.h |  22 ---
 lib/readline/rltypedefs.h |  21 ---
 pcomplete.c   |  26 ++---
 print_cmd.c   |   4 +-
 subst.c   |   2 +-
 trap.c|  10 ++--
 trap.h|   8 +--
 unwind_prot.c |  82 +++---
 unwind_prot.h |   2 +-
 variables.c   |  11 +++-
 variables.h   |   5 +-
 24 files changed, 254 insertions(+), 167 deletions(-)

diff --git a/builtins/command.def b/builtins/command.def
index e695fdd1..a376131e 100644
--- a/builtins/command.def
+++ b/builtins/command.def
@@ -131,7 +131,7 @@ command_builtin (WORD_LIST *list)
   command->flags |= COMMAND_BUILTIN_FLAGS;
   command->value.Simple->flags |= COMMAND_BUILTIN_FLAGS;
 
-  add_unwind_protect ((char *)dispose_command, command);
+  add_unwind_protect (unwind_dispose_command, command);
   result = execute_command (command);
 
   run_unwind_frame ("command_builtin");
diff --git a/builtins/evalfile.c b/builtins/evalfile.c
index 9b6f4215..46788398 100644
--- a/builtins/evalfile.c
+++ b/builtins/evalfile.c
@@ -247,7 +247,7 @@ file_error_and_exit:
   fa->funcname_a = funcname_a;
   fa->funcname_v = funcname_v;
   if (flags & FEVAL_UNWINDPROT)
-add_unwind_protect (restore_funcarray_state, fa);
+add_unwind_protect (unwind_restore_funcarray_state, fa);
 
 #  if defined (DEBUGGER)
   /* Have to figure out a better way to do this when `source' is supplied
@@ -260,7 +260,7 @@ file_error_and_exit:
   tt[0] = '1'; tt[1] = '\0';
   array_push (bash_argc_a, tt);
   if (flags & FEVAL_UNWINDPROT)
-   add_unwind_protect (pop_args, 0);
+   add_unwind_protect (unwind_pop_args, 0);
 }
 #  endif
 #endif
diff --git a/builtins/evalstring.c b/builtins/evalstring.c
index 243becbc..b52a1a26 100644
--- a/builtins/evalstring.c
+++ b/builtins/evalstring.c
@@ -70,14 +70,14 @@ static int cat_file (REDIRECT *);
 
 #if defined (HISTORY)
 static void
-set_history_remembering (void)
+set_history_remembering (void *ignored)
 {
   remember_on_history = enable_history_list;
 }
 #endif
 
 static void
-restore_lastcom (char *x)
+restore_lastcom (void *x)
 {
   FREE (the_printed_command_except_trap);
   the_printed_command_except_trap = x;
@@ -204,6 +204,26 @@ parse_and_execute_cleanup (int old_running_trap)
 parse_and_execute_level = 0;

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

[Paul Eggert]

There's no longer any point to worrying about K&R 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   |  4 
 builtins/gen-helpfiles.c  |  4 
 builtins/help.def |  9 +
 builtins/printf.def   |  5 -
 general.h |  9 -
 hashlib.h | 14 +-
 include/ansi_stdlib.h |  8 +---
 include/ocache.h  |  8 +---
 include/stdc.h| 12 
 lib/doc-support/getopt.c  |  4 
 lib/doc-support/getopt.h  |  4 
 lib/doc-support/getopt1.c |  4 
 lib/glob/collsyms.h   |  4 
 lib/glob/glob.c   |  8 
 lib/intl/explodename.c|  9 -
 lib/readline/history.h|  4 
 lib/readline/xmalloc.h|  8 +---
 lib/sh/strtrans.c | 11 ---
 lib/sh/vprint.c   |  8 
 lib/tilde/tilde.c |  8 
 mksyntax.c|  5 -
 support/endian.c  |  4 
 xmalloc.c |  6 +-
 xmalloc.h |  8 +---
 25 files changed, 7 insertions(+), 176 deletions(-)

diff --git a/aclocal.m4 b/aclocal.m4
index b8f67e75..5a0fa1fb 100644
--- a/aclocal.m4
+++ b/aclocal.m4
@@ -556,11 +556,6 @@ AC_CACHE_VAL(bash_cv_getenv_redef,
 #  include 
 #endif
 #include 
-#ifndef __STDC__
-#  ifndef const
-#define const
-#  endif
-#endif
 char *
 getenv (const char *name)
 {
@@ -600,11 +595,6 @@ AC_CACHE_CHECK([for standard-conformant putenv 
declaration], bash_cv_std_putenv,
 #if HAVE_STDDEF_H
 #include 
 #endif
-#ifndef __STDC__
-#  ifndef const
-#define const
-#  endif
-#endif
 extern int putenv (char *);
 ]], [[return (putenv == 0);]] )],
 [bash_cv_std_putenv=yes], [bash_cv_std_putenv=no]
@@ -625,11 +615,6 @@ AC_CACHE_CHECK([for standard-conformant unsetenv 
declaration], bash_cv_std_unset
 #if HAVE_STDDEF_H
 #include 
 #endif
-#ifndef __STDC__
-#  ifndef const
-#define const
-#  endif
-#endif
 extern int unsetenv (const char *);
 ]], [[return (unsetenv == 0);]] )],
 [bash_cv_std_unsetenv=yes], [bash_cv_std_unsetenv=no]
diff --git a/builtins/enable.def b/builtins/enable.def
index e6948bac..f44820b3 100644
--- a/builtins/enable.def
+++ b/builtins/enable.def
@@ -488,11 +488,7 @@ delete_builtin (struct builtin *b)
   struct builtin *new_shell_builtins;
 
   /* XXX - funky pointer arithmetic - XXX */
-#ifdef __STDC__
   ind = b - shell_builtins;
-#else
-  ind = ((int)b - (int)shell_builtins) / sizeof (struct builtin);
-#endif
   size = num_shell_builtins * sizeof (struct builtin);
   new_shell_builtins = (struct builtin *)xmalloc (size);
 
diff --git a/builtins/gen-helpfiles.c b/builtins/gen-helpfiles.c
index 76f7c06b..771e1e45 100644
--- a/builtins/gen-helpfiles.c
+++ b/builtins/gen-helpfiles.c
@@ -72,10 +72,6 @@
 extern int errno;
 #endif
 
-#if !defined (__STDC__) && !defined (strcpy)
-extern char *strcpy ();
-#endif /* !__STDC__ && !strcpy */
-
 #define whitespace(c) (((c) == ' ') || ((c) == '\t'))
 
 /* Flag values that builtins can have. */
diff --git a/builtins/help.def b/builtins/help.def
index 293f23de..3b248cdd 100644
--- a/builtins/help.def
+++ b/builtins/help.def
@@ -193,19 +193,12 @@ void
 builtin_help (void)
 {
   int ind;
-  ptrdiff_t d;
 
   current_builtin = builtin_address_internal (this_command_name, 0);
   if (current_builtin == 0)
 return;
 
-  d = current_builtin - shell_builtins;
-
-#if defined (__STDC__)
-  ind = (int)d;
-#else
-  ind = (int)d / sizeof (struct builtin);
-#endif
+  ind = current_builtin - shell_builtins;
 
   printf ("%s: %s\n", this_command_name, _(shell_builtins[ind].short_doc));
   show_longdoc (ind);  
diff --git a/builtins/printf.def b/builtins/printf.def
index 2a6e2658..cbf09039 100644
--- a/builtins/printf.def
+++ b/builtins/printf.def
@@ -1034,12 +1034,7 @@ tescape (char *estart, char *cp, int *lenp, int *sawc)
 
   switch (c = *p++)
 {
-#if defined (__STDC__)
   case 'a': *cp = '\a'; break;
-#else
-  case 'a': *cp = '\007'; break;
-#endif
-
   case 'b': *cp = '\b'; break;
 
   case 'e':
diff --git a/general.h b/general.h
index 2b81f683..f5b1e875 100644
--- a/general.h
+++ b/general.h
@@ -45,15 +45,6 @@
 
 #include "xmalloc.h"
 
-/* NULL pointer type. */
-#if !defined (NULL)
-#  if defined (__STDC__)
-#define NULL ((void *) 0)
-#  else
-#define NULL 0x0
-#  endif /* !__STDC__ */
-#endif /* !NULL */
-
 /* Hardly used anymore */
 #define pointer_to_int(x)  (int)((char *)x - (char *)0)
 
diff --git a/hashlib.h b/hashlib.h
index 623ad0aa..0b4126ab 100644
--- a/hashlib.h
+++ b/hashlib.h
@@ -24,11 +24,7 @@
 #include "stdc.h"
 
 #ifndef PTR_T
-#  ifdef __STDC__
-#define PTR_T void *
-#  else
-#define PTR_T char *
-#  endif
+# define PTR_T void *
 #endif
 
 typedef struct bucket_contents {
@@ -81,12 +77,4 @@ extern unsigned

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

[Paul Eggert]

Since we now assume C89 function prototypes anyway,
remove no-longer-used cruft that is used only for
ports to compilers requiring K&R style.
---
 aclocal.m4 | 35 +
 builtins/common.c  | 23 ++
 builtins/mkbuiltins.c  |  4 ---
 builtins/printf.def| 10 ++
 config-bot.h   | 11 ---
 configure.ac   |  3 +-
 error.c| 29 --
 examples/loadables/finfo.c | 30 --
 general.h  |  4 ---
 include/memalloc.h |  4 ---
 include/stdc.h | 18 ---
 jobs.h |  2 +-
 lib/doc-support/getopt.h   | 20 
 lib/readline/bind.c| 21 -
 lib/readline/complete.c|  4 ---
 lib/readline/display.c | 57 --
 lib/readline/examples/rl.c |  5 ---
 lib/readline/funmap.c  |  4 ---
 lib/readline/histlib.h |  3 --
 lib/readline/parens.c  |  4 ---
 lib/readline/readline.h|  4 ---
 lib/readline/rldefs.h  | 12 +---
 lib/readline/rlprivate.h   |  6 
 lib/readline/rlstdc.h  | 20 
 lib/readline/util.c| 63 --
 lib/sh/dprintf.c   |  9 ++
 lib/sh/fdprintf.c  | 16 ++
 lib/sh/snprintf.c  | 11 ++-
 lib/sh/strindex.c  |  4 +--
 lib/sh/xstrchr.c   |  6 
 lib/termcap/termcap.h  | 24 ---
 m4/iconv.m4|  4 ---
 pcomplete.c|  9 ++
 print_cmd.c| 25 ++-
 34 files changed, 41 insertions(+), 463 deletions(-)

diff --git a/aclocal.m4 b/aclocal.m4
index e6e18737..b8f67e75 100644
--- a/aclocal.m4
+++ b/aclocal.m4
@@ -69,11 +69,7 @@ AC_DEFUN(BASH_DECL_PRINTF,
 AC_CACHE_VAL(bash_cv_printf_declared,
 [AC_RUN_IFELSE([AC_LANG_SOURCE([[
 #include 
-#ifdef __STDC__
 typedef int (*_bashfunc)(const char *, ...);
-#else
-typedef int (*_bashfunc)();
-#endif
 #include 
 int
 main()
@@ -566,12 +562,7 @@ AC_CACHE_VAL(bash_cv_getenv_redef,
 #  endif
 #endif
 char *
-getenv (name)
-#if defined (__linux__) || defined (__bsdi__) || defined (convex)
- const char *name;
-#else
- char const *name;
-#endif /* !__linux__ && !__bsdi__ && !convex */
+getenv (const char *name)
 {
 return "42";
 }
@@ -601,7 +592,6 @@ fi
 # We should check for putenv before calling this
 AC_DEFUN(BASH_FUNC_STD_PUTENV,
 [
-AC_REQUIRE([AC_C_PROTOTYPES])
 AC_CACHE_CHECK([for standard-conformant putenv declaration], 
bash_cv_std_putenv,
 [AC_LINK_IFELSE([AC_LANG_PROGRAM([[
 #if HAVE_STDLIB_H
@@ -615,11 +605,7 @@ AC_CACHE_CHECK([for standard-conformant putenv 
declaration], bash_cv_std_putenv,
 #define const
 #  endif
 #endif
-#ifdef PROTOTYPES
 extern int putenv (char *);
-#else
-extern int putenv ();
-#endif
 ]], [[return (putenv == 0);]] )],
 [bash_cv_std_putenv=yes], [bash_cv_std_putenv=no]
 )])
@@ -631,7 +617,6 @@ fi
 # We should check for unsetenv before calling this
 AC_DEFUN(BASH_FUNC_STD_UNSETENV,
 [
-AC_REQUIRE([AC_C_PROTOTYPES])
 AC_CACHE_CHECK([for standard-conformant unsetenv declaration], 
bash_cv_std_unsetenv,
 [AC_LINK_IFELSE([AC_LANG_PROGRAM([[
 #if HAVE_STDLIB_H
@@ -645,11 +630,7 @@ AC_CACHE_CHECK([for standard-conformant unsetenv 
declaration], bash_cv_std_unset
 #define const
 #  endif
 #endif
-#ifdef PROTOTYPES
 extern int unsetenv (const char *);
-#else
-extern int unsetenv ();
-#endif
 ]], [[return (unsetenv == 0);]] )],
 [bash_cv_std_unsetenv=yes], [bash_cv_std_unsetenv=no]
 )])
@@ -2091,31 +2072,17 @@ AC_DEFUN([BASH_FUNC_VSNPRINTF],
   if test X$ac_cv_func_vsnprintf = Xyes; then
 AC_CACHE_CHECK([for standard-conformant vsnprintf], 
[bash_cv_func_vsnprintf],
   [AC_RUN_IFELSE([AC_LANG_SOURCE([[
-#if HAVE_STDARG_H
 #include 
-#else
-#include 
-#endif
 #include 
 #include 
 
 static int
-#if HAVE_STDARG_H
 foo(const char *fmt, ...)
-#else
-foo(format, va_alist)
- const char *format;
- va_dcl
-#endif
 {
   va_list args;
   int n;
 
-#if HAVE_STDARG_H
   va_start(args, fmt);
-#else
-  va_start(args);
-#endif
   n = vsnprintf(0, 0, fmt, args);
   va_end (args);
   return n;
diff --git a/builtins/common.c b/builtins/common.c
index 2679fae3..79e61887 100644
--- a/builtins/common.c
+++ b/builtins/common.c
@@ -34,12 +34,7 @@
 #include 
 
 #include 
-
-#if defined (PREFER_STDARG)
-#  include 
-#else
-#  include 
-#endif
+#include 
 
 #include "../bashansi.h"
 #include "../bashintl.h"
@@ -100,19 +95,13 @@ builtin_error_prolog (void)
 }
 
 void
-#if defined (PREFER_STDARG)
 builtin_error (const char *format, ...)
-#else
-builtin_error (format, va_alist)
- const char *format;
- va_dcl
-#endif
 {
   va_list args;
 
   builtin_error_prolog ();
 
-  SH_VA_START (args, format);
+  va_start (args, format);
 
   vfprintf (stderr, format, args);
   va_end (args);
@@ -120,20 +109,14 @@ builtin_error (format, va_alist)
 }
 
 void
-#if defined (PREFER_STDARG)
 builtin_warning (const 

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

[Paul Eggert]

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 C23.  However, one step at a time.
---
 aclocal.m4| 20 
 array.c   |  3 ++
 array2.c  |  5 ++-
 braces.c  |  4 +--
 builtins/common.c |  2 +-
 builtins/getopts.def  | 16 +++--
 builtins/mkbuiltins.c |  2 +-
 builtins/psize-posix.c|  1 +
 examples/loadables/bsdos.glue.c   | 31 ++
 examples/loadables/finfo.c| 54 ++-
 examples/loadables/getconf.c  |  3 +-
 examples/loadables/id.c   |  4 +--
 examples/loadables/pathchk.c  |  3 +-
 examples/loadables/pushd.def  | 42 +---
 examples/loadables/tee.c  |  2 +-
 examples/loadables/tty.c  |  2 +-
 execute_cmd.c |  2 +-
 expr.c| 12 +--
 externs.h | 10 +++---
 include/memalloc.h| 14 +++-
 input.c   |  1 +
 lib/glob/glob.c   |  5 ++-
 lib/glob/gm_loop.c| 11 ++-
 lib/glob/ndir.h   |  9 +++---
 lib/glob/strmatch.c   |  5 ++-
 lib/malloc/memtest.c  |  1 +
 lib/readline/bind.c   |  4 +--
 lib/readline/doc/hstech.texi  |  5 ++-
 lib/readline/doc/rltech.texi  | 18 ---
 lib/readline/examples/fileman.c   | 14 +++-
 lib/readline/examples/histexamp.c |  4 +--
 lib/readline/examples/rl.c|  4 +--
 lib/readline/examples/rlcat.c | 10 ++
 lib/readline/rltty.c  |  3 +-
 lib/readline/text.c   |  3 +-
 lib/sh/getcwd.c   |  5 ++-
 lib/sh/snprintf.c |  1 +
 lib/sh/strftime.c |  4 +--
 lib/sh/stringlist.c   |  2 +-
 lib/sh/stringvec.c|  2 +-
 lib/termcap/termcap.c |  5 ++-
 lib/termcap/tparam.c  |  5 ++-
 lib/tilde/shell.c |  2 +-
 lib/tilde/tilde.c |  3 +-
 pcomplete.c   |  2 +-
 shell.c   |  2 +-
 subst.c   |  7 ++--
 support/bashversion.c |  4 +--
 support/endian.c  |  5 ++-
 support/memtest.c |  1 +
 support/mksignames.c  |  7 ++--
 support/printenv.c|  4 +--
 support/recho.c   |  9 ++
 support/rlvers.sh |  1 +
 support/version2.c|  3 +-
 support/xcase.c   |  4 +--
 support/zecho.c   |  4 +--
 tests/misc/regress/getdate.y  |  7 ++--
 variables.c   |  3 +-
 version.c |  3 +-
 60 files changed, 164 insertions(+), 260 deletions(-)

diff --git a/aclocal.m4 b/aclocal.m4
index 37546c6c..e6e18737 100644
--- a/aclocal.m4
+++ b/aclocal.m4
@@ -432,6 +432,7 @@ AC_CACHE_VAL(bash_cv_sizeof_rlim_cur,
 #endif
 #include 
 #include 
+int
 main()
 {
 struct rlimit r;
@@ -457,6 +458,7 @@ AC_CACHE_VAL(bash_cv_sizeof_quad_t,
 #include 
 #endif
 
+int
 main()
 {
 #if HAVE_QUAD_T
@@ -841,9 +843,7 @@ AC_CACHE_VAL(bash_cv_func_strcoll_broken,
 #include 
 
 int
-main(c, v)
-int c;
-char*v[];
+main (int c, char **v)
 {
 int r1, r2;
 char*deflocale, *defcoll;
@@ -1345,15 +1345,13 @@ AC_CACHE_VAL(bash_cv_must_reinstall_sighandlers,
 #endif
 #include 
 
-typedef void sigfunc();
+typedef void sigfunc (int);
 
 volatile int nsigint;
 
 #ifdef HAVE_POSIX_SIGNALS
 sigfunc *
-set_signal_handler(sig, handler)
- int sig;
- sigfunc *handler;
+set_signal_handler (int sig, sigfunc *handler)
 {
   struct sigaction act, oact;
   act.sa_handler = handler;
@@ -1836,9 +1834,7 @@ bash_cv_wcwidth_broken,
 #include 
 
 int
-main(c, v)
-int c;
-char**v;
+main (int c, char **v)
 {
 int w;
 
@@ -2156,9 +2152,7 @@ AC_CACHE_VAL(bash_cv_wexitstatus_offset,
 #include 
 
 int
-main(c, v)
- int c;
- char **v;
+main (int c, char **v)
 {
   pid_t pid, p;
   int s, i, n;
diff --git a/array.c b/array.c
index 61894e0b..6f8926eb 100644
--- a/array.c
+++ b/array.c
@@ -1119,6 +1119,7 @@ quote_string(char *s)
return savestring(s);
 }
 
+int
 print_element(ARRAY_ELEMENT *ae)
 {
charlbuf[INT_STRLEN_BOUND (intmax_t) + 1];
@@ -1128,12 +1129,14 @@ print_element(ARRAY_ELEMENT *ae)
element_value(ae));
 }
 
+int
 print_array(ARRAY *a)
 {
printf("\n");
array_walk(a, print_element, (void *)NULL);
 }
 
+int
 main(int c, char **v)
 {
ARRAY   *a, *new_a, *copy_of_a;
diff --git a/array2.c b/array2.c
index 2988f3b1..3b6a62

Re: Bash not portable to C23

[Paul Eggert]

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 Bash won't port to C23?


Please report those as you find them.


I reported many of the ones I found to bug-bash just now. Many more such 
issues remain, unfortunately.


In looking into this I had some trouble reading the code - perhaps you 
could let me know if there's a roadmap for newbies? Or if there isn't 
one perhaps we could write one. That might help attract other people to 
make further improvements.


Here's a brief summary of my guesses at the situation; please correct me 
if I'm wrong. Perhaps this could serve as a basis for a roadmap.


* Ignore everything under the CWRU directory, because it does not 
contribute anything to any builds. Similarly for lib/posixheaders.old 
and support/config.*.*. (What other code should I ignore, and what's the 
motivation for keeping the unused code in the repository?)


* Ignore files like 'configure' and 'doc/bash.pdf' that are 
automatically generated. (Is there a list of which files these are? It's 
not clear to me.)


* Ignore lib/glob, lib/intl, lib/malloc, and lib/termcap as these are 
all taken from other projects and fixes should be sent there. (The other 
lib/* directories belong to Bash, though.)


* Ignore most of the files in m4/* as they're taken from Gnulib. (Which 
files?)


* Ignore the po/* files as they're all automatically generated and/or 
synced from the Translation Project somehow.


* Ignore support/config.guess and support/config.sub as it's taken from 
the GNU config upstream. Likewise for support/config.rpath, taken from 
GNU Libtool.



PS. What are the procedures for syncing from upstream? Is it all done by 
hand? In other projects we automate this as much as possible - would a 
patch to do that be welcome?

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

[Paul Eggert]

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 limited to 
platforms where pointers can differ in size or representation. The 
problem can also occur on platforms where calling conventions differ 
depending on type even if the two types have the same representation, 
and this can (and has) occurred on platforms with linear address spaces.


The patch fixes an actual (albeit unlikely) bug on GNU/Linux x86-64, due 
to a variant of that sort of thing.



I'm all for tidying up the code so that it can compile
cleanly and run reliably.


Yes, it's a win overall.

The patch is not enough to make Bash entirely C23-safe, alas; more work 
needs to be done in this area. Unfortunately it's a bit of a pain due to 
the K&R cruft still present (which can fight with C23).

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

[Paul Eggert]

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 even when %b is repurposed to align with C2x?


Sounds good to me for coreutils.

test -lt inconsistent about white space

[Paul Eggert]

Consider the following shell script 'doit':

sp=' '
nl='
'
test "${sp}1${sp}" -lt "${sp}2${sp}"
test "${nl}3${sp}" -lt "${nl}4${sp}"
test "${sp}5${nl}" -lt "${sp}6${nl}"
test "${nl}7${nl}" -lt "${nl}8${nl}"

Running the command "bash doit" outputs:

doit: line 6: test:  5
: integer expression expected
doit: line 7: test:
7
: integer expression expected

The problem occurs because strtoimax accepts all forms of leading 
whitespace, whereas Bash accepts only space and tab after the integer. 
This is inconsistent: 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 2023 12:05:14 -0700
Subject: [PATCH] fix inconsistency when parsing integers

* general.c (legal_number): Treat trailing whitespace
like leading whitespace.
---
 general.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/general.c b/general.c
index da59f9c0..3e63f9f7 100644
--- a/general.c
+++ b/general.c
@@ -256,7 +256,7 @@ legal_number (const char *string, intmax_t *result)
 return 0;	/* errno is set on overflow or underflow */
 
   /* Skip any trailing whitespace, since strtoimax does not. */
-  while (whitespace (*ep))
+  while (isspace ((unsigned char) *ep))
 ep++;
 
   /* If *string is not '\0' but *ep is '\0' on return, the entire string
-- 
2.41.0

Re: test -lt inconsistent about white space

[Paul Eggert]

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

Presumably this is because they use strtol or equivalent, and accept 
exactly the strings that strtol accepts. Although that's an allowed 
behavior, it's not the behavior that Bash and ksh and Dash use; they 
both allow the second example listed above.


My understanding is that Bash was intended to allow both leading and 
trailing whitespace. This is compatible with ksh and with Dash. If 
that's the intent, Bash should be consistent about it, just as ksh and 
Dash are. There seems little point to allowing one nonempty set of 
whitespace characters before the integer, and a different nonempty set 
of whitespace characters afterwards.


For what it's worth, 7th Edition Unix sh allows any characters after the 
integer. (There doesn't even have to be an integer!)


PS. As I understand it, POSIX allows all the behaviors described above, 
so this is not a POSIX conformance issue.

Re: test -lt inconsistent about white space

[Paul Eggert]

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 shells we know about, then a patch differing from what I 
submitted should be applied. The patch I sent makes Bash self-consistent 
in a different way, one that is compatible with ksh and Dash. Although I 
would vote for the latter on compatibility grounds, the former is at 
least self-consistent.




https://git.savannah.gnu.org/cgit/bash.git/tree/test.c?id=726f63884db0132f01745f1fb4465e6621088ccf#n354


That old code is obviously wrong as it has undefined behavior on integer 
overflow. So we shouldn't simply revert to it, of course.

Re: test -lt inconsistent about white space

[Paul Eggert]

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 coreutils 'test' to be compatible with 
the proposed change to Bash (and to ksh and to Dash), here:


https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=2709bea0f440507ac009e6e7ded453bb792d6842

Re: multi-threaded compiling

[Paul Smith]

On Mon, 2024-03-11 at 09:56 +0100, Mischa Baars wrote:
> I've attached the problem. It consists of two parts:
> 
> 1) multi-threaded bash script and / or multi-threaded Makefile
> 
> Running bash script functions as expected, but executing the same
> line of code with make and / or the command line, does not function.
> Perhaps someone could explain to me why?
> 
> 2) passing a string argument from a bash script and / or Makefile to
> the gcc -D option
> 
> Running the makefile functions as expected, but I have not been able
> to get similar code to work from a bash script. Can someone please
> explain to me what I'm doing wrong?

I don't understand the problem.  In the third paragraph above you say
the bash script works as expected and the makefile doesn't work, but in
the last paragraph you say that the makefile works as expected but you
can't get it to work in bash.

Please provide actual command invocations (cut and pasted) showing the
output you received and explaining exactly what is wrong with it.

But before you do that, be aware that make does NOT invoke /bin/bash as
its shell.  It invokes /bin/sh.  On some systems /bin/sh is actually an
alias for bash.  On other systems it isn't.

If you want your makefile to always use bash as its shell, you should
add an explicit:

SHELL := /bin/bash

to your makefile to force it.  Maybe that will solve your problem.  If
not we'll need details such as I mention above.

Re: multi-threaded compiling

[Paul Smith]

On Mon, 2024-03-11 at 18:14 +0100, Mischa Baars wrote:
> The actual command invocations (a Makefile, a make.sh script) can be
> found in the attachment, as indicated on the first line of the mail.
> In the attachment there are two directories, one and two, belonging
> to 1) and 2) respectively.

That's not what I asked: I asked YOU to run the commands on YOUR system
and cut and paste the results of the run into your email message, with
an explicit explanation of exactly what is wrong with the results and
what you wanted to see instead.  What errors did you get?  Or what was
unexpected about the behavior?

I'm not interested in running random scripts on my system that were
downloaded from an email, or examining their behavior to make sure
they're OK, or setting up a container to run them in, or guessing what
you wanted to happen, etc.

Or maybe someone else will want to do that work instead.

But before putting in more effort on the "misbehaving" makefile, read
this part of my response carefully:

> But before you do that, be aware that make does NOT invoke /bin/bash
> as its shell.  It invokes /bin/sh.  On some systems /bin/sh is
> actually an alias for bash.  On other systems it isn't.
> 
> If you want your makefile to always use bash as its shell, you should
> add an explicit:
> 
> SHELL := /bin/bash
> 
> to your makefile to force it.  Maybe that will solve your problem. 
> If not we'll need details such as I mention above.

and verify in your response you added the suggested line to your
makefile and it didn't help (in the situation where the makefile was
behaving in an unexpected way).

Re: multi-threaded compiling

[Paul Smith]

On Mon, 2024-03-11 at 19:37 +0100, alex xmb sw ratchev wrote:
> /data/data/com.termux/files/usr/bin/sh: 1: Syntax error: Bad for loop
> variable

This is because of the issue I mentioned in my initial reply.  This
invocation is using /bin/sh which is a POSIX shell but is not bash;
probably it's dash or similar (you are running on Debian or one of the
GNU/Linux distros that build on it).

If you set "SHELL := /bin/bash" (or whatever the path is for bash on
your system) in the makefile you won't see this, I expect.

Re: multi-threaded compiling

[Paul Smith]

On Mon, 2024-03-11 at 15:36 -0400, Greg Wooledge wrote:
> You won't be able to take advantage of "wait -n"'s ability to react
> to the first job that finishes.  You'll end up reaping each job in
> the order they started, not the order they finished.

It feels to me like you're trying to reproduce make's already-available
parallel build support, in a kind of kludgy way with bash.

Maybe this is an XY problem and you should step back and describe WHY
you're trying to create this behavior using bash instead of just using
make's support for parallel jobs.

What about make's parallel jobs doesn't meet your requirements (or put
another way, what actually are your requirements)?

Bash printf should diagnose integer overflow

[Paul Eggert]

Configuration Information:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2
uname output: Linux penguin.cs.ucla.edu 6.7.7-200.fc39.x86_64 #1 SMP 
PREEMPT_DYNAMIC Fri Mar  1 16:53:59 UTC 2024 x86_64 GNU/Linux

Machine Type: x86_64-redhat-linux-gnu

Bash Version: 5.3
Patch Level: 26
Release Status: devel

Description:
Commands like "printf '%1s' ''"
silently ignore width and precision.  They should report the
integer overflow before continuing with a lesser width or
precision.  (I ran into this bug while using Bash to output
very long strings of spaces for some test cases.)

Repeat-By:
printf '%1s' ''

It prints nothing.  It should print a diagnostic if it
cannot do the requested operation.

Fix:
Bash should use C23  to check for integer
overflow.  Gnulib supplies a replacement stdckdint.h that works
on pre-C23 platforms; it's been extensively tested in other GNU
apps and doesn't require much setup.

The attached patches first add  to Bash, then
replace Bash's by-hand overflow checking (which I think I
contributed a while ago, if memory serves) with uses of the
standard C23 macros, and finally fixes printf.  Although there
are several other integer overflow bugs in Bash I thought
I'd send these fixes in now.

These patches use the Gnulib files intprops-internal.h and
stdckdint.in.h unmodified.  I thought this would be better
than trying to simplify them to cover just Bash's needs, as
it will make it easier to sync with Gnulib later. However,
for simplicity these patches do not use all the Gnulib 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: Paul Eggert 
Date: Fri, 8 Mar 2024 21:58:46 -0800
Subject: [PATCH 1/4] maint: add support for C23-style stdckdint.h
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This is so that Bash can do proper checking for internal
integer overflow.  This change doesn't change Bash proper;
it only adds the minimum changes needed so that
C23-style "#include " will work portably
to older systems.
* Makefile.in (CREATED_CONFIGURE): Add stdckdint.h.
* configure.ac: Check for stdckdint.h.  If it works, remove
any stdckdint.h left over from a previous ‘configure’;
otherwise, create one.
* .gitignore: Add stdckdint.h.
* include/stdckdint.in.h, include/intprops-internal.h:
New files, copied verbatim from Gnulib.
---
 .gitignore  |   1 +
 Makefile.in |   1 +
 configure.ac|   7 +
 include/intprops-internal.h | 397 
 include/stdckdint.in.h  |  35 
 5 files changed, 441 insertions(+)
 create mode 100644 include/intprops-internal.h
 create mode 100644 include/stdckdint.in.h

diff --git a/.gitignore b/.gitignore
index 2c10177c..15b219d3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -70,6 +70,7 @@ support/bashbug.sh
 lsignames.h
 pathnames.h
 signames.h
+stdckdint.h
 version.h
 syntax.c
 stamp-h
diff --git a/Makefile.in b/Makefile.in
index 41443c6d..2b4b713c 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -584,6 +584,7 @@ CREATED_SUPPORT = signames.h recho$(EXEEXT) zecho$(EXEEXT) printenv$(EXEEXT) \
 		  mksyntax${EXEEXT} syntax.c $(VERSPROG) $(VERSOBJ) \
 		  buildversion.o mksignames.o signames.o buildsignames.o
 CREATED_CONFIGURE = config.h config.cache config.status config.log \
+		stdckdint.h \
 		stamp-h po/POTFILES config.status.lineno
 CREATED_MAKEFILES = Makefile builtins/Makefile doc/Makefile \
 		lib/readline/Makefile lib/glob/Makefile \
diff --git a/configure.ac b/configure.ac
index d4ca74e5..7befb6c2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -787,6 +787,7 @@ BASH_HEADER_INTTYPES
 
 AC_CHECK_HEADERS(unistd.h stdlib.h varargs.h limits.h string.h \
 		 memory.h locale.h termcap.h termio.h termios.h dlfcn.h \
+		 stdckdint.h \
 		 stdbool.h stddef.h stdint.h netdb.h pwd.h grp.h strings.h \
 		 regex.h syslog.h ulimit.h)
 AC_CHECK_HEADERS(sys/pte.h sys/stream.h sys/select.h sys/file.h sys/ioctl.h \
@@ -1352,4 +1353,10 @@ AC_CONFIG_FILES([Makefile builtins/Makefile lib/readline/Makefile \
 dnl Makefile uses this timestamp file to record whether config.h is up to date.
 AC_CONFIG_COMMANDS([stamp-h], [echo timestamp > stamp-h])
 
+if test "$ac_cv_header_stdckdint_h" = yes; then
+  rm -f stdckdint.h
+else
+  echo '#include ' >stdckdint.h
+fi
+
 AC_OUTPUT
diff --git a/include/intprops-internal.h b/inclu

Re: multi-threaded compiling

[Paul Smith]

On Tue, 2024-03-12 at 13:37 +0100, Mischa Baars wrote:
> > I'd still like to hear why you aren't simply using "make -j".
> 
> That's because I don't want to define static compile and link targets
> for every new project I start. The Makefile in question contains only
> a few lines of code and some environment variables, but works on
> every new project as long as you follow certain guidelines regarding
> the directory structure. It scans, compiles and links on the fly.

I don't find this argument compelling.  It's relatively straightforward
to create a makefile environment that "works on every new project as
long as you follow certain guidelines regarding the directory
structure" while still using parallel builds, that will "scan, compile,
and link" on the fly, using things like the wildcard function, pattern
rules, etc.

You are merely trading a bit of extra complexity in your makefile for a
whole lot of complexity and tricky hacking in bash, as can be seen by
following this thread.

But if you prefer to re-invent make's parallel build capabilities in
bash, certainly that's your prerogative.

Re: Bash printf should diagnose integer overflow

[Paul Eggert]

On 3/13/24 11:13, Chet Ramey wrote:


Thanks for the report. The most appropriate fix for this particular issue
is to display an error message if printf returns < 0, instead of
suppressing it unless the -v option has been set.


Oh, good point. This simplifies things a bit, though Bash still needs to 
do its own overflow checking for cases like "printf '%2147483648q' ''" 
and "printf '%*s' 2147483648 ''" when the Bash code itself is parsing 
the integer, rather than relying on printf(3) to do it.


Revised patchset attached. The first patch uses the fix you suggested; 
the remaining patches are similar to what I sent earlier, except the 
last one is simplified since it doesn't need to worry about inline width 
and precision when printf will do the checking. These patches are 
relative to Bash devel commit bf944fe91ffa97743ad86f6db6f3b84c78207a78 
dated today at 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 when
-v is not used, so that a shell command like
"printf '%1s' ''"
does not fail silently.
---
 builtins/printf.def | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/builtins/printf.def b/builtins/printf.def
index 49757f5c..b1140dc4 100644
--- a/builtins/printf.def
+++ b/builtins/printf.def
@@ -178,8 +178,7 @@ extern int errno;
 if (nw < 0 || (vflag == 0 && ferror (stdout))) \
   { \
 	QUIT; \
-	if (vflag) \
-	  builtin_error ("%s", strerror (errno)); \
+	builtin_error ("%s", strerror (errno)); \
 	PRETURN (EXECUTION_FAILURE); \
   } \
 tw += nw; \
-- 
2.44.0

From 21a3752666536f390f9d5d8378171a4323745adc Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Fri, 8 Mar 2024 21:58:46 -0800
Subject: [PATCH 2/5] maint: add support for C23-style stdckdint.h
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This is so that Bash can do proper checking for internal
integer overflow.  This change doesn't change Bash proper;
it only adds the minimum changes needed so that
C23-style "#include " will work portably
to older systems.
* Makefile.in (CREATED_CONFIGURE): Add stdckdint.h.
* configure.ac: Check for stdckdint.h.  If it works, remove
any stdckdint.h left over from a previous ‘configure’;
otherwise, create one.
* .gitignore: Add stdckdint.h.
* include/stdckdint.in.h, include/intprops-internal.h:
New files, copied verbatim from Gnulib.
---
 .gitignore  |   1 +
 Makefile.in |   1 +
 configure.ac|   7 +
 include/intprops-internal.h | 397 
 include/stdckdint.in.h  |  35 
 5 files changed, 441 insertions(+)
 create mode 100644 include/intprops-internal.h
 create mode 100644 include/stdckdint.in.h

diff --git a/.gitignore b/.gitignore
index 2c10177c..15b219d3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -70,6 +70,7 @@ support/bashbug.sh
 lsignames.h
 pathnames.h
 signames.h
+stdckdint.h
 version.h
 syntax.c
 stamp-h
diff --git a/Makefile.in b/Makefile.in
index 41443c6d..2b4b713c 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -584,6 +584,7 @@ CREATED_SUPPORT = signames.h recho$(EXEEXT) zecho$(EXEEXT) printenv$(EXEEXT) \
 		  mksyntax${EXEEXT} syntax.c $(VERSPROG) $(VERSOBJ) \
 		  buildversion.o mksignames.o signames.o buildsignames.o
 CREATED_CONFIGURE = config.h config.cache config.status config.log \
+		stdckdint.h \
 		stamp-h po/POTFILES config.status.lineno
 CREATED_MAKEFILES = Makefile builtins/Makefile doc/Makefile \
 		lib/readline/Makefile lib/glob/Makefile \
diff --git a/configure.ac b/configure.ac
index d4ca74e5..7befb6c2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -787,6 +787,7 @@ BASH_HEADER_INTTYPES
 
 AC_CHECK_HEADERS(unistd.h stdlib.h varargs.h limits.h string.h \
 		 memory.h locale.h termcap.h termio.h termios.h dlfcn.h \
+		 stdckdint.h \
 		 stdbool.h stddef.h stdint.h netdb.h pwd.h grp.h strings.h \
 		 regex.h syslog.h ulimit.h)
 AC_CHECK_HEADERS(sys/pte.h sys/stream.h sys/select.h sys/file.h sys/ioctl.h \
@@ -1352,4 +1353,10 @@ AC_CONFIG_FILES([Makefile builtins/Makefile lib/readline/Makefile \
 dnl Makefile uses this timestamp file to record whether config.h is up to date.
 AC_CONFIG_COMMANDS([stamp-h], [echo timestamp > stamp-h])
 
+if test "$ac_cv_header_stdckdint_h" = yes; then
+  rm -f stdckdint.h
+else
+  echo '#include ' >stdckdint.h
+fi
+
 AC_OUTPUT
diff --git a/include/intprops-internal.h b/include/intprops-internal.h
new file mode 100644
index ..c8a87d2b
--- /dev/null
+++ b/include/intprops-internal.h
@@ -0,0 +1,397 @@
+/* intprops-internal.h -- propert

Re: Bash printf should diagnose integer overflow

[Paul Eggert]

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 ran "make check" (equivalent to "make tests") and it looked to me like 
all the tests passed. The test output chattered a lot, and contained a 
lot of 'diff output', but then it did the same thing without the 
proposed patches and as far as I could tell nothing was unusual about 
the chatter. And since "make tests" exited with zero status, the tests 
appeared successful to me. Is there some documentation for how to 
interpret "make tests" output?


One thing that caused trouble for me is that I could not use the 
following shell command on my terminal:


  $ make tests >:tests.log 2>&1 < /dev/null &

because the tests would at some point stop in the background. Apparently 
some of the tests require access to the controlling terminal, which is a 
problem if you're trying to run them in the background. (Perhaps that 
explains why the tests succeeded for me but failed for you.)


I see that you're part way towards improving integer overflow checking, 
as you've added stdckdint.in.h to the devel branch but are not using 
stdckint.h yet. If there's any further way I can help to get integer 
overflow checking to work as well as my proposed patches tried to do, 
please let me know.

Re: Bash printf should diagnose integer overflow

[Paul Eggert]

On 3/18/24 12:41, Chet Ramey wrote:

I'm not sure what you're using, but that was not my experience on
macOS.


I am using Fedora 39 (the current version) on x86-64. That could explain 
our differing experiences.


I see several diagnostics (mostly diff output) with "make check" on 
Fedora 39. The diagnostics can vary from run to run, i.e., they aren't 
necessarily reproducible. I assumed these were OK because I got 'em 
before any patches. From my point of view the diff output was sort of 
random, so I eyeballed it and guessed which outputs mattered and which 
didn't. Apparently I guessed incorrectly with fw.


At some point I suppose it'd be nice if 'make check' succeeded (exit 
status 0) or failed (nonzero exit status) so that it is easy for 
non-experts to tell which diagnostics matter; that's what many other 
packages do. For now I'd rather focus on the integer overflow issues in 
Bash, while they're fresh in my mind.




First, the patched version doesn't build on macOS because your patches
don't include . Once you get past that, printf goes into an
infinite loop on

printf -v s "%b" ""

in printstr because `fw' is used unititialized (and randomly set to some
ridiculously large value). That and the old test's incorrect expectation
that a field width of 9223372036854775825 would always overflow to -1 (a
left-adjusted field width of 1) instead of being flagged as overflow are
the UB I was talking about.


Yes, I see now. I didn't get that behavior on Fedora, perhaps because 
the junk in fw was benign there.


Perhaps at some point we could enable more of GCC's static checking to 
catch silly mistakes like that. Again, a task for another time.




It should be mostly there in the changes I pushed today, once I made it
through the above.


Thanks, I checked the devel branch against what I submitted, found a few 
errors, and while reviewing all this found and fixed a few other 
integer-overflow issues in Bash. Proposed patches attached, in "git 
format-patch" format so you can use "git am" on them. If there'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-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* bashansi.h: If HAVE_C_BOOL, bool works as per C23, so
we needn’t include  or define any workarounds.
In pre-C99 compilers arrange for ‘false’ and ‘true’ as well;
although Bash doesn't use either symbol it's safer to
be compatible in case some system .h file unwisely uses it.
---
 bashansi.h | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/bashansi.h b/bashansi.h
index 4feaadfb..0bac61b4 100644
--- a/bashansi.h
+++ b/bashansi.h
@@ -35,13 +35,15 @@
 #  include "ansi_stdlib.h"
 #endif /* !HAVE_STDLIB_H */
 
-/* Prefer stdbool.h if we have it, maybe have to rethink this later */
-#if defined (HAVE_STDBOOL_H)
-#  include 
-#else
-#  ifndef HAVE_C_BOOL
+/* If bool is not builtin, prefer stdbool.h if we have it. */
+#ifndef HAVE_C_BOOL
+#  ifdef HAVE_STDBOOL_H
+#include 
+#  else
 #undef bool
 typedef unsigned char bool;
+#define false 0
+#define true 1
 #  endif
 #endif
 
-- 
2.44.0

From aeb21592ed88cac5072bcd41b2c478766d6e1dee Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Mon, 18 Mar 2024 13:54:29 -0700
Subject: [PATCH 02/10] Minor mkseq clarification/tuning
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* braces.c (mkseq): All branches of an if end in ‘result[i++] =
t;’, so hoist that out of the ‘if’.
---
 braces.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/braces.c b/braces.c
index 444807a7..194000c2 100644
--- a/braces.c
+++ b/braces.c
@@ -399,7 +399,7 @@ mkseq (intmax_t start, intmax_t end, intmax_t incr, int type, size_t width)
   QUIT;
 #endif
   if (type == ST_INT)
-	result[i++] = t = itos (n);
+	t = itos (n);
   else if (type == ST_ZINT)
 	{
 	  size_t tlen;
@@ -419,7 +419,6 @@ mkseq (intmax_t start, intmax_t end, intmax_t incr, int type, size_t width)
 		  memset (t + (n < 0), '0', width - tlen);
 		}
 	}
-	  result[i++] = t;
 	}
   else
 	{
@@ -428,9 +427,10 @@ mkseq (intmax_t start, intmax_t end, intmax_t incr, int type, size_t width)
 	  t[0] = n;
 	  t[1] = '\0';
 	}
-	  result[i++] = t;
 	}
 
+  result[i++] = t;
+
   /* We failed to allocate memory for this number, so we bail. */
   if (t == 0)
 	{
-- 
2.44.0

From 3c124056fbd07b31b259ec0fd87781d9a3ed4eed Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Mon, 18 Mar 2024 13:57:36 -0700
Subject: [PATCH 03/10] 

Re: Bash printf should diagnose integer overflow

[Paul Eggert]

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 
(b1e7f68032bd90dec1a2968a616b32a469929c78) on Fedora 39 running on bare 
hardware (AMD Phenom II X4 910e), with Fedora patches up through today 
and with 873 locales installed (output of "locale -a | wc"). Often "make 
check" output was the same, but sometimes it differed. Here's the first 
difference (after this I stopped checking):



$ diff -u :check[34].log
--- :check3.log 2024-03-21 14:09:48.069094929 -0700
+++ :check4.log 2024-03-21 22:39:51.391869014 -0700
@@ -327,6 +327,10 @@
 warning: UNIX versions number signals and schedule processes differently.
 warning: If output differing only in line numbers is produced, please
 warning: do not consider this a test failure.
+111c111
+< ./trap8.sub: DEBUG warning: run_pending_traps: recursive invocation while 
running trap for signal 17
+---
+> CHLD
 run-type
 run-varenv
 warning: some of these tests will fail if arrays have not


I recall other differences in past runs.



Output that differs in error message language isn't a failure.


Yes, and I assumed that since output like the above didn't affect the 
exit status of "make check", it wasn't that important.

Idle timer to trigger vlock?

[Paul Reilly]

Could someone point me in the right direction to understand how the TMOUT
variable is monitored, and logs out the session when it's expired?
I'm looking for a way to lock a users command session with vlock (or
similar) when they are idle for a user-defined time.
At the moment, I use TMOUT=7200 but this logs them out, which is
inconvenient. I just want to lock their session, requiring them to enter
their password to unlock the session, similar to how xscreensaver would do
if they were using a GUI.

Thanks
Paul

'exec

[Paul Eggert]

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' -DLOCALEDIR='/usr/local/cs/bash-4.2/share/locale' 
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -g -O2
uname output: Linux lnxsrvg1.seas.ucla.edu 2.6.18-274.7.1.el5 #1 SMP Mon Oct 17 
11:57:14 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu

Bash Version: 4.2
Patch Level: 10
Release Status: release

Description:
Bash can't do I/O redirection using 'exec' when operating
in an environment where all FDs above 10 are taken, even
if there are FDs available below 10.

This caused a coreutils test case to fail.  There is a
workaround, but the Bash bug should get fixed too.  See:
.

Repeat-By:
Run this command:

  bash -c 'ulimit -n 6; exec 

print function in /examples/functions/kshenv

[Paul Tibbitts]

This is not a bug in bash itself, but I was wondering if there are any
updates to the ksh-compatibility print function provided with bash in
the source distribution (in the examples/functions/kshenv file),
specifically with regards to ksh-compatible handling of -R.

Using ksh:

$ print -R -z
-z

Using bash 4.2.10 with the kshenv file:

$ print -R -z
bash: illegal option -- z

My understanding is that the -R should disable further option
processing except for -n, and display any additional arguments,
including those beginning with "-"

I have worked around the problem to some extent by modifying the
function, but was wondering if anyone has a more accurate/efficient/
official/distributed version.

Thanks.

Paul

Bash loops and otherwise mishandles long lines

[Paul Eggert]

Here's how to reproduce the problem:

(printf 'ln '
 perl -e 'print "x"x(2**31)'
 printf ' '
 perl -e 'print "x"x(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 report was inspired by the following report:

http://debbugs.gnu.org/13258

That bug report is against coreutils, but the real
bug was in bash, so I'm closing bug 13258 and forwarding
this to bug-bash@gnu.org.

Re: locale specific ordering in EN_US -- why is a

[Paul Eggert]

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 applications have awful workarounds for glibc's undesirable behavior."
So I'm afraid there is a point to changing modules outside glibc:
it strengthens the argument for changing glibc.

Re: stty settings override ~/.inputrc?

[Paul Jarc]

Chet Ramey <[EMAIL PROTECTED]> wrote:
> Readline, beginning with version 5.0, reads the stty special character
> settings and binds them to their readline equivalents each time
> readline() is called.  It reads ~/.inputrc once per `program'.

Suggestion: when reading .inputrc, update the stty settings to match
as closely as possible, so that re-reading the same stty settings for
the next command won't change anything.  That way, .inputrc wins
(persistently) over the original stty settings, but later changes to
stty settings still win over .inputrc.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: bash expr problem/bug... 0$val

[Paul Jarc]

[EMAIL PROTECTED] wrote:
>   #  a=500; b="0$[a]"; c=$[b]; echo -e "a: $a\nb: $b\nc: $c\n"
>   a: 500
>   b: 0500
>   c: 320

man bash, under ARITHMETIC EVALUATION:
   Constants with a leading 0 are interpreted as octal numbers.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

shared library installation

[Paul Jarc]

readline/shlib/Makefile uses INSTALL_DATA to install shared libraries.
INSTALL or INSTALL_PROGRAM would seem more appropriate; at least on
GNU/Linux, gcc creates shared libraries with the execute bit set, and
ldd warns if it is not set.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: failure in pipeline not reflected in $?

[Paul Jarc]

[EMAIL PROTECTED] wrote:
> If a command in a pipeline of commands fails, there appears to be no
> way of knowing this.

Check the man page regarding the PIPESTATUS array.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: pipeline outlives TERMed bash

[Paul Jarc]

Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> The problem is that svc -d (or manual kill -TERM)
> kills bash but nmeter and logger continue to run,
> until I kill nmeter manually.

It's best not to put a long-running pipeline in a daemontools run
script, for just this reason (among others).  Instead, move logger
into a separate /service/foo/log/run script.
http://cr.yp.to/daemontools/faq/create.html#runlog>

For more help with daemontools, try [EMAIL PROTECTED] or
[EMAIL PROTECTED]


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

coordinating bash and coreutils: which bash?

[Paul Eggert]

A few months ago we went through a POSIX-compatibility sweep of
coreutils, and in my nonexistent spare time I'd like to migrate some
of those fixes into the Bash builtins that duplicate coreutils.
Conversely, I'd like to migrate any fixes made by Bash in this area
into coreutils.

Which version of Bash should I use to do this?  I vaguely recall that
an alpha or beta version was released recently, but I can't find this
announcement on the Web, nor could I find recent sources when I poked
around in the obvious FTP or CVS places.

Thanks.


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: ansi escape sequences in prompt mess-up the command prompt

[Paul Jarc]

Antonis <[EMAIL PROTECTED]> wrote:
> Using ansi escape sequences in the prompt causes Bash to incorrectly
> calculate the available width of the terminal and messes-up the command
> prompt when a certain amount of characters are typed in.

See entry E3 in the bash FAQ.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: programmable auto completion with embedded ":" not working?

[Paul Jarc]

"fabien" <[EMAIL PROTECTED]> wrote:
>   when programming an auto-completion with embedded ":" in the
>   complete names, the auto-completion does not look good.

By default, ":" is treated like whitespace for completion, to help
when setting variables like $PATH.  Check the man page for
COMP_WORDBREAKS.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: error in math args?

[Paul Jarc]

Scott Dylewski <[EMAIL PROTECTED]> wrote:
> I get an error when running:
> echo $(( 008 / 2 ))

Numbers starting with 0 are interpreted as octal, and so can only use
digits 0-7.  You'll have to strip off the leading zeros to make the
number be interpreted as decimal.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: HERE document mystery

[Paul Jarc]

"Com MN PG P E B Consultant 3" <[EMAIL PROTECTED]> wrote:
> echo THIS DOES NOT WORK
> foo=$(cat exp_test < V=1234
> abcd
> BAD

0. Since you passed a file name to cat, it will ignore stdin.
1. Since the here-document belongs to the command in $(), the
   here-document must also be entirely inside $().  Move the closing )
   after "BAD".
2. [0-9]* matches every line, since * matches 0 or more occurrences.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Can't get the set-user-id bit to work

[Paul Jarc]

Sebastian Tennant <[EMAIL PROTECTED]> wrote:
> I have a 3-line script; foo:

The setuid bit works only for binaries, not scripts.  This is a
limitation of the kernel, necessary for security.

> A cron.daily script handles mandb.  I elected to install it with the
> set-user-id bit set, as you can see:

Is it meant to be installed that way?  If not, you probably shouldn't
do that.  It might break something, or introduce a security risk.

> it certianly shouldn't have any trouble creating it in /tmp:
>
>   drwxrwxr-x  13 root root 4096 Dec 27 16:50 /tmp

With those permissions, only the root user and root group can create
files in /tmp.  To allow all users to create files there, make it
world-writable and sticky:
# chmod 1777 /tmp
# ls -ld /tmp
drwxrwxrwt  13 root root 4096 Dec 27 16:50 /tmp


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Can't get the set-user-id bit to work

[Paul Jarc]

Sebastian Tennant <[EMAIL PROTECTED]> wrote:
> OK, but mandb _is_ a member of the root group, so shouldn't it be able
> to write files in /tmp with the permissions as they stand?

No, you'd have to make it setuid to root, or setgid to the root
group.  The user/group associations in /etc/passwd and /etc/group
aren't involved.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: "echo: write error: Broken pipe" even when DONT_REPORT_SIGPIPE set

[Paul Jarc]

Chet Ramey <[EMAIL PROTECTED]> wrote:
> `echo' now displays an error message on write errors.

In the case of a SIGPIPE trap, is it intended that echo sees EPIPE
before the SIGPIPE handler runs?


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Conditional expression problem: both "-a file" and "! -a file" return true

[Paul Jarc]

Eric Blake <[EMAIL PROTECTED]> wrote:
> But the RATIONALE (XCU line 35443) states that "The ! operator has higher
> precedence than the -a operator, and the -a operator has higher precedence
> than the -o operator."  Therefore, when -a is defined as a unary operator,
> an XSI compliant test is required to return failure for "test ! -a file"
> if file exists.  Bash got this wrong, so indeed it is a bug.

No, I think that quote only says that this:
  ! 1 -a 2
is the same as this:
  ( ! 1 ) -a 2
and not this:
  ! ( 1 -a 2 )

It doesn't give us any guidance for deciding whether ! is an operator
or operand in any particular case.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: can't expand after colon

[Paul Jarc]

Dan Jacobson <[EMAIL PROTECTED]> wrote:
> Must one use \: to make this work?

That, or adjust $COMP_WORDBREAKS to not include ":".


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Possible bash bug when dealing with CR/LF in variable expansion

[Paul Jarc]

"Johannes Thoma" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED]:~/bash/bash-3.1$ zak=`printf '\x0d\x0a'`

As documented in the man page under "Command Substitution", this
strips off any trailing newlines from the program's output before
assigning the variable's value.  So zak contains only a carriage
return here.

> [EMAIL PROTECTED]:~/bash/bash-3.1$ echo $zak | od -t x1
> 000 0d 0a
> 002

echo adds a newline at the end of its output.  Even if zak had a
newline, since it's unquoted, that newline would be removed.

> [EMAIL PROTECTED]:~/bash/bash-3.1$ zak="${zak}karin"
> [EMAIL PROTECTED]:~/bash/bash-3.1$ echo $zak | od -t x1
> 000 0d 6b 61 72 69 6e 0a
> 007

Again, the newline comes from echo, not from zak.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: exit somtimes not exit's the script

[Paul Jarc]

[EMAIL PROTECTED] wrote:
>   a exit inside a loop inside a pipe exits's the loop and not the
>   script. may bee a error.

This is normal.  Each element of a pipeline is run in a child process.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: problem ? bug ?

[Paul Jarc]

[EMAIL PROTECTED] wrote:
> [kaneda<-ogorasek]~$if [ ! -a /etc/passwd ] ; then echo si ; fi

-a is used as a binary "and" operator here.  The expressions "!" and
"/etc/passwd" are nonempty strings, so both are considered true, and
the overall result is true.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: eval in functions in pipelines doesn't set variables globally

[Paul Jarc]

[EMAIL PROTECTED] wrote:
>   Normally, the eval builtin used in functions to set variables
>   makes these variables available globally otutside the function.
>   However, when the function gets input from a pipline, the variables
>   are set only locally.

Read the bash FAQ, entry E4.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: BUG: ls -ld directory/

[Paul Jarc]

G C McNeil-Watson <[EMAIL PROTECTED]> wrote:
> If you do an
>
>  ls -ld directory/
>
> for some existing directory then the output contains TWO trailling
> slashes:
>
>  drwx--  2 pypgcm users 4096 Aug 16  2005 directory//
>
> The directory and the first slash appear in blue on my terminal, trailing
> slash in black.

You probably have ls aliased to 'ls -F', or some combination of
options that includes -F.  (Check with "alias ls".)  Read the
documentation for ls to see if there is a different combination of
options that gives you the behavior you want.  If you can't find it,
you can write to bug-coreutils@gnu.org to submit a feature request.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: trap handler scope wrong?

[Paul Jarc]

Phillip Susi <[EMAIL PROTECTED]> wrote:
> Chet Ramey wrote:
>> That's about right, but you need >&3 in the trap command.
>
> I did have > &3 in the trap command, see?

You have "> &3".  You need ">&3", without a space.

> I'm a bit worried though about hard coding the fd 3.  Is there a way
> to get the next available fd number and save it in a variable,
> rather than hard code 3?

Unfortunately, no.  You could use a higher number, which would be less
likely to be used, but if you want to be portable to other shells, you
can only go up to 9.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: How to suppress async messages for background jobs

[Paul Jarc]

Francesco Montorsi <[EMAIL PROTECTED]> wrote:
>   [EMAIL PROTECTED]:~$ kwrite &
> =>[1] 20986
>   [EMAIL PROTECTED]:~$
> =>[1]+  Donekwrite
>   [EMAIL PROTECTED]:~$
>
> is there a way to tell bash not to print those lines marked with => ?

If you don't need to refer to the process as %1, etc.:
$ ( kwrite & )

I have this in my .bashrc to I can use alt-Enter to run something in
the background without keeping track of it as a shell job:
bind $'Meta-RET: "\001(\005&)\r"'


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: document that echo can't be given a NULL

[Paul Jarc]

Dan Jacobson <[EMAIL PROTECTED]> wrote:
> No way to hand echo or /bin/echo a NULL.

For /bin/echo, that's because execve() uses null-terminated strings.
For bash's builtin echo, it could be done, but then it would be
inconsistent with external commands, which might be surprising.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Using variables in variables names

[Paul Jarc]

"Dirk H. Schulz" <[EMAIL PROTECTED]> wrote:
>> ac=12  dings$ac=wasannersder
>> -bash: dings12=wasannersder: command not found

Variable names in assignments are not subject to expansion.  So since
"dings$ac", as-is, does not fit the syntax for variable names, it
isn't treated as an assignment.  This will work:
ac=12 eval "dings$ac=wasannersder"


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Using variables in variables names

[Paul Jarc]

"Dirk H. Schulz" <[EMAIL PROTECTED]> wrote:
> Paul Jarc schrieb:
>> ac=12 eval "dings$ac=wasannersder"
>
> And how do I reference it then?

ac=12 eval "value=\$dings$ac"
echo $value

Or:

ac=12 name=dings$ac echo ${!name}


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Question about variables and for loop

[Paul Jarc]

Bob <[EMAIL PROTECTED]> wrote:
>   XXX='a "b c" d'
>   for x in $XXX ; do
>   echo $x
>   done

XXX='a "b c" d'
eval "set $XXX"
for x in "$@" ; do
echo $x
done

If the first element in XXX might start with "-", then it takes a
little more work to ensure it isn't misinterpreted as an option to
"set":
eval "set x $XXX"
shift


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

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

[Paul Eggert]

Henrik Nordstrom <[EMAIL PROTECTED]> writes:

> sön 2006-03-19 klockan 12:57 -0800 skrev Paul Eggert:
>
>> Autoconf deals with shells that do not conform to XSI, and where the
>> results are implementation-defined if there's a backslash anywhere in
>> the string, so to some extent this point is moot for Autoconf (though
>> it's undeniably a portability problem, one that is documented in the
>> Autoconf manual under "Limitations of Builtins").
>
> I thought so too, but in this case it is a autoconf 2.57 output which is
> failing, ending up with a lot of control characters instead of the
> expected sed backreferences..

Autoconf 2.57 is pretty old.  Do you have the same problem with 2.59?
If not, then the problem's solved from the Autoconf point of view.
Otherwise, I'd ask you to try it with CVS Autoconf (which has further
fixes in this area).


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Grouped pipeline clobbering question

[Paul Jarc]

Phillip Susi <[EMAIL PROTECTED]> wrote:
> cat file | ( head --lines=1 ; sed -e x )
>
> I thought that head should consume the first line from the pipe, leaving 
> the rest queued for sed to consume, but this does not seem to be the 
> case.

head may read an arbitrary amount of data from the pipe, although it
will print only as much as you tell it to.  To get the behavior you
want, you'll have to duplicate head's behavior in sed:

cat file | sed -e '1,10{p;d;}' -e x

And in this case, cat is unnecessary too:

sed -e '1,10{p;d;}' -e x < file


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

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

[Paul Eggert]

Andreas Schwab <[EMAIL PROTECTED]> writes:

> But note that bash interprets -n as an option, which is not compliant with
> XSI.

Bash doesn't claim conformance to XSI, so that's OK as far as Bash is
concerned.  Autoconf (and I assume Squid) is supposed be portable to
all POSIX hosts, not merely POSIX+XSI hosts, so it should work with
Bash; so this is still a bug in either Autoconf or Squid, not in Bash.

There's a little history here.  POSIX 1003.2-1992 said that echo has
implementation-defined behavior if given any options, or if any
operands contain '\'.  This allows both traditional (echo -n) and
System V (backslash) interpretation.

SUSv2 came down squarely on the System V side.

But the BSD folks revolted on this, and POSIX 1003.1-2001 reverted to
the POSIX 1003.2-1992 spec, with the compromise of putting the System
V stuff into the XSI ghetto.


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

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

[Paul Eggert]

Linda W <[EMAIL PROTECTED]> writes:

> I believe bash is broken in regards to using "any" number after
> "\" as an octal value.  The shell specifications require the leading
> zero for an octal constant

I'm afraid this is backwards.  This POSIX+XSI requirement constrains
applications, not implementations.

POSIX requires that if an application wants an octal escape for (say)
the character with octal code 123, it must execute "echo '\0123'".  If
an application executes "echo '\123'" (without the "0"), POSIX says
that the results are implementation-defined.  Hence Bash can interpret
\123 as an octal escape as well, if it so chooses, and still conform
to POSIX+XSI.  A similar analysis applies to \x escapes.

For details, please see .

Autoconf deals with shells that do not conform to XSI, and where the
results are implementation-defined if there's a backslash anywhere in
the string, so to some extent this point is moot for Autoconf (though
it's undeniably a portability problem, one that is documented in the
Autoconf manual under "Limitations of Builtins").


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

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

[Paul Eggert]

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 1003.2-1992, and it has
different wording in this area.

Quite a zoo, huh?


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: bash ignoring .inputrc (or am I dumb)

[Paul Jarc]

William Yardley <[EMAIL PROTECTED]> wrote:
> I would still like to know if there's a way to bind ^W to
> backward-kill-word within bash, so if anyone has suggestions, I'd
> appreciate them.

Check out the "bind" builtin command in the man page or "help bind".


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: pattern matching: range expression

[Paul Jarc]

Wolf-Rainer Novender <[EMAIL PROTECTED]> wrote:
> e.g. ls [A-Z]* should yield in all names starting with capital letters.
> Does not work! I get >>all<< names!

http://www.gnu.org/software/coreutils/faq/#Sort-does-not-sort-in-normal-order_0021


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Selinux bash prompt decorations

[Paul Jarc]

Steve Grubb <[EMAIL PROTECTED]> wrote:
> On Tuesday 04 April 2006 15:51, Chet Ramey wrote:
>> How about commands whose output may be assigned to shell variables?
>
> Yes, they can be acquired in a number of ways. But what we are trying to do 
> is 
> set things up so that people using this in a classified environment have an 
> easy way to see what the session is running at.

You can put the information in PS1 without bash having special
functionality for getting it.
selinux_user=`...`
PS1='$selinux_user...'


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: test -f with no args is true

[Paul Jarc]

Charlie Bennett <[EMAIL PROTECTED]> wrote:
> Is this expected behavior?
>
> [EMAIL PROTECTED] .ssh]# [ -f  ]
> [EMAIL PROTECTED] .ssh]# echo $?
> 0

Yes.  A single argument is considered true if it is not the mepty
string, even if it happens to coincide with the spelling of an
operator.  This is how all shells behave, and what POSIX/SUS says they
should do.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: unwanted expansion of variable with nested strings

[Paul Jarc]

Mike Frysinger <[EMAIL PROTECTED]> wrote:
> $ foo="a b c"
> $ gawk 'BEGIN {foo="'${foo}'"}'
> gawk: BEGIN {foo="a
> gawk:^ unterminated string

This is normal.  man bash:

#   Word Splitting
#   The  shell  scans the results of parameter expansion, command substitu-
#   tion, and arithmetic expansion that did not occur within double  quotes
#   for word splitting.

> so if i quote ${foo} like so:
> $ gawk 'BEGIN {foo="'"${foo}"'"}'
> it'll work in this case, but then fail if foo contains newlines:
> foo="a
> b
> c"

What do you mean by "fail"?  What do you want to happen in this case?


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: unwanted expansion of variable with nested strings

[Paul Jarc]

Mike Frysinger <[EMAIL PROTECTED]> wrote:
> On Thursday 04 May 2006 00:44, Paul Jarc wrote:
>> What do you mean by "fail"?  What do you want to happen in this case?
>
> i meant gawk hates it ... not bash

Ok, and what about the second question?  What are you trying to do
that you haven't figured out how to do?


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Selinux bash prompt decorations

[Paul Jarc]

Steve Grubb <[EMAIL PROTECTED]> wrote:
> Its not poor practice to make something usable for people.
...
> For the moment, we are going the route of doing this via `id -Z`. But I 
> thought there was a common problem across secure distributions that we could 
> create a standard for. TSOL could link to its libraries, RHEL could link to 
> libselinux, etc.

Having a common interface to all of these libraries would be good.
But adding new mechanisms to other programs to use those libraries,
when they can just as easily get to the same functionality via
existing mechanisms like command substitution, is not good.
Interdependencies should be kept to a minimum, and pushed to as high a
level as possible.  Instead of modifying bash to call some
standardized get_security_role() function, put a standardized
`get-security-role` command in PS1.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: How to use [[ string =~ regexp ]]?

[Paul Jarc]

Peter Volkov <[EMAIL PROTECTED]> wrote:
> $ [[ "string" =~ "[a-z]" ]] && echo something
> something

[a-z] matches only one charater, but the pattern is not required to
match against the entire string.  You can force it to match the whole
string by using "^" to anchor the pattern to the beginning of the
string, and "$" to anchor it to the end:
[[ string =~ ^[a-z]$ ]]


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: here document and STDIN

[Paul Jarc]

"Cai Qian" <[EMAIL PROTECTED]> wrote:
> For following code,
>
> sh <   read
> EOF
>
> I have no idea why will not block.

The "read" command reads from the shell's stdin, which is the here
document.  At the point where the "read" command is executed, the
shell has already read the "read" command from the here document, so
the next thing read from there will be end-of-file.  If you want the
"read" command to read from the original stdin that was present before
the here document was introduced, you can copy it to another
descriptor:

sh < So I can run some Perl code inside like,
>
> perl - <<'EOF'
>  X
>
> EOF

With perl, it may be easier to use -e instead of a here document:
perl -e '
    X
'

Then perl will still be connected to the original stdin, without any
need for duplicating descriptors.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: here document and STDIN

[Paul Jarc]

I wrote:
> sh < read <&3
> EOF

Sorry, that first line should be:
sh 3<&0 

Re: here document and STDIN

[Paul Jarc]

"Cai Qian" <[EMAIL PROTECTED]> wrote:
> The information is helpful. The problem by using
>
> perl -e '
>X
> '
>
> is that there seems no way to using single quota in Perl code any more.

It's not very concise, but you can do this:

perl -e '
... '\'' ...
'

>From the shell's point of view, this is a single-quoted string,
adjacent to a backslash-escaped single quote, adjacent to another
single-quoted string.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: EOF does not work in echo

[Paul Jarc]

"Cai Qian" <[EMAIL PROTECTED]> wrote:
> It suggests that "cat" has not seen EOF (004) generated by echo.

The character 004 is not EOF.

When typing at a terminal which is set to "cooked" mode, you use the
keystroke control-D to tell the terminal driver that it should send
EOF to the program reading from the terminal.  Control-D is also used
in other contexts (such as typing at a terminal in "raw" mode) to
produce the character 004.

In the case of a pipe, a reader will not see EOF until all writers
have closed the pipe (typically when they exit).


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Aliases fail in command substitution in noninteractive mode.

[Paul Jarc]

[EMAIL PROTECTED] wrote:
>   Aliases don't work correctly in command substitution when in 
>   noninteractive mode. They do work when in interactive mode.

man bash, under "ALIASES":
   Aliases are not expanded when the shell is not interactive, unless  the
   expand_aliases  shell option is set using shopt (see the description of
   shopt under SHELL BUILTIN COMMANDS below).


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Bash expansion nuance or bug?

[Paul Jarc]

Linda Walsh <[EMAIL PROTECTED]> wrote:
> Two aliases:
>alias ls='ls -CFG --show-control-chars --color=tty '
>alias dir='ls'
>
> If I type "ls dir" (created a test dir called dir), I
> get:
>"ls dir"
> I get:
>ls: ls: No such file or directory.

man bash, under ALIASES:
# If the last character of the alias value is a blank, then the next
# command word following the alias is also checked for alias
# expansion.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: while do done has problems with global variables

[Paul Jarc]

[EMAIL PROTECTED] wrote:
>ls -1  | while read f; do

Read entry E4 in the bash FAQ.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: terminating lines with accidental eof

[Paul Jarc]

[EMAIL PROTECTED] (Martin Wheatley) wrote:
> (ie commands are only executed when the user hits enter and NOT
> executed when an I/O error occurs on the input stream).

EOF is not an error.  If there is an error, then certainly bash should
not execute an partial command it has buffered, but that won't affect
your situation, since you only have EOF, not an error.

> Linking /bin/sh to /bin/bash does NOT maintain the bourne shell API.

This is well known.  I don't think Bob was recommending that you do
that.  He was just pointing out that many systems do it, and so your
statement of what /bin/sh does was ambiguous since you had not
specified which /bin/sh you're using.

> command history browsing must, similarly, present "commented"
> commands in case thay are executed as a result of this issue.

Has anyone verified that this happens for history browsing?


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: automatic code generation

[Paul Jarc]

box <[EMAIL PROTECTED]> wrote:
> void ${NAME}Panel::showEvent(QShowEvent *e) {
> ...code
> }
>
> I want to be able to run my script, have it read the contents of the files
> while replacing ${NAME} with a variable that is defined elsewhere in my
> script.

NAME=...
eval "cat < output-file


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Python and Bash

[Paul Jarc]

"Andrew Kezys" <[EMAIL PROTECTED]> wrote:
> So, when I'm running the shell script that calls on this python script
> and end it with ctrl-c, it only ends the shell script, and not the
> python script, which continues putting serial data to a file.

Ctrl-C should be sending SIGINT to both bash and python.  python will
process SIGINT by throwing a KeyboardInterrupt exception.  Have you
checked to see how that exception is handled in your script?  If it's
begin caught and ignored, that's the best place to fix it.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: !* goofs here-strings

[Paul Jarc]

mwoehlke <[EMAIL PROTECTED]> wrote:
> I thought the syntax was only two '<'s?

"<<" gives you a here-document. "<<<" gives you a here-string.  Check
the man page for details.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: null command and parameter expansion for "Display error if null or unset"

[Paul Jarc]

"Dave Rutherford" <[EMAIL PROTECTED]> wrote:
> On 7/31/06, Poor Yorick <[EMAIL PROTECTED]> wrote:
>> : ${FAKEVAR?} || echo hello
>
> Try this and then run your script:
>
> export FAKEVAR="echo This could have been rm -rf $HOME"

That won't do anything.  The contents of $FAKEVAR, if any, are just
passed as arguments to :, which does nothing.  Since the expansion
isn't quoted, word splitting and pathname expansion are applied -
that's extra useless work, but not harmful.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: null command and parameter expansion for "Display error if null or unset"

[Paul Jarc]

mwoehlke <[EMAIL PROTECTED]> wrote:
> Poor Yorick wrote:
>> The following line does not perform the "echo" command.
>> : ${FAKEVAR?} || echo hello
>
> What you probably want is:
> [ "$FAKEVAR" ] || echo hello

That doesn't distinguish between an unset variable and a variable set
to an empty value.  If that distinction is important, you can use:
test "${FAKEVAR+set}" = set

You can also wrap it up in a function for convenience:
is_set() {
  eval "test \"\${${1?}+set}\" = set"
}


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: unable to capture return value using backticks and local

[Paul Jarc]

"Adam Monsen" <[EMAIL PROTECTED]> wrote:
> foo()
> {
>local TICKED=`false`
>echo RV: $?
> }
>
> foo
> # prints "RV: 0", but I would expect "RV: 1"

You get 0 here because that's the status from the "local" command.  To
get the status from a backtick command, you need the assignment to be
alone, not part of another command:
foo()
{
  local TICKED
  TICKED=`false`
  echo RV: $?
}


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Bug with 'test' built-in.

[Paul Jarc]

John Wenker <[EMAIL PROTECTED]> wrote:
>   The following construct _always_ evaluates true, regardless of
>   whether the file exists or not.
>
>  if [ ! -a file ]; then
> echo "This line always prints no matter what."
>  else
> echo "This line never prints."
>  fi

-a can act as a prefix unary operator, or an infix binary "and"
operator.  When it appears as the second of three arguments (not
counting "]") in a test, it's treated as a binary operator, even if
the first argument is "!".  So in this case, "!" is test, and as a
single string it's only tested for non-emptiness, and so is considered
true.  Likewise for "file".  Since both subtests are true, the
combined "and" test is also true.

There are a few different ways to get the behavior you want.  You
could use "[ ! \( -a file \) ]" or "! [ -a file ]", although those are
not portable to some other shells.  (The behavior of a test is
generally more predictable when there are fewer arguments, so I'd go
with the second of those two, since it pulls the "!" outside the test
and leaves only two arguments for the test to examine.)  You could
also remove "!" and switch your "then" and "else" clauses, which works
with any shell.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash