incorrect 'LC_ALL=C export LC_ALL' behavour

Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: i386-redhat-linux-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/s

[patch] unsafe signal handler

Hi, Here is a patch which aims to address the problem reported earlier: http://lists.gnu.org/archive/html/bug-bash/2005-07/msg00129.html by making the signal handler set a flag which is then checked at strategic points in the main flow of code. What do you think? Tim. */ --- bash-3.0/sig.c.

[patch] memory leak in read builtin

There is at least one memory leak in the read builtin in bash-3.0. To demonstrate it, try this test case: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173283#c10 There is a link to a file, nonblock.c, which you should compile like 'make nonblock'. Then run the short script to see the

Incorrect completion when quoting last component of path

Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: i386-redhat-linux-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/s

Re: [patch] Re: Job-handling bug in bash-3.0 and bash-2.05b

On Mon, Mar 21, 2005 at 03:29:24PM -0500, Chet Ramey wrote: > > This job-handling bug is still present. Chet, would you mind > > commenting on it? > > It will be fixed in bash-3.1. It isn't. The symptom has changed, however: bash now segfaults. #0 0x0807722c in find_last_proc (job=1243, bloc

[patch] 3.1: man page corrections

When viewing the bash man page with 'man bash' in a locale that supports UTF-8 (for example), the single-quote character "'" doesn't necessarily display as we want. For a literal single-quote character, "\(aq" is needed in the groff input. Original bug report: https://bugzilla.redhat.com/bugzi

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

Comparing bash-3.0 (with config-top.h modified so that DONT_REPORT_SIGPIPE is defined) with bash-3.1 (where this is the default anyway) shows up a change in behaviour. bash-3.0: $ bash -c 'trap exit SIGPIPE; echo foo' | : $ bash-3.1: $ bash -c 'trap exit SIGPIPE; echo foo' | : bash: line 0: ec

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

On Mon, Jan 09, 2006 at 02:22:11PM -0500, Chet Ramey wrote: > > bash-3.1: > > > > $ bash -c 'trap exit SIGPIPE; echo foo' | : > > bash: line 0: echo: write error: Broken pipe > > $ > > > > Is this change in behaviour intentional, or a regression? > > It's intentional, and doesn't have anything

[patch] fix 'exec -l /bin/bash'

Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: i386-redhat-linux-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/s

inputrc parsing regression?

Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: i386-redhat-linux-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/s

Re: inputrc parsing regression?

On Tue, Jan 17, 2006 at 05:08:35PM -0500, Chet Ramey wrote: > Before bash-3.1/readline-5.1, key binding did not honor the setting of > convert-meta. The current version treats a key binding exactly the way > readline will when reading a key sequence and dispatching on it, > converting to eight-bi

incorrect brace expansion

Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: i386-redhat-linux-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/s

Re: Bash-3.1 official patch 7

On Sun, Feb 05, 2006 at 01:38:47PM -0500, Chet Ramey wrote: >BASH PATCH REPORT >= > > Bash-Release: 3.1 > Patch-ID: bash31-007 > > Bug-Reported-by: Tim Waugh <[EMAIL PROTECTED]>, Laird Breyer &

Re: [patch] memory leak in read builtin

Hi, I posted two patches for memory leaks in bash-3.0. One of them has made it into bash-3.1, but the other has not. Here is the missing one: On Wed, Dec 07, 2005 at 06:10:07PM +, Tim Waugh wrote: > There is at least one memory leak in the read builtin in bash-3.0. To > demonstr

Function/alias recursion

What is the intended behaviour for this sort of thing?: $ cat <<"EOF" >trouble hello () { pwd } alias pwd="hello" EOF $ source trouble $ source trouble $ pwd The behaviour I've observed with bash-3.2 and several earlier releases is that bash consumes all available memory and then crashes. Ti

Re: Quoting near =~ is inconsistent

Further to this, I am having trouble porting existing scripts to bash-3.2's new style of regex matching. Here is one example that is problematic: I want to use a character class in my regex, but bash seems to get confused by the ':]]' closing the class, and apparently takes it as a ']]' closing th

Re: nocaseglob

On Mon, 2007-01-22 at 08:04 -0800, Bruce Korb wrote: > There seems to be something else aside from LC_ALL, LC_COLLATE > and LANG that affects collating sequence. Notice the difference > between "[a-d]*" and "[a-D]*". Whatever collating sequence is being used > do select files puts "D" after "d",

Re: nocaseglob

On Tue, 2007-01-23 at 17:17 +0100, Andreas Schwab wrote: > glibc definitely uses strcoll as well. Most likely python has its own > implementation which gets it wrong. No, really, this is going through glibc's __collseq_table_lookup function. The Python example is just an easy-to-run distilled te

Re: nocaseglob

On Tue, 2007-01-23 at 14:14 -0500, Chet Ramey wrote: > The portable, standard way to perform character comparison using the > current locale is strcoll(). If I can't get the same results using > strcoll(), glibc is clearly doing something different internally. (And > there is no portable standard

Re: Why bash is not so efficient as cron?

Are the two environments setting different locales perhaps? If the character encoding is UTF-8 there is quite a bit more work that needs to be done compared to the C locale. Tim. */ signature.asc Description: This is a digitally signed message part _

Re: Bash-3.2 Official Patch 10

On Mon, 2007-03-05 at 17:49 -0500, Chet Ramey wrote: > The glibc implementation of regcomp/regexec does not allow backslashes to > escape "ordinary" pattern characters when matching. Bash used backslashes > to quote all characters when the pattern argument to the [[ special > command's =~ operator

"cd .." when WD unlinked gives wrong behaviour

Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: i386-redhat-linux-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/s

PS1 \W behaviour: how to get the "old" way back?

In bash-3.0 this was added: kk. The `\W' prompt expansion now abbreviates $HOME as `~', like `\w'. It seems that a large number of people preferred things the way they were before, with \W giving the basename with no tilde abbreviation. Since there is no easy way of achieving this without resort

Re: PS1 \W behaviour: how to get the "old" way back?

On Wed, Feb 23, 2005 at 02:15:12PM -0500, Chet Ramey wrote: > Unless I'm reading this wrong, ${PWD##*/} does the job (though it fails > if PWD == '/'). You can always use $(basename $PWD). Oh -- silly of me. I'd forgotten that PS1 gets expanded. ${PWD##/*/} does what I want, except for the cor

compiler warnings

When compiling bash with GCC there are a number of alarming-looking warnings, and several of them could be avoided by minor changes to the code. For example: bashline.c:2976: warning: suggest parentheses around assignment used as truth value for (passc = 0; c = string[i]; i++) This could more

control may reach end of non-void function

Hi, In bash-3.0, bashline.c gives this warning during compilation: bashline.c:1418: warning: control may reach end of non-void function 'bash_directory_expansion' being inlined Since that function is only used once, and in that instance the return value is not examined---and since there are no r

PS1 \W crash with PWD unset

Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: i386-redhat-linux-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/s

sh -c 'kill -SIGTERM $$' -> 'invalid signal specification'

With bash-3.0.14, this command: sh -c 'kill -SIGTERM $$' gives this error: sh: line 0: kill: SIGTERM: invalid signal specification The man page for bash says that 'sigspec is either a case-insensitive signal name such as SIGKILL (with or without the SIG prefix)'. Should the documentation be co

Re: sh -c 'kill -SIGTERM $$' -> 'invalid signal specification'

On Fri, Mar 18, 2005 at 10:33:29AM -0500, Chet Ramey wrote: > Since the behavior is as it stands because of Posix requirements, it > appears that I should copy the posix mode section of the texinfo manual > to the man page. After all, it's not long enough now. Oops! I'll have to remember to loo

Re: ((...) && (...)) parsing confused by line break

Hi Chet, I think you said you'd fixed this bug. Could you post the patch you used please? Thanks, Tim. */ On Mon, Jan 31, 2005 at 12:15:39PM +0000, Tim Waugh wrote: > Configuration Information [Automatically generated, do not change]: > Machine: i386 > OS: linux-gnu > Comp

Re: [patch] Re: Job-handling bug in bash-3.0 and bash-2.05b

This job-handling bug is still present. Chet, would you mind commenting on it? Thanks, Tim. */ pgpFxUtUb4RoU.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

">/inaccessible" gives incorrect error

Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: i386-redhat-linux-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/s

Re: bug in bash handling of PS1 prompt

On Wed, Jun 22, 2005 at 03:21:46PM -0700, [EMAIL PROTECTED] wrote: > When assigning to PS1 to change the prompt, bash > appears to append any new value to the initial default > value, rather than to replace it. I expect you have PROMPT_COMMAND set. Tim. */ pgpZD44ZaRlI8.pgp Description: PGP si

Re: Update on parent exiting after background command substitution

On Thu, Jun 30, 2005 at 08:57:07AM -0400, Chet Ramey wrote: > This is a classic race condition. It's already been fixed for the > next version. Is it possible to see what the fix is? It seems like quite a nasty bug! Tim. */ pgpJZpbgzWPwb.pgp Description: PGP signature ___

unsafe signal handler

The signal handler termination_unwind_protect() can call maybe_save_shell_history() -> append_history() -> history_do_write() -> history_filename() -> xmalloc() -> malloc() and malloc() is not safe to call from a signal handler. This affects bash-2.05b as well as bash-3.0. Tim. */ ref 163235 pg

Re: unsafe signal handler

Further information on unsafe functions used in signal handlers: a brief inspection of the code in the termination_unwind_protect() handler revealed other instances than the one highlighted before: run_interrupt_trap->_run_trap_internal->savestring->xmalloc (and more like that) maybe_save_shell_h

Re: unsafe signal handler

I am looking at bash-3.0, trying to untangle the termination_unwind_protect() signal handler. I cannot work out under what circumstances the function run_interrupt_trap() is called. sighandler termination_unwind_protect (sig) int sig; { if (sig == SIGINT && signal_is_trapped (SIGINT))