Re: built-in regex matches wrong character

In article , Eric Blake wrote: >But bash could be taught to convert any regex that contains a range with >both endpoints ASCII into a different bracket expression before handing >things over to regcomp(). That is, if the user is matching against >[a-d], bash hands [abcd] to regcomp() instead.

Re: Rational Range Interpretation for bash-5.0?

In article , Chet Ramey wrote: >Hi. I am considering making bash glob expansion implement rational range >interpretation starting with bash-5.0 -- basically making globasciiranges >the default. It looks like glibc is going to do this for version 2.28 (at >least for a-z, A-Z, and 0-9), and other G

Re: Bash crash

Sounds like a hardware problem with the RAM on your system HTH, Arnold In article you write: >Hi Chet, > >Thank you for your response. > >But it does not make sense since sbrk failure will be checked: > > mp = (union mhead *) sbrk (sbrk_amt); > > /* Totally out of memory. */ > if ((long)

Re: Feature Request re: syslog and bashhist

In article , aixtools wrote: >In short, having it included in ./configure simply give it much more >visibility - and perhaps adoption. Personally, I think that having bash send executed commands to syslog is an invasion of privacy; I'm surprised such a feature is even there at all... My two ce

Re: printf and the $ modifier

In article , Chet Ramey wrote: >3. There's not actually a lot of demand to make it available, and few > implementations go through the pain (even the standalone GNU printf). > The only one I found after a quick non-exhaustive search is the ksh93 > builtin, which doesn't use the libc printf

Re: Not so useless use of cat

In article , Chet Ramey wrote: >On 9/17/14, 3:07 AM, Aharon Robbins wrote: > >>> I've considered emulating it everywhere, regardless of what the OS >>> provides, but I'd get just as many complaints if I did that. >>> >>> Chet >> >>

Re: Not so useless use of cat

In article , Chet Ramey wrote: >On 9/16/14, 3:00 PM, Bob Proulx wrote: > >> That is one of the reasons I don't like the /dev/std{err,in,out} >> things. They are not portable. They do different things on different >> systems. I avoid them. > >I've considered emulating it everywhere, regardless

Re: let's establish BASH_MINIMUM_TIME_BETWEEN_INTERACTIVE_COMMAND

In article , wrote: >Gentlemen, I have once again come up with a million dollar idea for bash, >revolutionizing the shell world. > >As we all know, nobody in their right mind could type more than one >command per second into bash when in interactive mode. > >So let's establish BASH_MINIMUM_TIME_B

Re: feature request: file_not_found_handle()

Hi. > Date: Tue, 20 Aug 2013 11:02:24 -0400 > From: Greg Wooledge > To: Aharon Robbins > Cc: bug-bash@gnu.org > Subject: Re: feature request: file_not_found_handle() > > On Tue, Aug 20, 2013 at 05:48:12PM +0300, Aharon Robbins wrote: > > In article you write: > &g

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

[ I know I'm going to regret this... ] > `[a-z]' is case insensitive > > You are encountering problems with locales. POSIX mandates that `[a-z]' > uses the current locale's collation order -- in C parlance, that means > strcoll(3) instead of strcmp(3). As of the 2008 standard, this is no l

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

> >> I would suggest distros to rip out the #else part of this #ifndef. > > > > And I wouldn't, but as I have no control over the distros, I'm > > not going to worry about it. > > > > All I know is that with the non-gawk case, gawk fails its test suite, > > and I've given up discussing it. > > Yo

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

> Date: Thu, 27 Jun 2013 15:27:40 +0200 > From: Paolo Bonzini > Subject: Re: locale specific ordering in EN_US -- why is a > Right now only gawk is different from the others, and not in a very > clean manner: > > #ifndef GAWK > /* Defer to the system regex library about the meaning >

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

Hi Paolo. > I still believe that there is no place other than the glibc locale > descriptions where this can be fixed. This is necessary but not sufficient. All of gawk, grep, sed and bash run on lots of non-GLIBC systems. The locale definitions, even for the same locale, vary wildly out in the

Re: No such file or directory

In article , Michael Williamson wrote: >Hi, > >I have a complaint. Apparently, when unknowingly attempting to run a >32-bit executable file on a 64-bit computer, bash gives the error message >"No such file or directory". That error message is baffling and frustratingly >unhelpful. Is it possible

Re: Any chance of multi-dimensional arrays?

In article , Eduardo Bustamante wrote: >There are a lot of general purpose languages (not shell languages), that >support multi-dimensional arrays. And these languages can call external >tools just fine. Python, Perl, Ruby, ... pick one. Even Awk has faked >support for multi-dimensional arrays.

Re: tab completion with variable expansion broken

In article , Chet Ramey wrote: >On 10/14/12 8:52 AM, William F Hammond wrote: >> >> 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' -D

Re: square bracket vs. curly brace character ranges

Hi Bob, In article , Bob Proulx wrote: >Hi Arnold, > >Aharon Robbins wrote: >> You are ssuming here that everyone uses GLIBC. > >I don't know so I will ask. Isn't the problem endemic to glibc? Do >other libc's such as HP-UX or AIX or other have this

Re: square bracket vs. curly brace character ranges

In article , Bob Proulx wrote: >Marcel Giannelia wrote: >> locale-dependent [a-c] suggests to me that the software should be >> changed to just do what people expect, especially since nothing is >> really lost by doing so. > >I know that some projects are doing just that. I don't know the plans

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

In article , Linda Walsh wrote: >Greg Wooledge wrote: > >> On Sun, May 20, 2012 at 11:36:35AM -0700, Linda Walsh wrote: > >> For instance, on HP-UX 10.20, in the en_US.iso88591 locale: >> A a ... B b >> Meanwhile, on Debian 6.0, in the en_US.iso88591 locale: >> a A ... b B >> >> A

Re: status on $[arith] for eval arith vsl $((arith))??

In article , Linda Walsh wrote: >>> Because, as Linda discovered, there is still working code out there using >>> it. Maybe we'll get to a point where it's all gone, but we're not there >>> yet. >> >> IMO, the working code out there that relies on $[...] either runs on >>older versions of bash.

Re: documentation bug re character range expressions

This is a thorny issue that plagues all POSIX-compliant utilities, not just Bash. (POSIX locales are just a blight.) For gawk 4.0, I have said "to heck with it" and changed gawk so that ranges act like they are in the C locale (unless --posix is used). I and some other people are campaigning to

Re: Readline : move to previous/next path component

In article <[EMAIL PROTECTED]>, Andre Majorel <[EMAIL PROTECTED]> wrote: >Vi mode would help, but in Bash, there's no way to switch >between it and Emacs mode on the fly. Au contraire: set -o vi set -o emacs -- Aharon (Arnold) Robbins arnold AT sk

Re: ESC . vs. ^R, ^P again

I think you want ESC _ which will pull in the last word of the previous command. Arnold In article <[EMAIL PROTECTED]> you write: >As there years pass I use ESC . daily hoping that it will get the last >chunk of the previous line on my screen, despite any ^P's or ^R's I >might have done. > >Never

Re: nocaseglob

>Bruce Korb wrote: >> Exactly. And I want to learn how to shoot that dang thing down. Dead. >> If I've cleared my environment of LC_* and LANG values, then by gum >> ``echo [a-z]*'' should work the way it has for the past 35 years, and >> not some newfangled thing that somebody thought would be "