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
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
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
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
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.
Tim.
*/
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 [EMAIL
PROTECTED]
Bug-Reference-ID
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'
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-bit
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'
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'
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:
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:
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
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'
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))
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)
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
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
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
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'
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'
21 matches
Mail list logo
