built-in printf returns success when integer is out of range
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux fnord42 6.1.25-1rodete1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.25-1rodete1 (2023-05-11) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.2 Patch Level: 15 Release Status: release Description: printf '%d\n' 111 && echo success prints "success" /usr/bin/printf does not, but instead returns EXIT_FAILURE (1). Repeat-By: Run: printf '%d\n' 111 && echo success
Re: built-in printf returns success when integer is out of range
On Wed, 26 Jul 2023 21:52:32 +0100, Dennis Williamson
said:
>> Configuration Information [Automatically generated, do not change]:
>> Machine: x86_64
>> OS: linux-gnu
>> Compiler: gcc
>> Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat
>> -Werror=format-security -Wall
>> uname output: Linux fnord42 6.1.25-1rodete1-amd64 #1 SMP
>> PREEMPT_DYNAMIC Debian 6.1.25-1rodete1 (2023-05-11) x86_64 GNU/Linux
>> Machine Type: x86_64-pc-linux-gnu
>>
>> Bash Version: 5.2
>> Patch Level: 15
>> Release Status: release
>>
>> Description:
>> printf '%d\n' 111 && echo success
>> prints "success"
>> /usr/bin/printf does not, but instead returns EXIT_FAILURE (1).
>>
>> Repeat-By:
>> Run:
>> printf '%d\n' 111 && echo success
>>
>>
> You didn't include all the output. It's treated as a warning rather than an
> error. That's why an error status isn't set.
Ah indeed, the stderr message with bash builtin has the word
"warning", whereas the Linux coreutils one does not[1].
Regardless, I do not believe this should be a warning, and instead
that coreutils is doing the right thing, and bash is not.
The builtin was given a request to print an integer. It failed to do
that, because of invalid input. It's wrong to silently do the wrong
thing. I say silently, but what I mean is without a way to handle
the error, not that stderr didn't get any warning.
Scripts can be unattended, and they should fail if they fail, not
continue with best effort.
Not that 2^63-1 is any kind of best effort.
Bash built-in printf should fail (EXIT_FAILURE) on the integer out of
range just like it does fail given something that's not a number at
all.
[1]
$ printf '%d\n' 111 && echo yes || echo no
bash: printf: warning: 111: Numerical result out of range
9223372036854775807
yes
$ /usr/bin/printf '%d\n' 111 && echo yes || echo no
/usr/bin/printf: ‘111’: Numerical result out of range
9223372036854775807
no
--
typedef struct me_s {
char name[] = { "Thomas Habets" };
char email[] = { "tho...@habets.se" };
char kernel[]= { "Linux" };
char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt"; };
char pgp[] = { "9907 8698 8A24 F52F 1C2E 87F6 39A4 9EEA 460A 0169" };
char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" };
} me_t;
recalculate LINES and COLUMNS
Hi list, Sometimes I want to change the font of my terminal (urxvt): for instance, I am tired and want a bigger font. I can use a bash alias (or a keyboard shortcut) which runs these two lines: printf '\e]710;%s\007' 'xft:DejaVu Sans Mono:size=10' kill -WINCH $$ Font is changed but the second line seems to have no effect: bash does not recompute the values of COLUMNS and LINES, thus I may type "outside urxvt's window". There is a "checkwinsize" option but it does not seem to help. If I manually resize the window, the problem is fixed. How can I send a WINCH signal to bash so that it recalculates the correct values of LINES and COLUMNS after a font change? Thanks Thomas
Cannot build statically linked, working bash
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: /usr/gcc/bin/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/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -m64 -march=native -O3 -fomit-frame-pointer uname output: Linux sarkovy 2.6.31 #4 PREEMPT Tue Sep 15 23:48:23 CEST 2009 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.0 Patch Level: 35 Release Status: release Description: I failed at building a statically linked, working bash. First of all, the only way to build is by giving the '--with-bash-malloc=no' argument to configure, because otherwise the linker will complain about multiple definitions of 'malloc' and 'free', which of course are present in libc. Even so, the binary resulting from the build will crash during startup, inside the getpwuid() function. I found a mail thread that describes a similar problem for bash-3.2 on Solaris http://lists.gnu.org/archive/html/bug-bash/2008-10/msg00011.html. Like the reporter, I configured my system to use LDAP for authentication. Only if I run bash as the root user, which is a local account outside the ldap directory, there is no crash and it appears to work. As a temporary workaround, I am currently using a dynamically linked bash. Repeat-By: bash-4.0$ ./config.status --version bash config.status 4.0-release configured by /home/thomas/src/bash-4.0/configure, generated by GNU Autoconf 2.63, with options "'--prefix=/usr' '--exec-prefix=' '--enable-static-link' '--with-curses' '--with-bash-malloc=no' 'CC=/usr/gcc/bin/gcc' 'CFLAGS=-pipe -O3 -fomit-frame-pointer -march=native -m64' 'LDFLAGS=-O3 -Wl,--enable-new-dtags,--hash-style=gnu' 'CPP=/usr/gcc/bin/cpp'"
Pleac:
Hi, bash has only 0.43% examples at the pleac project. Pleac is the perl cookbook translated to other languages. It would be nice if someone could improve it: http://pleac.sourceforge.net/ Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de
Corrupt prompt string using '\W' within PS1
From: oe6...@gmx.at
To: bug-bash@gnu.org
Subject: Corrupt prompt string using '\W' within PS1
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/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include
-I./lib -g -O2
uname output: Linux gold 2.6.32-5-amd64 #1 SMP Fri Dec 10 15:35:08 UTC
2010 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.1
Patch Level: 9
Release Status: release
Description:
Corrupt prompt string using the backslash-escaped special character
'\W'
Repeat-By:
When executing interactively bash displays the following sequence:
bash-4.1$ cd /
bash-4.1$ PS1="\W \$ "
/ $ cd home
hmee $ cd /media
meiia $
Fix:
Inside 'y.tab.c' the use of strcpy is in undefined behavior.
The 't_string' and 't' objects overlaps. Using the memmove,
copying takes place as if an intermediate buffer was used,
allowing the destination and source to overlap.
Regards,
Thomas Kuschel, oe6tkt
--- old/y.tab.c2009-12-30 18:52:02.0 +0100
+++ y.tab.c2011-02-11 12:36:45.682266575 +0100
@@ -7481,7 +7481,10 @@ decode_prompt_string (string)
{
t = strrchr (t_string, '/');
if (t)
- strcpy (t_string, t + 1);
+ /* strcpy: If copying takes place between objects that
overlap,
+ the behavior is undefined.
+strcpy (t_string, t + 1); so changed to: */
+ memmove (t_string; t + 1, strlen (t));
}
}
#undef ROOT_PATH
--- old/y.tab.c 2009-12-30 18:52:02.0 +0100
+++ y.tab.c 2011-02-11 12:36:45.682266575 +0100
@@ -7481,7 +7481,10 @@ decode_prompt_string (string)
{
t = strrchr (t_string, '/');
if (t)
- strcpy (t_string, t + 1);
+ /* strcpy: If copying takes place between objects that overlap,
+ the behavior is undefined.
+strcpy (t_string, t + 1); so changed to: */
+ memmove (t_string; t + 1, strlen (t));
}
}
#undef ROOT_PATH
edit-and-execute-command is appropriately named, weird
Hi all, In using bash over the years, I've been quite happy to be able to hit ctrl-x ctrl-e to pull up an editor when my input has grown too complicated. When using read -e for input, however, the behavior I find makes a lot less sense: the input line is still opened in an editor, but the result is not processed by read - it is executed by bash. While a means to escape to the shell can certainly be useful it seems like it should generally be done in a more controlled environment. It is much harder to reason about my scripts when arbitrary variables might be overwritten just because I asked for input. In any case I'm not sure it makes sense to conflate this with the "open this line in an editor" command. I'm curious as to the reasoning was behind this behavior (if it was intentional), and whether I'm likely to break anything if I "fix" it. Thanks!
Re: edit-and-execute-command is appropriately named, weird
Hi Chet,
Thank you for the response, and the attempt at assistance.
I was unaware of the POSIX specifications relating to editing modes.
After reading the specs, however, I don't think they conflict with
what I propose. While the description of the [count]v command does
say that it executes the commands in the temporary file, this cannot
be required to apply to line editing in the read builtin when run with
the -e option, as the -e option is not described in the specification
of read at all and so its behavior is up to the developers here to
define.
Note that I am not proposing "edit and keep in buffer" semantics (as
you provided an example of below, and which would clearly conflict
with the standard), but rather "edit and accept" which results in
conformant behavior at the command prompt when the accepted line is
then processed as a shell command.
In the short term, I was able to get the behavior I want by overriding
fc in the script in question, but I still think default behavior is
ugly.
Thanks again for the response, and I'm interested in your further thoughts.
- David
On Thu, May 26, 2011 at 9:09 AM, Chet Ramey wrote:
> On 5/23/11 1:05 PM, David Thomas wrote:
>> Hi all,
>>
>> In using bash over the years, I've been quite happy to be able to hit
>> ctrl-x ctrl-e to pull up an editor when my input has grown too
>> complicated.
>>
>> When using read -e for input, however, the behavior I find makes a lot
>> less sense: the input line is still opened in an editor, but the
>> result is not processed by read - it is executed by bash. While a
>> means to escape to the shell can certainly be useful it seems like it
>> should generally be done in a more controlled environment. It is much
>> harder to reason about my scripts when arbitrary variables might be
>> overwritten just because I asked for input. In any case I'm not sure
>> it makes sense to conflate this with the "open this line in an editor"
>> command.
>
> That editing command exists because Posix standardizes it for vi editing
> mode. (Posix declined to standardize emacs editing mode at all.) It was
> useful to expose the same behavior when in emacs mode.
>
> If you want an `edit-in-editor' command that just replaces the readline
> editing buffer with the edited result, you should be able to write a shell
> function to do that and use `bind -x' to make it available on any key
> sequence you want (modulo the current restrictions on bind -x, of course).
>
> Something like this:
>
> edit_in_editor()
> {
> typeset p
> local TMPF=/tmp/readline-buffer
>
> p=$(READLINE_POINT}
> rm -f $TMPF
> printf "%s\n" "$READLINE_LINE" > "$TMPF"
> ${VISUAL:-${EDITOR:-emacs}} $TMPF && READLINE_LINE=$(< $TMPF)
> rm -f $TMPF
> READLINE_POINT=0 # or p or ${#READLINE_LINE} or ...
> }
>
> Salt to taste.
>
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
>
Re: edit-and-execute-command is appropriately named, weird
Oh, I wasn't asking you to do it, I was volunteering to. I just wanted to be sure there wasn't some overriding reason it was done the way it was, and that there wouldn't be too many people relying on the present behavior. As it is, I think I'll be taking a swing at it once my home internet is hooked up (which should be any day now...). On Sat, May 28, 2011 at 3:42 PM, Chet Ramey wrote: > On 5/27/11 6:20 PM, David Thomas wrote: >> Hi Chet, >> >> Thank you for the response, and the attempt at assistance. >> >> I was unaware of the POSIX specifications relating to editing modes. >> After reading the specs, however, I don't think they conflict with >> what I propose. While the description of the [count]v command does >> say that it executes the commands in the temporary file, this cannot >> be required to apply to line editing in the read builtin when run with >> the -e option, as the -e option is not described in the specification >> of read at all and so its behavior is up to the developers here to >> define. > > Quite true: it doesn't strictly apply to read -e or to emacs editing mode > at all. However, the specification is well-suited to being implemented > using `fc', which is also specified by Posix. It's also never seemed > important enough to disable that particular command when running > `read -e'. > >> Note that I am not proposing "edit and keep in buffer" semantics (as >> you provided an example of below, and which would clearly conflict >> with the standard), but rather "edit and accept" which results in >> conformant behavior at the command prompt when the accepted line is >> then processed as a shell command. > > That's probably true, but not quite how it works. The contents of the > edited file are executed directly rather than being placed back into the > editing buffer and accepted because that's how `fc' does its job. It > would take some work to redo the implementation. > > It might be an interesting exercise to reimplement that editing function > as you suggest, and it might even be more closely Posix-conformant, but > I'm not inclined to do it right now. There are other, higher-priority > issues. Maybe someday. > > In the meantime, the function I provided does what you would like at the > cost of a single extra keystroke. > > Chet > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/ >
[PATCH] add #if defined(JOB_CONTROL) around job_control in execute_cmd.c
Hello,
In bash-4.2 in execute_cmd.c there is a usage of job_control that
isn't enclosed in "#if defined(JOB_CONTROL)" / "#endif". This causes a
compile failure on Minix since job_control is only defined if
JOB_CONTROL is defined. Patch attached.
-Thomas
--- execute_cmd.c.orig Fri Jun 3 13:34:42 2011
+++ execute_cmd.c Fri Jun 3 13:36:41 2011
@@ -2202,7 +2202,11 @@
/* If the `lastpipe' option is set with shopt, and job control is not
enabled, execute the last element of non-async pipelines in the
current shell environment. */
- if (lastpipe_opt && job_control == 0 && asynchronous == 0 && pipe_out == NO_PIPE && prev > 0)
+ if (lastpipe_opt &&
+#if defined(JOB_CONTROL)
+ job_control == 0 &&
+#endif
+ asynchronous == 0 && pipe_out == NO_PIPE && prev > 0)
{
lstdin = move_to_high_fd (0, 0, 255);
if (lstdin > 0)
Re: Edit vs delete a running script. Why difference?
On Jan 18, 5:22 am, Greg Wooledge wrote: > On Wed, Jan 18, 2012 at 01:19:20PM +0900, Teika Kazura wrote: > > If the > > entire script is read at invocation, then why should / does > > modification affect? Is it a bug? > > The entire script *isn't* read at invocation. Bash just reads a little > bit at a time, as needed. Interestingly, on many Linux systems this allows one to check (crudely) how far a script has progressed by looking at /proc// fdinfo/255.
Misleading text at start of manual
(Checked against bash 4.2; for some reason, the manual on gnu.org is only 4.1.) The top node, "Bash Features", says: "The following menu breaks the features up into categories based upon which one of these other shells inspired the feature." But the following menu doesn't seem to bear that out. Perhaps it's simplest just to remove this sentence, as the top-level menu is perfectly logical and self-explanatory. -- http://rrt.sc3d.org
Patch for examples/loadables/ln.c: support for -n option
Hi,
We use the ln builtin in a project in order to avoid several forks made
by calling the coreutils ln executable. Attached is a patch to implement
the -n option to the ln builtin, making calls like ln -snf ... doable as
with the coreutils version.
Feel free to add this patch to the sources if you think it's worth it.
Kind regards,
Julien
>From dff9b244b233415d5081c3e4b40500e01929c74a Mon Sep 17 00:00:00 2001
From: Julien Thomas
Date: Mon, 27 May 2013 17:45:11 +0200
Subject: [PATCH 1/3] ln: Whitespace cleanup, remove tabulations
---
ln.c | 61 +++--
1 file changed, 31 insertions(+), 30 deletions(-)
diff --git a/ln.c b/ln.c
index ec73636..8fb0561 100644
--- a/ln.c
+++ b/ln.c
@@ -63,17 +63,17 @@ ln_builtin (list)
while ((opt = internal_getopt (list, "fs")) != -1)
{
switch (opt)
- {
- case 'f':
- flags |= LN_UNLINK;
- break;
- case 's':
- flags |= LN_SYMLINK;
- break;
- default:
- builtin_usage ();
- return (EX_USAGE);
- }
+{
+ case 'f':
+flags |= LN_UNLINK;
+break;
+ case 's':
+flags |= LN_SYMLINK;
+break;
+ default:
+builtin_usage ();
+return (EX_USAGE);
+}
}
list = loptend;
@@ -85,10 +85,10 @@ ln_builtin (list)
linkfn = (flags & LN_SYMLINK) ? symlink : link;
- if (list->next == 0) /* ln target, equivalent to ln target . */
+ if (list->next == 0) /* ln target, equivalent to ln target . */
return (dolink (list->word->word, ".", flags));
- if (list->next->next == 0) /* ln target source */
+ if (list->next->next == 0)/* ln target source */
return (dolink (list->word->word, list->next->word->word, flags));
/* ln target1 target2 ... directory */
@@ -156,16 +156,16 @@ dolink (src, dst, flags)
if ((flags & LN_SYMLINK) == 0)
{
if (stat (src, &ssb) != 0)
- {
- builtin_error ("%s: %s", src, strerror (errno));
- return (EXECUTION_FAILURE);
- }
+{
+ builtin_error ("%s: %s", src, strerror (errno));
+ return (EXECUTION_FAILURE);
+}
if (S_ISDIR (ssb.st_mode))
- {
- errno = EISDIR;
- builtin_error ("%s: %s", src, strerror (errno));
- return (EXECUTION_FAILURE);
- }
+{
+ errno = EISDIR;
+ builtin_error ("%s: %s", src, strerror (errno));
+ return (EXECUTION_FAILURE);
+}
}
/* If the destination is a directory, create the final filename by appending
@@ -174,9 +174,9 @@ dolink (src, dst, flags)
if ((stat (dst, &dsb) == 0) && S_ISDIR (dsb.st_mode))
{
if ((p = strrchr (src, '/')) == 0)
- p = src;
+p = src;
else
- p++;
+p++;
dst_path = mkdirpath (dst, p);
dst = dst_path;
@@ -217,10 +217,11 @@ char *ln_doc[] = {
/* The standard structure describing a builtin command. bash keeps an array
of these structures. */
struct builtin ln_struct = {
- "ln", /* builtin name */
- ln_builtin, /* function implementing the builtin */
- BUILTIN_ENABLED, /* initial flags for builtin */
- ln_doc, /* array of long documentation strings. */
- "ln [-fs] file1 [file2] OR ln [-fs] file ... directory", /* usage synopsis; becomes short_doc */
- 0 /* reserved for internal use */
+"ln",/* builtin name */
+ln_builtin, /* function implementing the builtin */
+BUILTIN_ENABLED, /* initial flags for builtin */
+ln_doc, /* array of long documentation strings. */
+/* usage synopsis; becomes short_doc */
+"ln [-fs] file1 [file2] OR ln [-fs] file ... directory",
+0/* reserved for internal use */
};
--
1.7.10.4
>From a235a5072390854986c09f197097757acbc52ca5 Mon Sep 17 00:00:00 2001
From: Julien Thomas
Date: Mon, 27 May 2013 17:45:39 +0200
Subject: [PATCH 2/3] ln: Add missing return type in ln_builtin function
definition
---
ln.c |1 +
1 file changed, 1 insertion(+)
diff --git a/ln.c b/ln.c
index 8fb0561..63bd38c 100644
--- a/ln.c
+++ b/ln.c
@@ -50,6 +50,7 @@ typedef int unix_link_syscall_t __P((const char *, const char *));
static unix_link_syscall_t *linkfn;
static int dolink ();
+int
ln_builtin (list)
WORD_LIST *list;
{
--
1.7.10.4
>From 0d0c745f4c5dd2c346b15fc0ac597986ce2b2b42 Mon Sep 17 00:00:00 2001
From: Julien Thomas
Date: Mon, 27 May 2013 17:52:52 +0200
Subject: [PATCH 3/3] ln: Implement -n option as in corutils ln
This option treats destination that is a symlink to a directory
as if it was a normal file. It allows ln -snf ... calls as doable
with coreutils ln.
The option is only available if HAVE_LSTAT is defined as it
[PATCH] Fix argument inversion in call to sh_makepath() from sh_realpath()
In function sh_realpath() defined in lib/sh/pathphys.c, the arguments
passed to sh_makepath() are inverted. This makes the sh_realpath()
fail when is not an absolute path because the expected
concatenation is /, not the reverse.
This problem does not look to be critical, at least in Bash 4.1,
because the function is only used in examples/loadablesrealpath.c.
---
lib/sh/pathphys.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/sh/pathphys.c b/lib/sh/pathphys.c
index 15fcd25..87fbe64 100644
--- a/lib/sh/pathphys.c
+++ b/lib/sh/pathphys.c
@@ -269,7 +269,7 @@ sh_realpath (pathname, resolved)
wd = get_working_directory ("sh_realpath");
if (wd == 0)
return ((char *)NULL);
- tdir = sh_makepath ((char *)pathname, wd, 0);
+ tdir = sh_makepath ((const char *)wd, pathname, 0);
free (wd);
}
else
--
1.7.10.4
Bug in bash(1)
There appears to be a redundancy in the description of the "disown" builtin in bash(1). Version is 4.2. disown [-ar] [-h] [jobspec ...] [...] If jobspec is not present, and neither -a nor -r is supplied, the shell's notion of the current job is used. [...] If no jobspec is present, and neither the -a nor the -r option is sup‐ plied, the current job is used. Here's a patch to remove one of the instances. $ diff -u bash.1_ORIG bash.1 --- bash.1_ORIG 2013-08-21 19:12:47.857956352 +0200 +++ bash.1 2013-08-21 19:13:58.541953745 +0200 @@ -7307,13 +7307,6 @@ .BR SIGHUP . If no .I jobspec -is present, and neither the -.B \-a -nor the -.B \-r -option is supplied, the \fIcurrent job\fP is used. -If no -.I jobspec is supplied, the .B \-a option means to remove or mark all jobs; the -- Thomas Hood
Bogus SIGPIPE bug
I have isolated a bug in bash 3.2 which doesn't appear in later
versions of bash I have tried; now I am trying to figure out when
where the bug got fixed so I can make an upgrade plan. I am using SLES
11 SP2.
To reproduce the issue do the following.
* Block SIGPIPE in the current process.
* From the current process, start bash interactively. (The new bash
process also has SIGPIPE blocked.)
* In the latter bash process, run a test program. (The new
test-program process also has SIGPIPE blocked.)
The latter process sees a pending SIGPIPE supposedly sent by itself.
If it unblocks SIGPIPE then it receives this signal immediately.
If the test program is started in various unusual ways such as the
following then it does NOT receive SIGPIPE:
bash -c '{ test ; }'
bash -c ': ; test'
bash -c 'test ; :'
( { test ; } )
( test ; : )
echo test | bash -s
whereas it DOES receive SIGPIPE if it as started as follows.
bash -c test
test
( test )
( test ; )
{ test ; }
I have searched in the mailing list archives and looked in the bash
docs but haven't found a clue as to where this bug was fixed. Does
this ring a bell with anyone or is this most likely a distro-specific
bug?
Info:
$ bash --version
GNU bash, version 3.2.51(1)-release (x86_64-suse-linux-gnu)
> rpm -q -a|grep bash
bash-3.2-147.9.13
$ cat /etc/issue
Welcome to SUSE Linux Enterprise Server 11 SP2 (x86_64) - Kernel \r (\l).
I attach the test program I use.
--
Thomas Hood
RAAF Technology bv
#include
#include
#include
#include
static void sigactor(int signum, siginfo_t *si, void *ctx) {
printf("Caught signal %d sent by process %d\n", signum, si->si_pid);
}
int main()
{
sigset_t sigmask;
struct sigaction act;
act.sa_sigaction = sigactor;
act.sa_flags = SA_RESTART | SA_SIGINFO;
printf("Running with PID %d\n", getpid());
printf("Will retrieve existing signal mask\n");
if (sigprocmask(SIG_SETMASK, NULL, &sigmask)) {
printf("Failed to retrieve existing signal mask\n");
return 1;
}
if (sigismember (&sigmask, SIGPIPE)) {
printf("SIGPIPE is blocked\n");
} else {
printf("SIGPIPE is not blocked\n");
}
printf("Will check for signals pending\n");
if (sigpending(&sigmask)) {
printf("Failed to check for signals pending\n");
return 1;
}
if (sigismember (&sigmask, SIGPIPE)) {
printf("SIGPIPE is pending\n");
} else {
printf("SIGPIPE is not pending\n");
}
printf("Will install signal handler\n");
if (sigaction(SIGPIPE, &act, NULL) || sigaction(SIGHUP, &act, NULL) || sigaction(SIGTERM, &act, NULL)) {
printf("Failed to install signal handler\n");
return 1;
}
//printf("Will sleep\n");
//sleep(30);
sigemptyset(&sigmask);
sigaddset(&sigmask, SIGPIPE);
printf("Will unblock signal\n");
if (sigprocmask(SIG_UNBLOCK, &sigmask, NULL)) {
printf("Error unblocking signal\n");
return 1;
}
printf("Will exit\n");
return 0;
}
When a hashed pathname is deleted, search PATH
Tested in bash 4.3. $ foo ... a command is run $ hash hits command 0 /home/rrt/bin/foo $ rm `which foo` $ which foo /usr/bin/foo $ foo bash: /home/rrt/bin/foo: No such file or directory Why doesn't bash just remove the hashed path and do a normal PATH search? I have to remove it manually. -- http://rrt.sc3d.org
Re: When a hashed pathname is deleted, search PATH
On 14 March 2014 18:23, Chet Ramey wrote: > On 3/14/14 12:11 PM, Reuben Thomas wrote: > > Tested in bash 4.3. > > > > $ foo > > ... a command is run > > $ hash > > hits command > >0 /home/rrt/bin/foo > > $ rm `which foo` > > $ which foo > > /usr/bin/foo > > $ foo > > bash: /home/rrt/bin/foo: No such file or directory > > > > Why doesn't bash just remove the hashed path and do a normal PATH > search? I > > have to remove it manually. > > Look at the description of the `checkhash' option to `shopt'. It does what > you want; it's just not the default. > Thanks. Why is it not the default? Shouldn't an optimisation (hashing PATH lookup) be transparent to the user by default? -- http://rrt.sc3d.org
Re: When a hashed pathname is deleted, search PATH
On 15 March 2014 18:23, Chet Ramey wrote: > It's not been a problem, really. The existence of the `checkhash' option > has been enough. How often do you remove binaries in directories in $PATH? > Fairly often: I frequently rename or retire scripts in my per-user bin directory. Since bash is happy to switch this on in POSIX mode, why not do so by default? It's just another example of making something Just Work rather than inflict a minor annoyance on the user which can only be resolved by manual configuration (whose very existence escaped at least this individual). This is precisely the sort of problem that I regularly fix in my own systems and upstream, because in the big picture, it's just one of many. Is there a downside to making checkhash the default? -- http://rrt.sc3d.org
Re: When a hashed pathname is deleted, search PATH
On 17 March 2014 14:12, Chet Ramey wrote: > On 3/15/14 2:44 PM, Reuben Thomas wrote: > > On 15 March 2014 18:23, Chet Ramey > <mailto:chet.ra...@case.edu>> wrote: > > > > It's not been a problem, really. The existence of the `checkhash' > option > > has been enough. How often do you remove binaries in directories in > $PATH? > > > > > > Fairly often: I frequently rename or retire scripts in my per-user bin > > directory. > > OK. Based on the number of reports in the last few years, you are in the > minority. > It's a minor annoyance, I bet a lot of users just live with it. I'm an inveterate reporter of minor annoyances, and even I took many years to report this problem. To my mind that doesn't indicate it shouldn't be fixed: minor annoyances can easily be "rounded down" to zero, but the total pain can still be large. Only the minor performance hit it would extract on every command lookup. > I don't understand, surely it only has a performance impact when a hashed file or a directory on PATH is (re)moved? How about removing both pain *and* complexity: I'd happily prepare a patch to make checkhash always on, remove its documentation, but of course keep the option name supported for backwards compatibility. Then no-one ever need think about it again. Failing that, I'd also happily prepare a patch to simply switch the default to on. -- http://rrt.sc3d.org
Re: When a hashed pathname is deleted, search PATH
On 17 March 2014 20:30, Chet Ramey wrote: > On 3/17/14 10:17 AM, Dave Rutherford wrote: > > On Mon, Mar 17, 2014 at 10:12 AM, Chet Ramey > wrote: > >> On 3/15/14 2:44 PM, Reuben Thomas wrote: > >>> On 15 March 2014 18:23, Chet Ramey >>> <mailto:chet.ra...@case.edu>> wrote: > >>> Is there a downside to making checkhash the default? > >> > >> Only the minor performance hit it would extract on every command lookup. > > > > Only on commands that were found in the hash table, correct? > > Yes, of course. I should have said every *successful* command hash table > lookup. This is much less of an issue now than when the option was first > added. > OK, I misread the description, and thought it would only look the command up if the execution fails. Why can't that be done? -- http://rrt.sc3d.org
Re: When a hashed pathname is deleted, search PATH
On 17 March 2014 20:46, Chet Ramey wrote: > Because the execution fails in a child process. You'd be able to fix it > for that process, but would do nothing about the contents of the parent > shell's hash table. > Thanks for the explanation. -- http://rrt.sc3d.org
Re: When a hashed pathname is deleted, search PATH
On 18 March 2014 08:04, Linda Walsh wrote: > > > Chet Ramey wrote: > >> Because the execution fails in a child process. You'd be able to fix it >> for that process, but would do nothing about the contents of the parent >> shell's hash table. >> >> The way the option works now is to check the hash lookups and delete >> anything that is no longer an executable file, then redo the lookup and >> hash the new value. >> > > Wouldn't bash notice that the child exited in <.1 seconds ( > or is it less? > Timing is not something you could rely on, though. The child could report failure by e.g. writing through a pipe to the parent, as in http://stackoverflow.com/questions/2719499/c-signal-parent-process-from-childthereby letting the parent update its hash table, but it's not clearly worth the extra complexity to remove the small overhead.
Reverse incremental search provoking errors
In bash-4.3-beta2 a new feature has been introduced under 2. a. Changed message when an incremental search fails to include "failed" in the prompt and display the entire search string instead of just the last matching portion. But there's another side effect to this: the string matching the characters typed first is returned, although failed is printed. I understand the good intent of this feature, but coming from bash 4.2, I find it quite disturbing, as it's provoking errors if one doesn't check, if reverse search has succeeded or failed (e.g. for a long string) and just presses enter. While this has not happened to me yet, I found the previous behaviour very comfortable and safe. If no matching results are present I don't think its a good idea to print 'failed' and just return the next best match. (Not very realistic) example search for "longcommand remember-the-milk" and a typo: "[Ctrl-r] remember-the-milk" may return "rm somefiles". One has to look carefully look if the search has failed otherwise, which many people don't do, especially if they're using to the previous behaviour. I didn't find a way to turn this feature of and get the old behaviour. Is it possible to at least make it optional in the next release that the next best match is returned? I think most people will notice it just now as it found its way into Ubuntu 14.04 LTS released in two weeks, so it will probably stay for a while. Best regards Thomas
Re: read -e does not restore terminal settings correctly when interrupted if a trap is set
Yep, that fixed the problem, thank you !
2014-09-08 20:46 GMT+02:00 Chet Ramey :
> On 9/7/14, 6:40 PM, micka...@gmail.com wrote:
>
>> Bash Version: 4.3
>> Patch Level: 24
>> Release Status: release
>>
>> Description:
>> Given the following script (test.sh) :
>>
>> #!/bin/bash
>> cleanup() { :; }
>> trap cleanup 0
>> read -e dummy
>>
>> Run the script ('bash test.sh') *in ZSH* and when it waits for an
>> input,
>> interrupt it with Ctrl-C.
>
> Thanks for the report. The problem is that bash doesn't clean up readline
> and its terminal state in all cases that can result in its calling
> longjmp() or exiting the shell. I've attached a patch that should fix the
> problem.
>
> The problem doesn't manifest itself in bash because bash saves the terminal
> state before a command runs and restores it when the command is terminated
> by a signal.
>
> Chet
>
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
command completion
Before there was programmable completion, there was simply filename completion. Now we have smart completion, which you can turn off with "complete -r". But that doesn't revert to simple filename completion. It still insists on doing "command completion". That means that if it thinks that a command belongs in a particular position, then it insists on the file being executable or it won't use it for completion. Unfortunately, bash and I don't always agree on when and what needs to be executable. Is there an option to turn off command completion, but leave filename completion on? ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bash-3.1 Official Patch 10 - UPDATED
On Fri, Mar 03, 2006 at 11:10:50AM -0500, Chet Ramey wrote: > Bash-Release: 3.1 > Patch-ID: bash31-010 > [...] > THIS IS AN UPDATED PATCH. [...] Uh. Why couldn't you just release a new patch on top of the old ones instead? Would have been less cumbersomely for build systems where the source and patch files are downloaded automatically and cached for later re-use. (I had to intervene and manually delete the old `bash31-010'.) Regards, Thomas ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
[Fwd: [KDE Bug 124960] konsole/bash must not execute CR unconfirmed prompt commands on exit signals]
From: schorpp To: bug-bash@gnu.org,[EMAIL PROTECTED] Subject: -see mail subject- Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-pc-linux-gnu' -DCONF_VENDOR='pc' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 uname output: Linux tom1.schorpp.dyndns.dk 2.6.16 #1 PREEMPT Tue Mar 21 01:38:42 CET 2006 i686 GNU/Linux Machine Type: i386-pc-linux-gnu Bash Version: 2.05b Patch Level: 0 Release Status: release Description: -see attachments- Repeat-By: -see attachments- y tom --- Begin Message --- --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. http://bugs.kde.org/show_bug.cgi?id=124960 --- Additional Comments From t.schorpp gmx de 2006-04-07 08:59 --- yes: tom1:~# ls -l konsole.txt -rw-r--r-- 1 root root 5 Apr 7 08:29 konsole.txt tom1:~# grep konsole.txt .bash_history echo shit > konsole.txt tom1:~# tail .bash_history ... echo shit > konsole.txt schorpp tom1:~$ tail .bash_history ... su - now is konsole firing the echo on signal or bash on signal? i cant see it clearly in the konsole sources. should i forward a copy of this bug to bashbugs gnu org just to be sure the gnu guys are investigating this too? --- End Message --- --- Begin Message --- --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. http://bugs.kde.org/show_bug.cgi?id=124960 phil kde org changed: What|Removed |Added Severity|crash |normal Status|UNCONFIRMED |NEW everconfirmed|0 |1 --- Additional Comments From phil kde org 2006-04-06 23:51 --- Same here. Only occurs when 'su' has been used. I didn't try 'su -' though. Do you get the same problem with 'su -'? --- End Message --- --- Begin Message --- --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. http://bugs.kde.org/show_bug.cgi?id=124960 --- Additional Comments From t.schorpp gmx de 2006-04-05 21:01 --- CR=Carriage Return, Enter Key 1. open konsole 2. su to root 3. type some exe/script call like "echo shit_happens > 124960.txt" -dont press enter- 4. shutdown system with kde logout. the command written at the prompt gets executed without confirmation by enter. --- End Message --- --- Begin Message --- --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. http://bugs.kde.org/show_bug.cgi?id=124960 --- Additional Comments From phil kde org 2006-04-05 18:31 --- I don't understand what you mean by CR confirmation. Could you explain more fully, and give the steps I would need to take to reproduce the bug? --- End Message --- --- Begin Message --- --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. http://bugs.kde.org/show_bug.cgi?id=124960 --- Additional Comments From t.schorpp gmx de 2006-04-05 11:25 --- bash version is 2.05b-26 debian stable. --- End Message --- --- Begin Message --- --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. http://bugs.kde.org/show_bug.cgi?id=124960 Summary: konsole must not execute CR unconfirmed prompt commands on exit signals Product: konsole Version: unspecified Platform: Debian testing OS/Version: Linux Status: UNCONFIRMED Severity: crash Priority: NOR Component: general AssignedTo: konsole-devel kde org ReportedBy: t.schorpp gmx de Version:(using KDE KDE 3.5.2) Installed from:Debian testing/unstable Packages OS:Linux tom1:~# hdlock (without CR execution confirmation!), a customer script to lock the hd drives with ata-security is executed on kde logout->system shutdown and respective signals. konsole must not execute scripts or call any CR-unconfirmed commands/executables at exit signals in any case. bug severity was set to maximum cause this is a system security hazard that leaves the system in a broken state. y tom --- End Message --- ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
The yank-last-arg ("_") command and comments
A recent new version of bash has changed the behavior of the
yank-last-arg command ("_"). Is there a way to revert to the old behavior?
Now, it no longer does so for comment lines.
i.e. yank the last arg.
A very frequent thing that happens to me is that I discover
after typing in a command line that the object of the command hasn't
been properly readied.
For example, I want to put a file somewhere, and then remember
that the subdirectory hasn't been created yet. The yank-last-arg command
is very useful in combination with the insert-comment command:
I just hit "#" to turn the command into a comment,
and then enter the necessary command and hit
(i.e. XTerm ...F1: string(0x1b) string("_") \n\ ...)
mkdir
then I can bring back the commented-out line, x-out the comment character,
and rerun it with just a very few key-presses.
--
---
Thomas Mellman Tel: +49/8233/389-037
Creative Telcom Solutions
[EMAIL PROTECTED] Fax: +49/1212-5-115-48-103
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bug-bash Digest, Vol 47, Issue 9
[EMAIL PROTECTED] wrote:
---
Message: 1
Date: Tue, 10 Oct 2006 16:08:05 -0500
From: mwoehlke <[EMAIL PROTECTED]>
Subject: How to detect bash?
To: bug-bash@gnu.org
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Anyone have any clever, VERY reliable tricks for detecting if the
current shell is bash? The obvious way is '[ -n "$BASH" ]', but in the
interest of catching idiots that set BASH to get around such a check, I
came up with:
[ "`BASH_SUBSHELL=975 ; ( echo $BASH_SUBSHELL )`" -eq 976 ]
(975 is of course an arbitrary number.)
Anyone think they know a better way (or a reason the above might not
work)? I'm guessing it can still be circumvented*, but one would have to
be specifically making an effort to do so.
(* Actually, I'm not 100% certain it can; you have to be able to run a
script upon sub-shell startup. I'm assuming that can be done, but maybe
I'm wrong...)
I have this. I don't like it, but I don't know any better.
getshelltype ()
{
#
# unfortunately, using set -o options doesn't work here
#
if typeset -Z a 2> /dev/null; then
echo ksh
else
echo bash
fi
}
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Problem on GNU/Hurd systems w.r.t. process substitution
Hello! There seems to be a problem with bash's usage of named pipes on GNU/Hurd systems. #v+ [EMAIL PROTECTED]:~ $ diff -u <(echo a) <(echo b) --- /proc/self/fd/632006-11-19 15:32:53.622504951 +0100 +++ /proc/self/fd/622006-11-19 15:32:53.614508451 +0100 @@ -1 +1 @@ -a +b [EMAIL PROTECTED]:~ $ echo $? 1 [EMAIL PROTECTED]:~ $ echo $BASH_VERSION 3.1.17(1)-release [EMAIL PROTECTED]:~ $ apt-cache policy bash | grep Inst Installed: 3.1-5 [EMAIL PROTECTED]:~ $ uname -a Linux taylor 2.6.18-1-xen-686 #1 SMP Sat Oct 21 21:58:56 UTC 2006 i686 GNU/Linux #v- #v+ [EMAIL PROTECTED]:~ $ diff -u <(echo a) <(echo b) [EMAIL PROTECTED]:~ $ echo $? 0 [EMAIL PROTECTED]:~ $ echo $BASH_VERSION 3.1.17(1)-release [EMAIL PROTECTED]:~ $ apt-cache policy bash | grep Inst Installed: 3.1dfsg-7 [EMAIL PROTECTED]:~ $ uname -a GNU leibniz 0.3 GNU-Mach 1.3.99/Hurd-0.3 i686-AT386 GNU #v- info Bash #v+ [...] 3.5.6 Process Substitution -- Process substitution is supported on systems that support named pipes (FIFOs) or the `/dev/fd' method of naming open files. [...] #v- The GNU/Hurd system does support named pipes. Any idea what is going wrong here, particularly the fact that it fails silently? (I didn't investigate so far.) Regards, Thomas signature.asc Description: Digital signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Hidden files feature request
Hello! On Sat, Nov 25, 2006 at 10:27:19PM -0700, Bob Proulx wrote: > Uno Engborg wrote: > > In Gnome, MacOS-X, and in Kubuntu KDE, you can make a file hidden from > > the desktop environment by listing it in a file called .hidden. > > The .hidden file resides in the same directory as the files to be > > hidden, and lists the files to be hidden as one file/line. > > > > Files hidden by being listed in .hidden should behave like any other > > dot file. E.g. they should be listed with ls -a > > > > It would be nice if the bash shell used the same extended mechanism for > > creating hidden files. Honoring the .hidden mechanism would allow for a > > more consitent user experiece for peoople switching back and forth > > between GUI and CLI environments. > > Perhaps you could explain how this new paradigm idea affects the bash > shell? I fail to see a connection. He wants `echo *' to not display these files anymore and so forth, I guess. Regards, Thomas signature.asc Description: Digital signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: readline: edit (mode:vi) means eol unreachable
Hugh Sasse <[EMAIL PROTECTED]> wrote: > I see that a terminfo entry for PuTTY is on the wishlist. So meanwhile > I've asked them to re-examine this. On PuTTY developer's wishlist, I assume. ncurses has had a "putty" terminfo for a few years (iirc, the example given on PuTTY's website has some problems). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Bash uses 100% CPU time (when started by "su")
Configuration Information: Machine: i686 OS: linux-gnu Compiler: i686-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=athlon-xp -O2 -fomit-frame-pointer -pipe uname output: Linux schlumpfine 2.6.19-gentoo-r5 #3 PREEMPT Sun Feb 11 11:26:54 CET 2007 i686 AMD Athlon(tm) XP 2600+ AuthenticAMD GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 3.1 Patch Level: 17 Release Status: release Description: When using bash and then starting a second bash by using "su", the bash started by "su" will use 100% CPU time if it is in reverse-i-search mode and the first bash process is killed with SIGHUP (using "kill" or e. g. by closing the xterm window). This also happens with Bash 3.2_p9 and Readline 5.2_p1. I'm using su from shadow version 4.0.18.1. Repeat-By: 1) log in to a console or open an xterm/konsole/... 2) echo $$ (keep this in mind as PID#1) 3) su $USER 4) echo $$ (keep this in mind as PID#2) 5) Hit Ctrl+R (bash is in reverse-i-search mode now) 6) On a different console type: kill -HUP 7) The bash with PID#2 now runs endlessly with 100% CPU usage 8) kill -9 ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: shouldn't prompt printing be smarter?
Chet Ramey <[EMAIL PROTECTED]> wrote: > Fran Litterio wrote: >>> Also, creating an "option" to decide which behaviour should be followed >>> (current one or the one I propose) would make everyone happy >> >> It should be possible to code a value for PROMPT_COMMAND that sends >> the cursor position report escape sequence (for xterm this is >> "\033[6n"), learn the position of the cursor, and conditionally output >> a newline if the cursor is not in column 1. >> >> Some quick experimentation shows that this sequence of commands will >> do just that: > This is the right approach. In general, it's not possible for readline > to do this in a terminal-independent way -- termcap and terminfo do not > provide the appropriate capability. If you want to do this, you will > have to decide yourself which terminals to support. yes/no: since termcap doesn't have a standard, one can add capabilities if they're needed. ncurses's terminfo has a convention: # The System V Release 4 and XPG4 terminfo format defines ten string # capabilities for use by applications, In this file, we use # certain of these capabilities to describe functions which are not covered # by terminfo. The mapping is as follows: # # u9 terminal enquire string (equiv. to ANSI/ECMA-48 DA) # u8 terminal answerback description # u7 cursor position request (equiv. to VT100/ANSI/ECMA-48 DSR 6) # u6 cursor position report (equiv. to ANSI/ECMA-48 CPR) The feature won't work on some terminal types (Sun console for instance). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Error when configuring bash 3.2
Hello! On Mon, Apr 09, 2007 at 02:36:04AM +0200, Pierre wrote: > [...] > checking whether #! works in shell scripts... ./configure: ./conftest: > /bin/cat: bad interpreter: No such file or directory > yes > [...] On what sort of system is that and what does ``ls -l /bin/cat'' show? Regards, Thomas signature.asc Description: Digital signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Would bash ever use xterm color support as default?
shirish agarwal <[EMAIL PROTECTED]> wrote: > Hi all, >Most of us use bash by default. And bash is not intuitive atleast for > people who are new to the system. I'm sure there have been suggestions made > for this before & would be made after me and I guess the people maintaining > bash would have some valid points why things like intelligent history > completion, tab-completion, having color support have not been made > defaults. Please lemme know any links or rationale which are behind these > decisions. >Couple of links https://wiki.ubuntu.com/Spec/EnhancedBash as well as however the examples given are all hardcoded, and (given the limitation to specific terminal types) more/less work without requiring any modification to bash. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Question about behavior of redirections inside an if construct
Hello!
I'm probably only missing something very obvious, but...
tho...@dirichlet:~ $ bash --version
GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.
tho...@dirichlet:~ $ bash -c 'if { :; } 2> /dev/null < NONEXISTING_FILE;
then :; else echo >&2 OK; fi'
OK
tho...@dirichlet:~ $ sh -c 'if { :; } 2> /dev/null < NONEXISTING_FILE; then
:; else echo >&2 OK; fi'
OK
tho...@dirichlet:~ $ bash -c 'if : 2> /dev/null < NONEXISTING_FILE; then :;
else echo >&2 OK; fi'
OK
These three work as expected. But why doesn't the following one?
tho...@dirichlet:~ $ sh -c 'if : 2> /dev/null < NONEXISTING_FILE; then :;
else echo >&2 OK; fi'
(no output)
Regards,
Thomas
signature.asc
Description: Digital signature
Re: Question about behavior of redirections inside an if construct
Hello! On Thu, Jan 29, 2009 at 05:47:53PM +0100, Andreas Schwab wrote: > Thomas Schwinge writes: > > These three work as expected. But why doesn't the following one? > > > > tho...@dirichlet:~ $ sh -c 'if : 2> /dev/null < NONEXISTING_FILE; then > > :; else echo >&2 OK; fi' > > Works fine here. Are you sure sh is Bash? Why would sh be something differe... tho...@dirichlet:~ $ ls -l /bin/sh lrwxrwxrwx 1 root root 4 2007-12-25 23:16 /bin/sh -> dash Jeez. That's Ubuntu intrepid 0.5.4-9ubuntu1 version. Unless someone beats me to it, or it is fixed already, I'll take it up with them, sometime later. Andreas: Thanks for pointing out the obvious! Regards, Thomas signature.asc Description: Digital signature
Misleading syntax in manual
The syntax for the "for" command is misleading, as although correct for bash, it is not POSIX-compliant. I am using GNU bash, version 3.2.48(1)-release (i486-pc-linux-gnu) The man page says: for name [ in word ] ; do list ; done which conflicts with the POSIX syntax definition, given in http://www.opengroup.org/onlinepubs/95399/utilities/xcu_chap02.html#tag_02 which says: for name [ in [word ... ]]do compound-list done Note that in the POSIX definition, a semi-colon is only needed, and indeed permitted, after the word list when an "in" clause is used. Hence: for i; do is not correct in POSIX, although it is accepted by bash. (I found this while trying to build GNU Zile on Solaris.) bash does, of course, accept the POSIX syntax. The easiest fix seems to be to put the semicolon above in square brackets, making it optional, though this risks giving the impression that the syntax for i in foo bar;; do would be acceptable, when it's not (even by bash). So, you could give two explicit definitions: for i [;] do list ; done and for i in word ; do list ; done -- http://rrt.sc3d.org/ My dark path darkens; rise over the mountain, distant moon (Murasaki) Listening to: 'Sanctus and Benedictus' from 'Mass of the Children and other sacred music' (The Cambridge Singers / John Rutter)
Improving the manual (was: ${!vname} not documented)
Hello! On Tue, Oct 06, 2009 at 08:16:03AM -0400, Greg Wooledge wrote: > On Tue, Oct 06, 2009 at 03:25:31AM -0400, Mike Frysinger wrote: > > i imagine Chet takes patches > > When I sent a patch to make the manual more human-friendly (replacing > for example ! with $! so that people can search for $! and find it), > it was not accepted. I support that such a patch is installed, as it makes navigating in the manual easier for all those who don't know in which section to look for $!, for example. Regards, Thomas signature.asc Description: Digital signature
unicode aware printf \u and \U switches not supported
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: i686-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' -DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin' -DSYS_BASHRC='/etc/bash/bashrc' -DSYS_BASH_LOGOUT='/etc/bash/bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS -DSSH_SOURCE_BASHRC -O2 -march=core2 -mfpmath=sse -msse4.1 -fomit-frame-pointer -pipe uname output: Linux blackknight 2.6.31-gentoo-r6 #1 SMP PREEMPT Mon Nov 30 19:03:35 CET 2009 i686 Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz GenuineIntel GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 4.0 Patch Level: 35 Release Status: release Description: bash's printf does not understand \u and \U although the man page says it supports all expressions that printf(1) supports. It would be perfect if bash's printf could do this as well (as I would not have to resort to an external utility when needing to print unicode characters as easily as coreutils' printf can do; especially on cygwin, when this is needed a few thousand times things get really slow, but that's not really a bash problem, just so you know how I noticed it...) Repeat-By: tb...@blackknight ~ $ /usr/bin/printf "\u20AC\n" € tb...@blackknight ~ $ type printf printf is a shell builtin tb...@blackknight ~ $ printf "\u20AC\n" \u20AC Fix: Please add the \u and \U functionality, if possible. Or correct the man page. The current state is erroneous however.. Thank you! -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Re: manpage error-Arithmetic Evaluation of numbers with explicit base
Well OK, I understand. Still I think there should be a difference in the man page when it comes to brackets. When talking about arrays, the brackets are NOT an option but mandatory. (and it might be me being uneducated, but how to you print out the decimal equivalent of binary 11 without using brackets? I can only produce the correct value "3" by echo $[2#11] The "optional" refers to being able to not use it when operating on a normal decimal number as I understand this now. Then where can I find that I have to use brackets like I use them -- which only is a side effect of the brackets I have seen in the man page and seems unrelated on the whole!) On 03/2310 03:05 AM, chet.ra...@case.edu wrote: > On 3/22/10 9:13 AM, tbart...@gmx-topmail.de wrote: > > > Bash Version: 4.0 > > Patch Level: 35 > > Release Status: release > > > > Description: > > The man page seems to be wrong regarding the handling of numbers > with different bases. It states one has to use [base#]n although it seems to > be [base#n] that needs to be used... > > The meta-notation [x] means that x is optional. This usage is fairly > common, especially in Unix man pages. > > Chet > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer >``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRUc...@case.edu > http://cnswww.cns.cwru.edu/~chet/ -- GMX.at - Österreichs FreeMail-Dienst mit über 2 Mio Mitgliedern E-Mail, SMS & mehr! Kostenlos: http://portal.gmx.net/de/go/atfreemail
Re: manpage error-Arithmetic Evaluation of numbers with explicit base
Don't get me wrong, I am a full time bash script programmer and I do know how
man pages (and their syntax) look like. I use this syntax myself in every
usage() I write...
Still I think it is misleading.
I simply cannot see how a newb can tell the difference between a bracket that's
part of the syntax:
[...]Any element of an array may be referenced using ${name[subscript]}.[...]
.. and one that's not:
[...]Constants with a leading 0 are interpreted as octal numbers. A leading
0x or 0X denotes hexadecimal. Otherwise, numbers take the form [base#]n,
where base is a decimal number between 2 and 64 representing the arithmetic
base, and n is a number in that base. If base# is omitted, then base 10 is
used.[...]
Granted, it states that base# can be omitted, but I still cannot tell why it is
an "optional" indicator here and "part of the syntax" with the array
explanation. (where it basically can be left out as well to get just the first
element, so it isn't mandatory). It could be part of the syntax here equally
well in my understanding..
But things get even more complicated with array assignments:
[...]Arrays are assigned to using compound assignments of the form name=(value1
... valuen), where each value is of the form [subscript]=string. Indexed array
assignments do not require the bracket and subscript. When assigning to indexed
arrays, if the optional brackets and subscript are supplied, that index is
assigned to[...]
If everything in brackets is optional it should be [subscript=]string or the
value will be a literal "=string" if the optional [subscript] gets left out...
Please don't get me wrong. I have no problem in understanding the man page this
way, but I do think it is inconsistent. And I absolutely understand why, as
there are multiple meanings for a poor little bracket ;->
On Mon, 03/29, 2010 02:51:18PM, Greg Wooledge wrote:
> On Mon, Mar 29, 2010 at 02:22:35PM +0200, Thomas Bartosik wrote:
> > Well OK, I understand. Still I think there should be a difference in the
> man
> > page when it comes to brackets. When talking about arrays, the brackets
> are
> > NOT an option but mandatory.
>
> That's correct. Referencing a specific element of an array by index
> uses square brackets as part of the syntax.
>
> > (and it might be me being uneducated, but how to you print out the
> decimal equivalent of binary 11 without using brackets? I can only produce the
> correct value "3" by
> > echo $[2#11]
>
> The $((...)) notation is preferred and documented.
>
> echo $((2#11))
>
> > The "optional" refers to being able to not use it when operating on a
> normal
> > decimal number as I understand this now. Then where can I find that I
> have to
> > use brackets like I use them -- which only is a side effect of the
> brackets I
> > have seen in the man page and seems unrelated on the whole!)
>
> You are confusing literal square brackets which are part of the syntax
> of a command (as in array indexing) with the brackets used in man pages
> and other documents to indicate that something is optional.
>
> We're not saying that literal square brackets are optional when doing
> array indexing. We're saying that the things INSIDE brackets in a man
> page are optional -- and that the brackets themselves are NOT part of
> the command at all, but rather, part of the documentation.
>
> I understand how it's easy to get confused by that, but eventually
> you'll have to get used to it.
>
> Look at ls(1) from Debian as an example:
>
> SYNOPSIS
>ls [OPTION]... [FILE]...
>
> Or from HP-UX:
>
> SYNOPSIS
>ls [-abcdefgilmnopqrstuxACFLR1] [names]
>
> Or from OpenBSD:
>
> SYNOPSIS
> ls [-1AaCcdFfghikLlmnopqRrSsTtux] [file ...]
>
> See the brackets there? They indicate that the options and filenames
> are optional. They don't mean that you type literal square brackets
> around the options and filenames.
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
bad substitution: no closing `)' in $( #"...
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: freebsd6.2 Compiler: cc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='freebsd6.2' -DCONF_MACHTYPE='i386-portbld-freebsd6.2' -DCONF_VENDOR='portbld' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -I/usr/local/include -O2 -fno-strict-aliasing -pipe uname output: FreeBSD m-net.arbornet.org 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #1: Tue Nov 6 16:13:56 EST 2007 r...@newmnet.arbornet.org:/usr/src/sys/i386/compile/MNET i386 Machine Type: i386-portbld-freebsd6.2 Bash Version: 3.1 Patch Level: 17 Release Status: release Description: See this shell code: : $( #" ) The shell complains: bad substitution: no closing `)' in $( #" ) Repeat-By: see description above
Re: Invisible characters in prompt with multi-byte support enabled
Alexander Becher <[EMAIL PROTECTED]> wrote: > Short version: bash-2.05b/lib/readline/display.c:update_line:1353 > calculates _rl_last_c_pos incorrectly if multibyte support is enabled > and there are invisible characters in the line that include zero-width > characters. There's a similar problem with bash 3.0 - see http://groups-beta.google.com/group/muc.lists.netbsd.users/browse_thread/thread/74cc6170139c4a9d/a8ea4643fdd0e00d?q=netbsd+termcap+bash&rnum=1&hl=en#a8ea4643fdd0e00d I spent enough time analyzing it to see that it's in the same general area. The logic in display.c seems to assume that all of the invisible characters are in one chunk. > I would have loved to include a fix, but that part of readline's code > is incomprehensible to me (for the moment, at least). ;-) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
incorrect handling of invisible characters in prompt string
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: netbsdelf Compiler: cc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='netbsdelf' -DCONF_MACHTYPE='i386--netbsdelf' -DCONF_VENDOR='' -DLOCALEDIR='/usr/pkg/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -I/usr/include -O2 -I/usr/include uname output: NetBSD colwyn.zhadum.de 3.0_BETA NetBSD 3.0_BETA (COLWYN) #0: Sat Jun 18 20:48:09 BST 2005 [EMAIL PROTECTED]:/export/scratch/tron/build.21314a/sys/compile/COLWYN i386 Machine Type: i386--netbsdelf Bash Version: 3.0 Patch Level: 16 Release Status: release Description: An extra character is displayed in the prompt. Tracing the code to see where it went astray, I could see that it appears to assume that the invisible characters are all in one chunk. Using the bundled copy of readline, it is producing incorrect results starting at display.c in this chunk beginning at line 1372: /* If we are changing the number of invisible characters in a line, and the spot of first difference is before the end of the invisible chars, lendiff needs to be adjusted. */ After that, it makes these calls (note that the "c" is passed as part of the invisible-character chunk): _rl_output_some_chars([01;35mc) _rl_output_some_chars(olwyn[00m:~$) _rl_move_cursor_relative(new=22, data=[01;35mcolwyn[00m:~$) Finally, the extra character shows up via putc() called from line 1686. The problem shows up if $TERM is xterm which includes :ei=\E[4l:im=\E[4h: and causes the _rl_move_cursor_relative() call to switch to insert mode when adding the extra character. There is no logic to handle the case where insert-mode is not available - it appears to simply overwrite the cell in that case. Repeat-By: Set TERM=xterm PS1='\[\033[01;35m\]\h\[\033[00m\]:\w\$' then "cd ~". Fix: [Description of how to fix the problem. If you don't know a fix for the problem, don't include this section.] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Sequence Brace Expansion Crash
From: thomas
To: bug-bash@gnu.org
Subject: Sequence Brace Expansion Crash
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/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_FORTIFY_SOURCE=2
-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin'
-DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc'
-DSYS_BASH_LOGOUT='/etc/bash.bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS
-Wno-parentheses -Wno-format-security
uname output: Linux archlinux 4.16.13-1-ARCH #1 SMP PREEMPT Thu May 31
23:29:29 UTC 2018 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.4
Patch Level: 19
Release Status: release
Description:
I was testing brace expansion, and found that if bash uses too much memory
during the expansion, it will simply be killed.
Repeat-By:
echo {a..z}{a..z}{a..z}{a..z}{a..z}{a..z}
Amusingly, this is the only command I've used that has actually caused a
swap.
Fix:
There should probably be a check somewhere, so that when too much memory is
used, an error is thrown rather than crashing. Or computing the
permutations of the expansion and exiting before the calculation might work.
failglob handling
Hi, please see the following script: > #!/bin/bash > shopt -s failglob > if [[ $? -ne 0 ]]; then > echo 'shopt failed' > exit 1 > fi > > # Let's view current options just to be sure > shopt -p > > # The following glob should fail because /foo/bar does not exist ... > # Due to 'failglob' option, bash should stop here > echo /foo/bar/* > > # This code should never run if previous glob failed > echo Still alive Is the assumption true that "Still alive" should *never* be printed when "/foo/bar" does not exist? With bash 4.4-5 (aka 4.4.12(1)) on Debian Stretch and 4.4.23(1) on Gentoo, "Still alive" will be printed. When you add "set -e" to the beginning, execution will stop immediately after the failing glob, i.e. no "Still alive" will be printed. However, see the following interesting difference between semicolons and newlines: > $ echo "shopt -s failglob; echo /foo/bar/*; echo alive; " | bash > bash: line 1: no match: /foo/bar/* > $ echo "shopt -s failglob; echo /foo/bar/*; echo alive; " | sed 's:; :\n:g' | > bash > bash: line 2: no match: /foo/bar/* > alive > $ echo "set -e; shopt -s failglob; echo /foo/bar/*; echo alive; " | sed 's:; > :\n:g' | bash > bash: line 3: no match: /foo/bar/* > $ -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Bash will continue executing main code path instead of current code path on error
Hi,
Test script:
#!/bin/bash
failing_function() {
local foo=${1}
# force bad substitution
local bar=${${foo}_blah}
echo "You will never see this text!"
}
if [[ 1 -eq 1 ]]
then
# Current code path
failing_function
echo "I run after the failing_function!"
else
# Alternative code path
echo "Will never run."
fi
# Main code path
echo "Rest of the script"
Actual result:
==
bash-test.sh: line 5: bar=${${foo}_blah}: bad substitution
Rest of the script
Expected result:
bash-test.sh: line 5: bar=${${foo}_blah}: bad substitution
I run after the failing_function!
Rest of the script
Is my expectation wrong? I am really wondering that the script will
continue but not in the current if clause...
Tested with:
> GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
[PATCH] Fix \H: Use getaddrinfo to get full hostname
At the moment, \h and \H used in prompt PS1 or PS2 will actually return
the same value while manpage claims that \h should return hostname up to
the first '.' (like `hostname`) and \H should return full hostname (like
`hostname -f`).
This commit will make bash use the same API like hostname command to
return full hostname like intended.
This patch is based on the original work from Renato Silva [Link 1].
Link 1: https://lists.gnu.org/archive/html/bug-bash/2014-06/msg00021.html
---
shell.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/shell.c b/shell.c
index a2b2a55e..28e89a2b 100644
--- a/shell.c
+++ b/shell.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include "filecntl.h"
#if defined (HAVE_PWD_H)
# include
@@ -1839,6 +1840,8 @@ get_current_user_info ()
static void
shell_initialize ()
{
+ struct addrinfo *addr_info;
+ struct addrinfo addr_hints;
char hostname[256];
int should_be_restricted;
@@ -1864,10 +1867,17 @@ shell_initialize ()
if (current_host_name == 0)
{
/* Initialize current_host_name. */
- if (gethostname (hostname, 255) < 0)
- current_host_name = "??host??";
+ memset(&addr_hints, 0, sizeof(struct addrinfo));
+ addr_hints.ai_flags = AI_CANONNAME;
+
+ if (gethostname (hostname, 255) >= 0)
+{
+ if (getaddrinfo (hostname, NULL, &addr_hints, &addr_info) == 0)
+strncpy (hostname, addr_info->ai_canonname, 255);
+ current_host_name = savestring (hostname);
+}
else
- current_host_name = savestring (hostname);
+ current_host_name = "??host??";
}
/* Initialize the stuff in current_user that comes from the password
--
2.22.0
Re: [PATCH] Fix \H: Use getaddrinfo to get full hostname
On 2019-07-24 16:27, Chet Ramey wrote: > Thanks for the patch. This is system-dependent: there are systems, like > mine, where `hostname' returns the system's FQDN. It all depends on the > administrator's choices. Can you tell me more about your system and how you (your administrator) set up your system so that hostname will return FQDN? I hope you are not talking about putting FQDN into a file which is expecting hostname only... Or in other words: At the moment I am wondering what should be wrong on my system or on Debian/Ubuntu out of the box: You set hostname to hostname only (no FQDN) and set domain option in /etc/resolv.conf for example for FQDN. But maybe I am missing something. Thanks. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [PATCH] Fix \H: Use getaddrinfo to get full hostname
On 2019-07-24 16:46, Greg Wooledge wrote: >> I hope you are not talking about putting FQDN into a file which is >> expecting hostname only... > > Yes, many people do precisely that. They configure their systems > so the "hostname" command returns an FQDN, as I showed above. (Not > my design, not my choice.) I consider this as misconfiguration. :( I can't believe that we somehow encourage people to either do something wrong (put FQDN where just non-FQDN is expected and bypass DNS mechanism) or use $(hostname -f) in PS1 when they want FQDN. Anyway, back to bash: So you are rejecting this patch, right? Maybe update man page at least to clarify that "\H" in contrast to "\h" is supposed to return the same value but _unfiltered_? Thanks. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [PATCH] Fix \H: Use getaddrinfo to get full hostname
On 2019-07-24 17:32, Greg Wooledge wrote: > Your perspective is too limited. Linux-based systems are very popular, > but they're not the entire Unix world. > > [...] > > There is nothing "wrong" about this configuration. I don't like it, > and you clearly don't like it, but our opinions only matter to us. OK :( Thank you for the explanation! -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Typo in documentation (e.g. man page): 'abd' -> 'and'
Hello, I noticed a small typo in the documentation on conditional expressions. The typo is visible in the man page bash(1), where it says: The test abd [ commands determine their behavior based on Most likely, 'abd' should be 'and' instead. Greetings, Thomas Fischer
Re: bug-bash Digest, Vol 218, Issue 13
On 1/10/21 6:00 PM, bug-bash-requ...@gnu.org wrote: Message: 3 Date: Sun, 10 Jan 2021 16:49:50 +0100 From: Ángel To: bug-bash@gnu.org Subject: Re: non-executable files in $PATH cause errors Message-ID: <94646752576f053515ac2ba4656fe0c895f348ce.ca...@16bits.net> Content-Type: text/plain; charset="ISO-8859-15" On 2021-01-10 at 08:52 +0100, n952162 wrote: Hello, I consider it a bug that bash (and its hash functionality) includes non-executable files in its execution look-up and then (inevitably) simply reports an error, because its such files aren't executable. Perhaps it's there to support PATH look up for arguments to the bash command. That would also be a bug. Why should it be okay to execute a non-executable script? Supporting users who are too lazy to chmod a file ought to be less important than supporting users who want fine-grain control over what's executable and what's not. Hello I can't reproduce what you report. $ mkdir foo bar $ printf '#!/bin/sh\necho Program "$0"\n' > foo/program $ printf '#!/bin/sh\necho Program "$0"\n' > bar/program $ PATH="$PATH:$PWD/foo:$PWD/bar" $ chmod +x bar/program $ program It is executing bar/program, not foo/program which is earlier in the path, but not executable. Maybe you just made the earlier program not executable, and the old path is still being remembered? You should run hash -r after making executable changes that will make an already-executed command find a different program in the path (in the example above, making foo/program executable, or removing again its +x bit). Best regards I unfortunately can't reproduce it, either. I can't remember if I reconfigured something or was doing something special. When I encounter it again, I'll investigate it better. But here's a bug for you, in readline: - edit a line - go to some character - replace that character with another, using the "r" command. - cruise further down the line to another character - hit the "." repeat command The replace operation will not be executed, but rather the "x" operation. This has actually improved over the years. A while back, repeating an earlier operation like that would get characters tangled up. Now, it seems at least to be deterministic.
Re: bug-bash Digest, Vol 142, Issue 53
bug-bash-requ...@gnu.org wrote:
>Send bug-bash mailing list submissions to
> bug-bash@gnu.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnu.org/mailman/listinfo/bug-bash
>or, via email, send a message with subject or body 'help' to
> bug-bash-requ...@gnu.org
>
>You can reach the person managing the list at
> bug-bash-ow...@gnu.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of bug-bash digest..."
>
>
>Today's Topics:
>
> 1. Re: y.tab.c inclusion within the source tree
> (Christian Weisgerber)
> 2. Re: Bash-4.3 Official Patch 27 (Nathan McGarvey)
> 3. Re: Patch file bash42-049 is broken (Christian Weisgerber)
> 4. Re: Patch file bash42-049 is broken (Chet Ramey)
> 5. [UPDATE] Bash-4.2 Official Patch 49 (Chet Ramey)
> 6. Issues with restricted mode (TrevD)
> 7. ShellShok leak (Franz Beck)
> 8. Re: Bash-4.3 Official Patch 27 (becker...@gmail.com)
>
>
>--
>
>Message: 1
>Date: Sun, 28 Sep 2014 13:42:36 +0200
>From: Christian Weisgerber
>To: Mark Goldfinch
>Cc: bug-bash@gnu.org
>Subject: Re: y.tab.c inclusion within the source tree
>Message-ID: <20140928114236.ga60...@lorvorc.mips.inka.de>
>Content-Type: text/plain; charset=us-ascii
>
>Mark Goldfinch:
>
>> Can someone clarify to me why y.tab.c is included within the bash source
>> tree if it is generated from parse.y?
>>
>> If one looks in the FreeBSD ports tree, they're deliberately taking the
>> initiative to touch parse.y to ensure that y.tab.c is always rebuilt.
>
>They also have a dependency on the bison port, because parse.y does
>not build correctly with FreeBSD's yacc(1). You end up with a bash
>that has broken $(...) parsing. Same issue on OpenBSD, where the
>port doesn't touch parse.y because there is no need to.
>
>> If y.tab.c's timestamp ends up being newer than parse.y,
>
>Why would this happen?
>
>> a patch which (correctly) only patches parse.y,
>
>... will cause parse.y to have a newer timestamp.
>
>--
>Christian "naddy" Weisgerber na...@mips.inka.de
>
>
>
>--
>
>Message: 2
>Date: Sun, 28 Sep 2014 07:46:48 -0400
>From: Nathan McGarvey
>To: Eric Blake
>Cc: bug-bash@gnu.org, chet.ra...@case.edu
>Subject: Re: Bash-4.3 Official Patch 27
>Message-ID:
>
>Content-Type: text/plain; charset=UTF-8
>
>Does anyone know if Red Hat intends on remerging with official bash? (This
>may be better directed at a seperate thread with them.)
>
>-Nathan
>On Sep 28, 2014 12:49 AM, "Eric Blake" wrote:
>
>> On 09/27/2014 08:50 PM, Chet Ramey wrote:
>> >BASH PATCH REPORT
>> >=
>>
>> > /* Don't import function names that are invalid identifiers from
>> the
>> >environment, though we still allow them to be defined as shell
>> >variables. */
>> > ! if (absolute_program (tname) == 0 && (posixly_correct == 0 ||
>> legal_identifier (tname)))
>> > ! parse_and_execute (temp_string, tname,
>> SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);
>>
>> This patch forbids importing function names containing '/' (yay!), and
>> we already established that bash has never been able to properly import
>> functions with names containing '='. But I'm assuming there will need
>> to be a followup patch to actually reject the attempt to create such
>> function names (that is, "bash -c 'a/b () { echo oops; }; a/b'" should
>> issue an error message instead of printing "oops"), so that we do not
>> have the confusing situation of being unable to pass all permitted
>> function names through an export/import cycle.
>>
>> By the way, thanks for this patch - it plugs CVE-2014-7186,
>> CVE-2014-7187, and CVE-2014-6277 (and probably other parser crashes)
>> from remote exploits down to merely annoying local bugs that can no
>> longer be abused for privilege escalation. In other words, it is THIS
>> patch that plugs the Shell Shock issue, even though there are still more
>> patches needed to plug all of the parser holes that Shell Shock has
>> uncovered.
>>
>> --
>> Eric Blake eblake redhat com+1-919-301-3266
>> Libvirt virtualization library http://libvirt.org
>>
>>
>
>
>--
>
>Message: 3
>Date: Sun, 28 Sep 2014 13:48:55 +0200
>From: Christian Weisgerber
>To: bug-bash@gnu.org
>Subject: Re: Patch file bash42-049 is broken
>Message-ID: <20140928114855.gb60...@lorvorc.mips.inka.de>
>Content-Type: text/plain; charset=us-ascii
>
>Deron Meranda:
>
>> I was wondering if anybody was going to address the problem with 4.2 patch
>> 49 ?
>>
>> It is still corrupted on the FTP server. There are a few lines that appear
>> to have been deleted out of the middle of the patch file.
>
>Indeed.
>
>> Not only is there a critical line of code missing, but the the 'patch'
>> command will also fail when used
extglob features less useful since shell scripts turn them off
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../bash-3.2p17si2 -I../bash-3.2p17si2/include
-I../bash-3.2p17si2/lib -Os
uname output: Linux aa 2.6.39.3-v11 #9 SMP PREEMPT Tue Dec 13 11:07:11 HST 2011
i686 GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 3.2
Patch Level: 17
Release Status: release
Description:
My interactive environment contains some shell functions that are
cleaner making use of "extglob on" of the interactive shell. But
as soon as any other shell script is run they cause, e.g.,
aa ~ > bashbug
/bin/sh: pushdHelper: line 14: syntax error near unexpected token `('
/bin/sh: pushdHelper: line 14: ` +@([1-9])*([0-9]))'
/bin/sh: error importing function definition for `pushdHelper'
because the script is running "extglob off" and trying to interpret
the functions already in the environment.
Repeat-By:
Put an extglob feature in a function in the environment and run
a shell script.
:(
Mahalo,
Jim
Please improve documentation of "history -a"
At least in bash 4.3, the documentation for history -a says: Append the new history lines (history lines entered since the beginning of the current Bash session) to the history file. This is unfortunately misleading, since it suggests that the technique of adding "history -a" to one's PROMPT_COMMAND, as suggested here: http://heyrod.com/snippet/s/always-append-bash-history.html would append to one's history file many copies of the lines entered since the beginning of the current session. Fortunately it doesn't do that, but rather appends lines that have not yet been appended. I suggest making this clear, and also mentioning the PROMPT_COMMAND trick, as I look forward to losing far fewer useful commands from my global history by having them instantly saved, and not lost when a long-running terminal hangs and must be killed, or the machine running out of power etc. - - http://rrt.sc3d.org
Feature proposal/request: input line highlighting
Hi, as opposed to having a fancy colored prompt, I would like to be able to set up coloring of the whole bash command input line (but not the following command output). This could be achieved by adding a variable like "AFTERPROMPT_COMMAND" which is executed after a prompt line is completed (or "PS9" which is output after a prompt line is completed). It could even be a nice idea to configure this behavior separately for bash and readline, so the users have a choice whether to color just command input, readline-handled program input, or both. I would appreciate this feature, and maybe even supply a patch if I had a clue where to hook it in... Thanks and kind regards, Thomas
Re: Fwd: Re: Feature proposal/request: input line highlighting
On 11 Jun 2015 18:10, Thomas Wolff wrote: > as opposed to having a fancy colored prompt, I would like to be able to > set up coloring of the whole bash command input line (but not the > following command output). This could be achieved by adding a variable > like "AFTERPROMPT_COMMAND" which is executed after a prompt line is > completed (or "PS9" which is output after a prompt line is completed). > It could even be a nice idea to configure this behavior separately for > bash and readline, so the users have a choice whether to color just > command input, readline-handled program input, or both. > I would appreciate this feature, and maybe even supply a patch if I had > a clue where to hook it in... this is already doable -- leave the end of PS1 enabling color. PS1='\[\e[0;33m\]$ \[\e[34;1m\]' this will color the input buffer blue Hi Mike, thanks for your response, but that's not what I meant because the output of the invoked programs will stay blue. I'll illustrate my idea with the attached screenshot, showing a few possible options. Kind regards, THomas
Re: Default time for unmarked history lines
On 7 January 2016 at 20:07, Eduardo A. Bustamante López wrote: > (2) The history should be ordered monotonically (increasing?) > Yes, and it's not at the moment (or wasn't, until I added timestamps to every line in my history), because the lines at the start of the history, with no timestamp, were given the current date and time, and lines at the end of the history, with timestamps, were given the earlier date and time at which they were added to the history. That's why the epoch is better. Also, it's a better clue that the timestamp is being faked.
Re: Default time for unmarked history lines
On 8 January 2016 at 04:21, Eduardo A. Bustamante López wrote: > > I now understand your points. > Thanks very much for taking a look at this. > dualbus@hp ...src/gnu/bash % cat ~/.bash_history > echo 1 > #1452197044 > echo a; sleep 1 > #1452197045 > echo b; sleep 1 > > dualbus@hp ...src/gnu/bash % ./bash -i <<< > "HISTTIMEFORMAT='%Y-%m-%dT%H:%M:%S ' history" > dualbus@hp:~/local/src/gnu/bash$ HISTTIMEFORMAT='%Y-%m-%dT%H:%M:%S ' > history > 1 1969-12-31T18:00:01 echo 1 > 2 2016-01-07T14:04:04 echo a; sleep 1 > 3 2016-01-07T14:04:05 echo b; sleep 1 > 4 1969-12-31T18:00:01 HISTTIMEFORMAT='%Y-%m-%dT%H:%M:%S ' history > > So, it seems that new entries are created with the localtime, unless > there's a > history comment followed by a timestamp. I'm not sure what changes are > needed > to adjust this, but I guess that is not a simple fix. > I'm puzzled by this. What do you mean by "unless there's a history comment followed by a timestamp"? The history file you dump ends with a command, not a timestamp. I am guessing that the bash you then invoke does not have HISTTIMEFORMAT set in its environment, so no timestamp is added for the last line. > BTW, the timestamp = 0 thing is a bug in readline. Aha! Thanks. -- http://rrt.sc3d.org
Re: Default time for unmarked history lines
On 11 January 2016 at 14:22, Chet Ramey wrote: > For a history file without any timestamps, using > the current default and setting the history entry timestamp to the current > time is more appropriate. > Why is that? The only similar thing I can think of is file systems, where if you zero the metadata you get timestamps of the epoch, not the current time. > You probably also have histappend set or didn't use something like > `history -w' to force the entire history file to be written when the shell > exits. > That's right. -- http://rrt.sc3d.org
Fwd: Default time for unmarked history lines
[
Forwarding reply erroneously not sent to the list.]
On 15 January 2016 at 15:26, Chet Ramey wrote:
> On 1/11/16 11:54 AM, Reuben Thomas wrote:
> > On 11 January 2016 at 14:22, Chet Ramey > <mailto:chet.ra...@case.edu>> wrote:
> >
> > For a history file without any timestamps, using
> > the current default and setting the history entry timestamp to the
> current
> > time is more appropriate.
> >
> >
> > Why is that? The only similar thing I can think of is file systems,
> where
> > if you zero the metadata you get timestamps of the epoch, not the current
> > time.
>
> OK, consider the situation when a user has no timestamps in his history
> file. There seem to be three choices for the timestamp: the epoch time,
> which to me is clearly incorrect ("what? what is this 1970s stuff?"), the
> last modified time on the history file itself, and the current time. I
> left the default as the current time, so commands from the history file
> are the same as commands entered at the terminal.
>
I agree with the user story thought in principle.
The trouble is that this is an experience users have anyway with
filesystems and with programs that deal with metadata in files, such as
dates in JPEGs: zero (and sometimes absent) metadata result in epoch
times/dates.
By fixing it just in bash you're actually confusing users (like me) who've
worked out what tends to happen with 0 dates in general.
So, how about instead interpreting a missing/0 date as a NaD (Not A Date),
rather as readline does anyway with time 0, and providing a slightly more
meaningful message than the current "??". Then a) I would be able to remove
all my bogus "1" timestamps, and b) both "0" and missing timestamps would
give the user a clue that data was missing and/or zero?
> > You probably also have histappend set or didn't use something like
> > `history -w' to force the entire history file to be written when the
> shell
> > exits.
> >
> >
> > That's right.
>
> Then you have presented the history library with an ambiguous situation.
>
Correct, and it's entirely natural: for years I didn't use timestamps, now
I do.
Again, with the solution I propose above, I would get a monotonic history
for the part where time is defined, which is good enough.
--
http://rrt.sc3d.org
Re: Fwd: Default time for unmarked history lines
On 18 January 2016 at 22:21, Chet Ramey wrote: > On 1/18/16 11:53 AM, Reuben Thomas wrote: > > > So, how about instead interpreting a missing/0 date as a NaD (Not A > Date), > > rather as readline does anyway with time 0, and providing a slightly more > > meaningful message than the current "??". Then a) I would be able to > remove > > all my bogus "1" timestamps, and b) both "0" and missing timestamps would > > give the user a clue that data was missing and/or zero? > > I think that a more meaningful error string would be useful. We'll try > reporting on invalid dates if the timestamp string in the history entry is > non-empty. > Sounds good, thanks. -- http://rrt.sc3d.org
Time to increase the defaults for history size?
The default HISTSIZE and HISTFILESIZE have been set for as long as I can remember (and the repo only seems to back to bash 3.2). For those concerned about privacy or security, 500 lines is probably too much. For those concerned about disk space, it's hard to come up with a sensible default. My roughly 500,000-command long ~/.bash_history is getting on for 10 years old or so, but only about 12Mb. I suggest therefore that the default be set to unlimited history (both HISTSIZE and HISTFILESIZE), so that more users benefit out of the box from the amazing powers unleashed by being able to get any command you ever typed. -- http://rrt.sc3d.org
Running bash under valgrind gives "invalid free()"
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849517 I can reproduce this also in bash 4.3 as supplied with Ubuntu 16.04, and in a build of 4.4 from source on my Ubuntu system. As stated in the bug report, the bug causes problems beyond bash, as it causes build systems to think that valgrind is not working, and hence run tests without it. I searched the bug-bash archives and couldn't find a previous report of this particular problem (I found mentions of other valgrind diagnostics). -- http://rrt.sc3d.org
Re: Running bash under valgrind gives "invalid free()"
O n 12 April 2017 at 14:50, Chet Ramey wrote: > On 4/12/17 8:57 AM, Reuben Thomas wrote: > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849517 > > > > I can reproduce this also in bash 4.3 as supplied with Ubuntu 16.04, and > > in a build of 4.4 from source on my Ubuntu system. > > > > As stated in the bug report, the bug causes problems beyond bash, as it > > causes build systems to think that valgrind is not working, and hence run > > tests without it. > > Look at it this way: if the "bug" can't be reproduced on another OS, or > can't be reproduced using a debugging malloc library other than valgrind, > that points the finger at valgrind or Debian. > Apologies, I didn't think of reproducibility on other OSes. (Though the point about valgrind is not a strong one: frequently, it's the only tool that shows up bugs of this sort, as it's rather more powerful than a debugging malloc library.) Apologies also for not noticing that the backtrace was lacking. I've installed debugging symbols here and obtained: ==19358== Invalid free() / delete / delete[] / realloc() ==19358==at 0x4C2ED5B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==19358==by 0x45E1D0: unwind_frame_run_internal.constprop.3 (unwind_prot.c:301) ==19358==by 0x45E37F: without_interrupts (unwind_prot.c:107) ==19358==by 0x45E37F: run_unwind_frame (unwind_prot.c:135) ==19358==by 0x47B664: parse_and_execute (evalstring.c:421) ==19358==by 0x4209D6: run_one_command (shell.c:1348) ==19358==by 0x41F893: main (shell.c:695) ==19358== Address 0x423b6e8 is in the brk data segment 0x4228000-0x423bfff Do let me know if there's anything else useful I can do.
Re: Running bash under valgrind gives "invalid free()"
O n 12 April 2017 at 15:49, Chet Ramey wrote: > > It's a false positive, or a bug in valgrind. I took a quick look. There's > one place in this code path where free() gets called. Here's the trace: > [analysis snipped] Thanks very much, looks like it's time for me to file a Valgrind bug report.
Re: Running bash under valgrind gives "invalid free()"
On Apr 12, 2017 4:56 PM, "Chet Ramey" wrote: [snip] > Maybe update the Debian bug report you cited as well. There's still stuff > there from 2005. The report is from December 2016. I can't find "2005" in the page. I'll certainly send an update to point to the upstream bug I file.
Re: Running bash under valgrind gives "invalid free()"
On 12 April 2017 at 17:58, Hanno Böck wrote: > On Wed, 12 Apr 2017 14:59:26 +0100 > Reuben Thomas wrote: > > > frequently, it's the only tool that shows up bugs of this sort, as > > it's rather more powerful than a debugging malloc library.) > > Try address sanitizer, it's pretty reliable and finds even more bug > classes compared to valgrind. Just add -fsanitize=address to the CFLAGS. > > If you can't reproduce the bug with asan I'd bet on a valgrind bug. Thanks very much for the recommendation (and to Chet); I'd not heard of it. Once I've fixed all the bugs I'm finding with valgrind, I'll go back and see what asan finds, and also see if it finds anything else, so I can see whether to run it as well or instead of valgrind. Having confirmed Chet's analysis with a few printfs added to bash (i.e. just to check the address being allocated and the one complained about were the same) I've filed a bug report against valgrind: https://bugs.kde.org/show_bug.cgi?id=378732 -- http://rrt.sc3d.org
Re: Running bash under valgrind gives "invalid free()"
On 13 April 2017 at 09:15, Reuben Thomas wrote: > > Having confirmed Chet's analysis with a few printfs added to bash (i.e. > just to check the address being allocated and the one complained about were > the same) I've filed a bug report against valgrind: > https://bugs.kde.org/show_bug.cgi?id=378732 > Julian Seward (valgrind author) correctly guessed that it is a problem with malloc/free interception: when bash uses its own malloc (as by default on my GNU/Linux system), the malloc is not intercepted by valgrind, but the free is. Obviously a bug in valgrind, but I am interested: why does bash not use the glibc malloc by default on GNU/Linux systems? -- http://rrt.sc3d.org
Re: Running bash under valgrind gives "invalid free()"
On 12 April 2017 at 15:49, Chet Ramey wrote:
>
> It's a false positive, or a bug in valgrind. I took a quick look. There's
> one place in this code path where free() gets called.
Julian Seward (valgrind author) pointed out:
"
…
what you report is symptomatic of bash
using its own malloc to allocate a block but the system free to release
it. Could that be the case?
"
I had a look. Certainly at xmalloc.c:148 where free is called by xfree from
the cleanup function called at unwind_prot.c:333, gdb reports:
p free
$7 = {void (void *)} 0x77df0d80
This is glibc free.
If I put a breakpoint on xmalloc and rerun, it is not hit.
If I put a breakpoint on shell.c:1399, and trace into savestring, I find it
is running sh_xmalloc.
So it seems that the malloc and free calls are mismatched.
Re: Running bash under valgrind gives "invalid free()"
O
n 13 April 2017 at 15:33, Reuben Thomas wrote:
> On 12 April 2017 at 15:49, Chet Ramey wrote:
>
>>
>> It's a false positive, or a bug in valgrind. I took a quick look. There's
>> one place in this code path where free() gets called.
>
>
> Julian Seward (valgrind author) pointed out:
>
> "
> …
> what you report is symptomatic of bash
>
> using its own malloc to allocate a block but the system free to release
>
> it. Could that be the case?
> "
>
> I had a look. Certainly at xmalloc.c:148 where free is called by xfree
> from the cleanup function called at unwind_prot.c:333, gdb reports:
>
> p free
> $7 = {void (void *)} 0x77df0d80
>
> This is glibc free.
>
> If I put a breakpoint on xmalloc and rerun, it is not hit.
>
> If I put a breakpoint on shell.c:1399, and trace into savestring, I find
> it is running sh_xmalloc.
>
> So it seems that the malloc and free calls are mismatched.
>
Trying to understand this at a source level, if I capture the compilation
command for evalstring.c and replace -c with -E to preprocess it, I see
that the relevant line has become:
add_unwind_protect (xfree, orig_string)
where xfree is now the function name (in xmalloc.c).
So this still looks wrong (it should be sh_xfree, surely?).
--
http://rrt.sc3d.org
Re: Running bash under valgrind gives "invalid free()"
On 13 April 2017 at 16:11, Chet Ramey wrote: > > I see no reason why, since all of these things are defined in the same > file and are statically linked, `free' would resolve to the glibc free > when malloc resolves to the bash malloc. So this is the real problem? Do you have any suggestions for how I might investigate this? -- http://rrt.sc3d.org
Re: Running bash under valgrind gives "invalid free()"
O n 13 April 2017 at 16:27, Chet Ramey wrote: > On 4/13/17 11:18 AM, Reuben Thomas wrote: > > On 13 April 2017 at 16:11, Chet Ramey > <mailto:chet.ra...@case.edu>> wrote: > > > > > > I see no reason why, since all of these things are defined in the > same > > file and are statically linked, `free' would resolve to the glibc > free > > when malloc resolves to the bash malloc. > > > > > > So this is the real problem? > > If it is, it's a valgrind artifact. Contrary to Julian's (?) assumption, > free() resolves to the bash free implementation when compiled normally. I > tested this on a Fedora 25 VM I was using for something else. Putting a > breakpoint in xfree, running bash -c '', and stepping through it ends up > in the free() defined in lib/malloc/malloc.c. > This is not the result I obtained. I simply ran gdb on the bash binary, valgrind was not involved. Indeed, building --without-bash-malloc fixed it.
Re: Running bash under valgrind gives "invalid free()"
On 13 April 2017 at 16:46, Chet Ramey wrote:
> On 4/13/17 11:41 AM, Reuben Thomas wrote:
>
> > This is not the result I obtained. I simply ran gdb on the bash binary,
> > valgrind was not involved.
>
> If you didn't build the binary yourself,
I did, from git master. Sorry that wasn't clear.
Thanks for your gdb traces.
Here's mine on Ubuntu 16.04:
$ ./bash --version
GNU bash, version 4.4.12(1)-release (x86_64-unknown-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ gdb ./bash
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./bash...done.
(gdb) b xfree
Breakpoint 1 at 0x47ca80: file xmalloc.c, line 147.
(gdb) r -c ''
Starting program: /home/rrt/.local/var/repo/bash/bash -c ''
s is 0x721368
s is 0x721368
string is 0x721368
Breakpoint 1, xfree (string=0x721368) at xmalloc.c:147
147 if (string)
(gdb) s
148free (string);
(gdb) s
internal_free (mem=0x721368, file=0x0, line=0, flags=) at
malloc.c:846
846malloc.c: No such file or directory.
(gdb) s
858in malloc.c
(gdb) p free
$1 = {void (void *)} 0x77df0d80
(gdb)
So it seems I misunderstood what gdb was telling me: "p free" gives the
address of glibc free (even if I do it inside xfree). But it is running
bash's free.
(There are some extra diagnostics there which are debugging statements I
put in.)
Meanwhile, in the valgrind bug report, Mark Wielaard observed:
"I think the problem is that bash not only has its own malloc/free
implementation (valgrind should intercept that just fine). But also has
malloc wrappers for some malloc functions that call their internal
counterparts directly (so valgrind won't know that is a matching
allocation/deallocation function)."
Mark manages to fix the problem by defining DISABLE_MALLOC_WRAPPERS, which
is at least less drastic than configuring --without-bash-malloc.
I shall pursue the matter on the Valgrind side. Mark also says that
compiled thus he finds some small memory leaks in bash, so I'll report back
if I can confirm.
Thanks very much again for your help with this problem.
--
http://rrt.sc3d.org
Leaks detected by valgrind
Here they are. I guess you probably won't care about them as as far as I can see they are all one-off allocations at initialization: ==1289== 276 bytes in 1 blocks are definitely lost in loss record 230 of 249 ==1289==at 0x4C2DB2F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==1289==by 0x4793CF: xmalloc (xmalloc.c:112) ==1289==by 0x472F48: set_default_locale (locale.c:81) ==1289==by 0x420900: main (shell.c:411) ==1289== ==1289== 1,008 bytes in 1 blocks are definitely lost in loss record 232 of 249 ==1289==at 0x4C2DB2F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==1289==by 0x47939A: xmalloc (xmalloc.c:112) ==1289==by 0x496FDD: sh_setlinebuf (setlinebuf.c:45) ==1289==by 0x41F83C: shell_initialize (shell.c:1799) ==1289==by 0x4210BB: main (shell.c:570) ==1289== ==1289== 1,008 bytes in 1 blocks are definitely lost in loss record 233 of 249 ==1289==at 0x4C2DB2F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==1289==by 0x47939A: xmalloc (xmalloc.c:112) ==1289==by 0x496FDD: sh_setlinebuf (setlinebuf.c:45) ==1289==by 0x41F848: shell_initialize (shell.c:1800) ==1289==by 0x4210BB: main (shell.c:570) ==1289== -- http://rrt.sc3d.org
Re: Running bash under valgrind gives "invalid free()"
On 13 April 2017 at 21:17, Chet Ramey wrote: > On 4/13/17 3:57 PM, Reuben Thomas wrote: > > > Meanwhile, in the valgrind bug report, Mark Wielaard observed: > > > > "I think the problem is that bash not only has its own malloc/free > > implementation (valgrind should intercept that just fine). But also has > > malloc wrappers for some malloc functions that call their internal > > counterparts directly (so valgrind won't know that is a matching > > allocation/deallocation function)." > > Yes, if he wants the details, feel free to forward my message from earlier > today. > Thanks, I already linked to it in the valgrind bug report . -- http://rrt.sc3d.org
Re: Running bash under valgrind gives "invalid free()"
On 13 April 2017 at 22:05, Reuben Thomas wrote: > > On 13 April 2017 at 21:17, Chet Ramey wrote: > >> On 4/13/17 3:57 PM, Reuben Thomas wrote: >> >> > Meanwhile, in the valgrind bug report, Mark Wielaard observed: >> > >> > "I think the problem is that bash not only has its own malloc/free >> > implementation (valgrind should intercept that just fine). But also has >> > malloc wrappers for some malloc functions that call their internal >> > counterparts directly (so valgrind won't know that is a matching >> > allocation/deallocation function)." >> >> Yes, if he wants the details, feel free to forward my message from earlier >> today. >> > > Thanks, I > already linked to it in the valgrind bug report > . > I've closed the Valgrind bug report WONTFIX. Mark Wielaard there kindly provides a patch to bash to make it play nicely with Valgrind, though I doubt you'll want to take it (just to be clear, I wouldn't if I were a bash maintainer!). Since RedHat and Fedora build --without-bash-malloc, that seems an acceptable solution for Debian/Ubuntu. (Not least, performance there is less of an issue since the default /bin/sh is no longer bash.) As Mark says, and if it hasn't already been tried, it would be good if any benchmarks could be brought to the attention of the glibc maintainers if there's potential for improvement in glibc's malloc. -- http://rrt.sc3d.org
Setting HISTTIMEFORMAT is causing problems in >=bash-5.2
> p $param
CONFIG_PROTECT_MASK
DB<5> c
Shorewall::Config::export_params(/usr/share/shorewall/Shorewall/Config.pm:6065):
6065: if ( $shell == BASH ) {
DB<5> p $param
EDITOR
DB<6> p $value
/bin/nano
DB<7> c
Shorewall::Config::export_params(/usr/share/shorewall/Shorewall/Config.pm:6065):
6065: if ( $shell == BASH ) {
DB<7> p $param
GCC_SPECS
DB<8> p $value
export HISTTIMEFORMAT=$'[\E[36m%F %T\E(B\E[m]: '
DB<9> s
Shorewall::Config::export_params(/usr/share/shorewall/Shorewall/Config.pm:6068):
6068: $value =~ s/\\'/'/g;
DB<9>
Shorewall::Config::export_params(/usr/share/shorewall/Shorewall/Config.pm:6069):
6069: $value =~ s/\\"/"/g;
DB<9>
Shorewall::Config::export_params(/usr/share/shorewall/Shorewall/Config.pm:6070):
6070: $value =~ s//\\/g;
DB<9>
Shorewall::Config::export_params(/usr/share/shorewall/Shorewall/Config.pm:6077):
6077: if ( defined $ENV{$param} ) {
DB<9>
Shorewall::Config::export_params(/usr/share/shorewall/Shorewall/Config.pm:6078):
6078: next if $value eq $ENV{$param};
DB<9> V ENV[param]
$| = 1
$^A = ''
$^D = 0
$1 = 'ENV[param]'
%ENV = (
'CCACHE_DIR' => '/var/cache/ccache'
'CONFIG_PROTECT' => '/usr/share/gnupg/qualified.txt'
'CONFIG_PROTECT_MASK' => '/etc/sandbox.d /etc/terminfo'
'EDITOR' => '/bin/nano'
'GCC_SPECS' => ''
'HISTFILESIZE' => 1
'HISTSIZE' => 1
'HISTTIMEFORMAT' => "[\e[36m%F %T\e(B\e[m]: "
'HOME' => '/root'
[...]
--
Regards,
Thomas
AW: Re: AW: Re: read command sometimes misses newline on timeout
That sounds promising. Is the fix somewhere accessible for me? I would gladly test it. - Thomas
AW: Re: AW: Re: AW: Re: AW: Re: read command sometimes misses newline on timeout
I can confirm that the patch resolves all the issues I had. Thank you very much for your help, it is very appreciated. On 10/15/24 11:08 AM, Thomas Oettli wrote: > Got it, I just backported your patch to Bash 5.2 and it fixed the issue on > my build host. > I will roll out the patched version to all my hosts this weekend and keep > you noticed if anything strange happens. > BTW: will this patch be backported to previous Bash versions? I doubt it; I have only done that once, for shellshock. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
Bash 5.2: broken built-in printf for float numbers
Hi, Bash 5.2 has a broken built-in printf for float numbers. Example: printf "%5.1f" 1024 should print "1024.0" (with standard locale LC_ALL=C.UTF-8) Testing the Bash shell in different versions of recent Debian and Ubuntu setups, the output is wrong. Bug tracker for Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081424 .Depending on the Debian/Ubuntu patch version of Bash, the output made by Bash is either complete garbage (random), or "nan" or "-0.0". The output of the external command /usr/bin/printf is always correct. The attached small Bash script runs Docker with different Debian and Ubuntu containers, generating test output with version information. The generated output of ./bash-bug-test1 | tee bash-bug-test1.log is attached as well. -- Best regards / Mit freundlichen Grüßen / Med vennlig hilsen === Thomas Dreibholz Simula@OsloMet -- Simula Metropolitan Centre for Digital Engineering Centre for Resilient Networks and Applications Pilestredet 52 0167 Oslo, Norway --- E-Mail: dre...@simula.no Homepage: http://simula.no/people/dreibh === Thu Nov 7 10:01:01 CET 2024 debian:buster: [34mUsing /usr/bin/printf: 1024.0 KiB[0m Version: 5.0-4 BASH_VERSION=5.0.3(1)-release [34mBefore update, built-in: 1024.0 KiB[0m Version: 5.0-4 BASH_VERSION=5.0.3(1)-release [34mAfter update, built-in: 1024.0 KiB[0m debian:bullseye: [34mUsing /usr/bin/printf: 1024.0 KiB[0m Version: 5.1-2+deb11u1 BASH_VERSION=5.1.4(1)-release [34mBefore update, built-in: 1024.0 KiB[0m Version: 5.1-2+deb11u1 BASH_VERSION=5.1.4(1)-release [34mAfter update, built-in: 1024.0 KiB[0m debian:bookworm: [34mUsing /usr/bin/printf: 1024.0 KiB[0m Version: 5.2.15-2+b7 BASH_VERSION=5.2.15(1)-release [34mBefore update, built-in: 1024.0 KiB[0m Version: 5.2.15-2+b7 BASH_VERSION=5.2.15(1)-release [34mAfter update, built-in: 1024.0 KiB[0m debian:trixie: [34mUsing /usr/bin/printf: 1024.0 KiB[0m Version: 5.2.32-1+b1 BASH_VERSION=5.2.32(1)-release [34mBefore update, built-in: -0.0 KiB[0m Version: 5.2.32-1+b2 BASH_VERSION=5.2.32(1)-release [34mAfter update, built-in: -0.0 KiB[0m debian:testing: [34mUsing /usr/bin/printf: 1024.0 KiB[0m Version: 5.2.32-1+b1 BASH_VERSION=5.2.32(1)-release [34mBefore update, built-in: 0.0 KiB[0m Version: 5.2.32-1+b2 BASH_VERSION=5.2.32(1)-release [34mAfter update, built-in: 0.0 KiB[0m debian:unstable: [34mUsing /usr/bin/printf: 1024.0 KiB[0m Version: 5.2.32-1+b1 BASH_VERSION=5.2.32(1)-release [34mBefore update, built-in: -204327741538987132533192794927419046106144370772369067144001965065161242045289853933424603039610742765779793810597801184754129275053360309618110969423231717384062432058427347826307485969762914691664330509979200032842049491957764290078785962757369350076911069969239729154736129270785769992734960976555010430713383618340788820788507559129318189208272451977269332636444203114323022392973081005658984792070869039843858287898144149816907494393321815826805422017174725641362212397539938519821902402387915413320895705572018851798903773024770029221244115172305318180547954013842232151890119353142938839169791454898465005065926350934327937223829195322959028063808579448922509632217940641525368073980231046139194063117862709414781443676490422432171223772954604204638101380839487861779434148440746775961600278624264499056578635971259610621050830286169542272919137782421338317319075022183889480724170325904581381211373420245041437586372208113285655308235814389644801887550489478983566490999306912591860811951646021902865643414075350795432827622680810271749962424003634082227874863378093578638776784259066237087884813775265768346635330503338087313703447363122979375703745557549432864913138030395126632463024603889560821970519678934045977467393462053440975465450562325255151100325454328230687913662728589694433389951492863039355068538662388789252635003645127671312972608507337872402386963230774821571948638850203879199387942528300773184537860928439736611073513100752942303358404174233156832196938336203689024572238547146236819346017882327810344060039771903531151679323202197117049111712048654523956368515592549425863389745958353085845786880925212332641389772065318078337924996388299964679406536542109261769667265207070322312122193335517386651759519095748195963254935570993428724073104430239609842771276298731491289735039699479694334555942546314619600312724647476613331912205072032729733174452468364236741182722898604302287113003441172795222784716276719168936031692017414056437097934348629747740256120177220
Tilde (~) in bash(1) is typeset incorrectly as Unicode character
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -g -ffile-prefix-map=/build/bash/src=/usr/src/debug/bash -flto=auto -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin' -DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc' -DSYS_BASH_LOGOUT='/etc/bash.bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS uname output: Linux craig 6.4.4-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 19 Jul 2023 19:19:38 + x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.1 Patch Level: 16 Release Status: release Description: In the bash manual page (`man bash`), the ASCII tilde character '~' (0x7e) is replaced by the Unicode character '˜' (U+02DC SMALL TILDE): $ man bash | grep 'additional binary operator' An additional binary operator, =˜, is available, with the same prece‐ The same happens for the use of ~ as a shorthand for the home directory. This makes the manual page incorrect, and difficult to search. It looks like there is an ASCII tilde character in the man page's source code: $ gunzip -c /usr/share/man/man1/bash.1.gz | grep 'additional binary operator' An additional binary operator, \fB=~\fP, is available, with the same I don't know the first thing about groff, but `man groff_char` suggests that ~ is indeed rendered as "modifier tilde", and that one should write \(ti to obtain an actual tilde character. I'm guessing the manpage is generated from texinfo, so if this is actually a bug in texinfo, feel free to forward this email to bug-texinfo at gnu.org.
accents
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: darwin10.7.0 Compiler: /usr/bin/gcc-4.2 Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='darwin10.7.0' -DCONF_MACHTYPE='i386-apple-darwin10.7.0' -DCONF_VENDOR='apple' -DLOCALEDIR='/Users/thomas/Administration-ordinateur/autoinstall/macports/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DMACOSX -I. -I. -I./include -I./lib -I/Users/thomas/Administration-ordinateur/autoinstall/macports/include -pipe -O2 -arch x86_64 uname output: Darwin tDeContes-fixe.local 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386 Machine Type: i386-apple-darwin10.7.0 Bash Version: 4.2 Patch Level: 8 Release Status: release Description: 1 when i do PS1="&# $PS1" then I have problems since there is some accents in my command lines : http://cjoint.com/data1/1dweGsOZD6M.htm http://cjoint.com/data1/1dweHvDnu8H.htm http://cjoint.com/data1/1dweHSHlKQq.htm http://cjoint.com/data1/1dweIqnfKNe.htm http://cjoint.com/data1/1dweINbOCMJ.htm http://cjoint.com/data1/1dweJgK8K6m.htm http://cjoint.com/data1/1dweJGszDSY.htm http://cjoint.com/data1/1dweLRlowWS.htm i heard that you had the problem without having to do PS1="&# $PS1" and that you corrected it in that case 2 without doing PS1="&# $PS1" i don't have problem when there is just one accent on a small line, but i have a lot of them when the command line is larger than the terminal and is displayed on several lines in the terminal Do you need screen captures too ? Repeat-By: make a file and give it a name containing an accent 1 - execute PS1="&# $PS1" - drag & drop the file with the accent - use "top arrow" and "bottom arrow" to move in the history : at each time you move on the line containing an accent, it eats one character 2 - type "enter" several times, to get a lot of lines printed on the terminal - drag & drop the file with the accent several times, until it makes a command line too long to be written on only one line (the command line should be larger than the terminal) : it should already begin to have a strange behavior, at this time (it doesn't continue on the next line) - use "top arrow" and "bottom arrow" to move in the history : at each time you move on the line containing an accent, it eats not only characters, but lines i would like to be kept aware about success in reproducing the bug, resolving it, etc, please :-) -- Téléassistance / Télémaintenance (adresse temporaire) http://biocer.fr/invites/thomas-de-contes/
Re: accents
Le 9 mai 2011 à 20:21, Greg Wooledge a écrit :
> On Mon, May 09, 2011 at 04:46:14PM +0200, Thomas De Contes wrote:
>> Description:
>>
>> 1
>> when i do
>> PS1="&# $PS1"
>> then I have problems since there is some accents in my command lines :
>
> What is the value of PS1 before you prepend ampersand-hash-space to it?
tDeContes-fixe:~ thomas$ echo "$PS1"
+ echo '\h:\W \u\$ '
\h:\W \u\$
tDeContes-fixe:~ thomas$ bash
+ bash
bash-4.2$ set -x
bash-4.2$ echo "$PS1"
+ echo '\s-\v\$ '
\s-\v\$
bash-4.2$
the 1st bash is a login shell
in both case (login shell or not), i have the same behavior (without/with
ampersand-hash-space)
>
> What does the ampersand-hash-space have to do with the problem?
if i do not
PS1="&# $PS1"
then i don't have the problem described in 1
>
>> i heard that you had the problem without having to do
>> PS1="&# $PS1"
>> and that you corrected it in that case
>
> Who's "you"?
bash's maintainers ("you corrected it")
Somebody told me about corrected bugs that looked like mine :
http://lists.gnu.org/archive/html/bug-bash/2009-06/msg00110.html
http://ftp.gnu.org/gnu/bash/bash-3.2-patches/bash32-049
http://ftp.gnu.org/gnu/bash/bash-3.2-patches/bash32-050
(i give you the links for info, but it's too difficult for me to understand all
of that)
>> 2
>> without doing
>> PS1="&# $PS1"
>> i don't have problem when there is just one accent on a small line, but i
>> have a lot of them when the command line is larger than the terminal and is
>> displayed on several lines in the terminal
>
> At first glance this looks like the classic "I have colors in my prompt
> and I forgot to put \[ \] in the right places",
i don't use colors, at least i don't see them and i don't want them in my
terminal
What do you think about my PS1 ?
Is there something else important about colors ?
> but it's hard to be sure
> because the description is so confusing.
happy to help you to help me :-)
>
>> Repeat-By:
>>
>> make a file and give it a name containing an accent
>
> In what locale? UTF-8, ISO-8859-1, or what?
LANG=fr_FR.UTF-8
i think that all the system works with UTF-8, and that it is the default
encoding in nearly all the applications, now
> Is the accented character
> a single-byte character, or a multi-byte character, in your locale?
a multi-byte character, i think
How to confirm that ?
>
>> 1
>> - execute
>> PS1="&# $PS1"
>> - drag & drop the file with the accent
>> - use "top arrow" and "bottom arrow" to move in the history :
>> at each time you move on the line containing an accent, it eats one character
>
> I did this in an ISO-8859-1 locale and did not reproduce the problem.
>
> Then I did it on a UTF-8 locale (differet computer) and also did not
> reproduce the problem. Granted, I'm controlling the UTF-8 X session
> from the mouse and keyboard that are on the ISO-8859-1 machine, but
> od -t x1 tells me that the file name I created on the UTF-8 machine
> has a multi-byte character in it, so I'm not sure what is required
> to reproduce the issue.
i heard that mac os x and linux both use UTF-8 for their file system, but not
"the same UTF-8" (that causes problems when sharing external hard disks, for
example)
How to know exactly which characters I put in my terminal, to allow you to do
the same in your ?
Oh, i've found that, tell me if it's wrong :
$ echo /Users/thomas/Downloads/réz | h
+ echo $'/Users/thomas/Downloads/re?\201z'
+ hexdump -C
2f 55 73 65 72 73 2f 74 68 6f 6d 61 73 2f 44 6f |/Users/thomas/Do|
0010 77 6e 6c 6f 61 64 73 2f 72 65 cc 81 7a 0a|wnloads/re..z.|
001e
thank you for the feed back, i hope we'll find what's wrong :-)
--
Téléassistance / Télémaintenance
(adresse temporaire)
http://biocer.fr/invites/thomas-de-contes/
Re: accents
Le 16 mai 2011 à 17:02, Chet Ramey a écrit : > On 5/9/11 10:46 AM, Thomas De Contes wrote: >> 1 >> - execute >> PS1="&# $PS1" >> - drag & drop the file with the accent >> - use "top arrow" and "bottom arrow" to move in the history : >> at each time you move on the line containing an accent, it eats one character >> >> 2 >> - type "enter" several times, to get a lot of lines printed on the terminal >> - drag & drop the file with the accent several times, until it makes a >> command line too long to be written on only one line (the command line >> should be larger than the terminal) : >> it should already begin to have a strange behavior, at this time (it doesn't >> continue on the next line) >> - use "top arrow" and "bottom arrow" to move in the history : >> at each time you move on the line containing an accent, it eats not only >> characters, but lines > > These are both the result of a bug in Mac OS X. Its implementation of > wcwidth doesn't return correct results for Unicode and UTF-8 combining > characters. so, wcwidth is apple's responsibility, then no libre-software developer can do anything, Am I right ? How to report this problem to apple ? Or maybe is it already done ? well, i don't think that apple will correct it in 10.6, So, to work quietly, I think there is an other option : ask bash to not display special characters on the interactive line (all what i type) i think that 10.4 was configured so that, but i don't know how apple had configured bash it displayed things like "\65\301" instead of "é" (i think) it was not very nice for eyes, but at least there was no big bugs like described above :-) > Take a look at my messages from yesterday for more details. well, i red them, but i don't understand a lot of thing in this domain :-/ thank you very much for all :-) -- Téléassistance / Télémaintenance (adresse temporaire) http://biocer.fr/invites/thomas-de-contes/
Re: accents
Le 25 août 2011 à 14:36, Greg Wooledge a écrit : > On Wed, Aug 24, 2011 at 06:51:32PM -0700, Linda Walsh wrote: >> BTW, Thomas -- what is the Character that comes after 'De' in your >> name? I read it as hex '0xc282c2' which doesn't seem to be valid unicode. (it is NBSP (for address book)) > > RFC 2822 (section 2.2) says that Header Fields in an email must be > composed of US-ASCII characters i don't know very well how to read RFCs, but in "=?iso-8859-1?Q?Thomas_De=A0Contes?=" Aren't there all the needed informations to translate that in readable characters ? -- Téléassistance / Télémaintenance (adresse temporaire) http://biocer.fr/invites/thomas-de-contes/
Re: accents
Le 25 août 2011 à 14:17, Chet Ramey a écrit : >> so, wcwidth is apple's responsibility, then no libre-software developer can >> do anything, >> Am I right ? > > To a certain extent, yes. wcwidth is a libc function, and it has a bug > on Mac OS X. Well, libc is a part of linux, isn't it ? Does that mean that it is a part of Darwin, not of proprietary layers of Mac OS X ? (it is only of curiosity, do not continue if that annoys you) > I will have a workaround in the next readline release. so i will be able to use it without having to make a workaround myself ? very good news :-)) (How can I know when it will be available ?) -- Téléassistance / Télémaintenance (adresse temporaire) http://biocer.fr/invites/thomas-de-contes/
Re: accents
Le 25 août 2011 à 15:35, Chet Ramey a écrit : >> >> Le 25 août 2011 à 14:17, Chet Ramey a écrit : >> >>>> so, wcwidth is apple's responsibility, then no libre-software developer >>>> can do anything, >>>> Am I right ? >>> >>> To a certain extent, yes. wcwidth is a libc function, and it has a bug >>> on Mac OS X. >> >> Well, libc is a part of linux, isn't it ? > > Sure, Linux has a libc, but Mac OS X isn't Linux. > >> Does that mean that it is a part of Darwin, not of proprietary layers of Mac >> OS X ? > > Yes, I'm sure that part of the C library is part of Darwin. It's > theoretically > possible to fix it and send the fix back to Apple. What they do with that fix > is their business, of course. thank you for explanations :-) > >> (How can I know when it will be available ?) > > I can put you in the testing pool, if you'd like. no thank you, because i use MacPorts to install all unix tools i need, and i don't know how to insert a testing stuff in MacPorts mechanism on the other hand, if there is a way for bash to not display special characters on the interactive line, i suppose it can be useful to know how to do that in many cases, for example if i switch on a new platform, waiting for making special characters to be displayed correctly (Is it correct english enough ?) -- Téléassistance / Télémaintenance (adresse temporaire) http://biocer.fr/invites/thomas-de-contes/
Bash high memory usage in simple for loop?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey there, I just encountered some dubious behaviour... Feeding a large data set in a "for i in..." loop doing nothing causes exponentially large memory usage, and that memory is never freed (although is seems to be re-used over multiple runs...) For instance I have 68M of small numbers (1..256) separated by newlines and that makes bash grow over 1.6G, even when ann it does inside the loop is calling true. The only way I can free up the memory is to leave the shell. You can test easily with this command (you might want to limit your memory with ulimit first to avoid trashing your system...): $ for i in `seq 1 1000`; do true; done On my test system this requires 1G of memory, and memory climbs a bit higher on additional runs but settles at 1.1G (it doesn't seem to leak any memory part this point. This is running: GNU bash, version 4.1.7(2)-release (i486-slackware-linux-gnu) On Slackware-13.1 I also verified this behaviour on: GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu) (Ubuntu Lucid) Is this normal or expected? Thanks - -- Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkygDXQACgkQ6dZ+Kt5BchbETwCgxflyi4SH3S2j9e+tpPz6gUay dU0An10OakENErpDNNFZNQgoQbZwsJ+B =ZlLd -END PGP SIGNATURE-
bug: readonly array that is empty causes error (whereas not empty does not)
The following script is okay
set -ue
readonly -a a=('')
Yet, the following script fails with exit code 1
set -ue
readonly -a a=()
In my case, I would like to preserve a copy of all passed arguments:
set -ue
readonly -a ARGS=("${@}")
If no arguments are passed then the script fails. It's surprising the
error behavior diverges depending upon setting an empty array or non-empty
array.
*-James Thomas Moon*
Bash symlink not followed as expected.
Hey All, Not sure if this is a bug but logging anyway just in case. Rgds, Thomas * The version number and release status of Bash (e.g., 2.05-release) o GNU bash, version 3.00.16(1)-release-(i386-pc-solaris2.10) * The machine and OS that it is running on (you may run /bashversion -l/ from the bash build directory or look at the `.made' file in that directory for this information) o Netra x4450 oOracle Solaris 10 9/10 s10x_u9wos_14a X86 Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. Assembled 11 August 2010 * A description of the bug Symlink path is not followed as expected. For example: bash-3.00# pwd /ee/oce bash-3.00# ls -l oracle lrwxrwxrwx 1 oracle oinstall 6 Oct 12 12:03 oracle -> ../oce bash-3.00# cd oracle bash-3.00# pwd /ee/oce/oracle bash-3.00# cd oracle bash-3.00# pwd /ee/oce/oracle/oracle bash-3.00# cd oracle bash-3.00# pwd /ee/oce/oracle/oracle/oracle bash-3.00# cd oracle bash-3.00# pwd /ee/oce/oracle/oracle/oracle/oracle bash-3.00# sh # pwd /export/home/database/11g/oce # cd /ee/oce # ls -l oracle lrwxrwxrwx 1 oracle oinstall 6 Oct 12 12:03 oracle -> ../oce # cd oracle # pwd /export/home/database/11g/oce # cd oracle # pwd /export/home/database/11g/oce * A recipe for recreating the bug reliably Make a directory and symlink back to a previous directory. # cd /var/tmp # mkdir tom # cd tom # ln -s ../tom link # cd link # pwd /var/tmp/tom # cd link # pwd /var/tmp/tom # bash bash-3.00# cd link bash-3.00# cd link bash-3.00# pwd /var/tmp/tom/link/link * A fix for the bug if you have one!
Confusing documentation of `ENV` in section "Bash variables"
The documentation says: 'ENV' Similar to 'BASH_ENV'; used when the shell is invoked in POSIX Mode (*note Bash POSIX Mode::). However, as described elsewhere in the manual, BASH_ENV is used specifically for non-interactive shells, whereas ENV is used specifically for interactive shells. From the quoted section above, one might get the erroneous impression that ENV is just like BASH_ENV but for POSIX mode. If I've not misunderstood, maybe a little more explanation in the quoted section would be a good idea? Even just changing "invoked" to "invoked interactively". Although that then runs the risk of implying that BASH_ENV is also used in interactive mode. Alternatively, remove "Similar to 'BASH_ENV';". -- https://rrt.sc3d.org
Re: Confusing documentation of `ENV` in section "Bash variables"
On Wed, 23 Sep 2020 at 14:24, Chet Ramey wrote: > "Expanded and executed similarly to BASH_ENV when an interactive shell is > invoked in POSIX Mode." > Yes, that's better than my suggestions, thanks! -- https://rrt.sc3d.org
AW: Re: read command sometimes misses newline on timeout
I agree with you, but it should never happen that read returns timeout, also returns the full line and has already read the newline character. If that happens, there is no way for the script to decide what to do. Please see the provided test script, it showcases the error. If I did a mistake there, I would gladly change it. But I currently don't see any way how to handle this properly from the script side. Please also see the answer from Martin D Kealey, I think he is on to something: https://lists.gnu.org/archive/html/bug-bash/2024-10/msg7.html On 10/4/24 8:18 AM, Thomas Oettli via Bug reports for the GNU Bourne Again SHell wrote: > Bash Version: 5.2 > Patch Level: 26 > Release Status: release > > Description: > I have tried to write a bash script that asynchronously reads from a pipe > (line by line) with the help of "read -t". > If the timeout occurs in just the right moment, read returns the full line, > but the return code says timeout (rc > 128). If the read command times out, it always returns > 128, so if you have a return code in that range, you can assume read timed out and react accordingly. > Therefor it is not possible to know if a full line was returned or not. When read times out, it always returns what it read before the timeout in the buffer, so you don't lose any data. Whether or not that's a `full line' is up to timing, and it's up to the script to decide how to cope with it. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
AW: Re: read command sometimes misses newline on timeout
I know that it works in that case.
This is just an example that tries to force read into the same situatiation
that I hit in a real world example in which I don't control the input.
Von: alex xmb sw ratchev
Gesendet: Montag, 7. Oktober 2024 19:17
An: Thomas Oettli
Cc: bug-bash@gnu.org ; chet.ra...@case.edu
Betreff: [EXT] Re: read command sometimes misses newline on timeout
CAUTION: This email originated from outside the SFS organization. Do not follow
guidance, click links or open attachments unless you recognize the sender and
know the content is safe.
MAIL FROM: <@fxmb...@gmail.com>Report as Spam / Check
Mail<https://mail2.sfs.biz/pyquarantine.php?quarantine=orig&action=report_or_check&mailfrom=fxmbsw7%40gmail.com&id=20241007191742_006EB2A9EAD22>
well try remove the -n in echo
On Monday, October 7, 2024, Thomas Oettli
mailto:thomas.oet...@sfs.com>> wrote:
Sorry Alex, I don't understand exactly what you mean.
Here is the Test-Script again with some comments:
function reader() {
local buf line
while :; do
read -t .01 buf # try to read line to $buf with timeout
rc=$?
if (( rc == 0 )); then # got a full line or the rest of a
partial line, append $buf to $line
line+=$buf
elif (( rc > 128 )); then# ran into timeout
line+=$buf # maybe received partial line, append
$buf to $line and continue reading
continue
fi
# at this point, the content of $line should always be "TEST"
[[ $line != TEST ]] && echo Invalid line: $line && exit
echo OK
line="" # prepare to read next line, set $line
to empty string
done
}
reader < <(
while :; do
echo -n TEST
sleep .00$(($RANDOM%10))
echo
done
)
Could you please explain to me, where exactly the mistake is? I don't know if
you ran the script by yourself, but on all of my machines it exits after just a
few seconds
with the following output:
Invalid line: TESTTEST
Von: alex xmb sw ratchev mailto:fxmb...@gmail.com>>
Gesendet: Montag, 7. Oktober 2024 16:41
An: Thomas Oettli mailto:thomas.oet...@sfs.com>>
Cc: bug-bash@gnu.org<mailto:bug-bash@gnu.org>
mailto:bug-bash@gnu.org>>;
chet.ra...@case.edu<mailto:chet.ra...@case.edu>
mailto:chet.ra...@case.edu>>
Betreff: [EXT] Re: read command sometimes misses newline on timeout
CAUTION: This email originated from outside the SFS organization. Do not follow
guidance, click links or open attachments unless you recognize the sender and
know the content is safe.
MAIL FROM: <@fxmb...@gmail.com>Report as Spam / Check
Mail<https://mail1.sfs.biz/pyquarantine.php?quarantine=orig&action=report_or_check&mailfrom=fxmbsw7%40gmail.com&id=20241007164140_2F94A29C1A462>
there is a case , u [[ $readreply ]] after read
On Monday, October 7, 2024, Thomas Oettli via Bug reports for the GNU Bourne
Again SHell mailto:bug-bash@gnu.org>> wrote:
I agree with you, but it should never happen that read returns timeout, also
returns the full line and has already read the newline character.
If that happens, there is no way for the script to decide what to do. Please
see the provided test script, it showcases the error.
If I did a mistake there, I would gladly change it. But I currently don't see
any way how to handle this properly from the script side.
Please also see the answer from Martin D Kealey, I think he is on to something:
https://lists.gnu.org/archive/html/bug-bash/2024-10/msg7.html
On 10/4/24 8:18 AM, Thomas Oettli via Bug reports for the GNU Bourne Again
SHell wrote:
> Bash Version: 5.2
> Patch Level: 26
> Release Status: release
>
> Description:
> I have tried to write a bash script that asynchronously reads from a pipe
> (line by line) with the help of "read -t".
> If the timeout occurs in just the right moment, read returns the full line,
> but the return code says timeout (rc > 128).
If the read command times out, it always returns > 128, so if you have a
return code in that range, you can assume read timed out and react
accordingly.
> Therefor it is not possible to know if a full line was returned or not.
When read times out, it always returns what it read before the timeout in
the buffer, so you don't lose any data. Whether or not that's a `full line'
is up to timing, and it's up to the script to decide how to cope with it.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu<mailto:c...@case.edu>
http://tiswww.cwru.edu/~chet/
AW: Re: AW: Re: AW: Re: read command sometimes misses newline on timeout
Got it, I just backported your patch to Bash 5.2 and it fixed the issue on my build host. I will roll out the patched version to all my hosts this weekend and keep you noticed if anything strange happens. BTW: will this patch be backported to previous Bash versions? Von: Chet Ramey Gesendet: Dienstag, 15. Oktober 2024 16:24 An: Thomas Oettli ; bug-bash@gnu.org Cc: chet.ra...@case.edu Betreff: [EXT] Re: AW: Re: AW: Re: read command sometimes misses newline on timeout CAUTION: This email originated from outside the SFS organization. Do not follow guidance, click links or open attachments unless you recognize the sender and know the content is safe. MAIL FROM: <@chet.ra...@case.edu> Report as Spam / Check Mail<https://mail2.sfs.biz/pyquarantine.php?quarantine=orig&action=report_or_check&mailfrom=chet.ramey%40case.edu&id=20241015162437_EB0C62AD3BACE> On 10/15/24 10:06 AM, Thomas Oettli wrote: > That sounds promising. Is the fix somewhere accessible for me? I would gladly > test it. I pushed it to the devel branch this morning. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
