Re: built-in regex matches wrong character

[Aharon Robbins]

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.  You don't need a flag in 
>regcomp() to get RRI, just merely some pre-processing (and often memory 
>allocation, as the expansion of a range into a non-range tends to 
>require more characters).

This is easy and inexpensive for ASCII only.  Full RRI does the
same thing for wide character sets as well, though, and there
the possibility for using very large amounts of memory makes the
rewrite-the-range idea less palatable.
-- 
Aharon (Arnold) Robbins arnold AT skeeve DOT com

Re: Rational Range Interpretation for bash-5.0?

[Aharon Robbins]

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 GNU utilities have done it for some
>time. What do folks think?
>
>Chet

As the Founding Father of the Society for Rational Range Interpretation
I can only say that I think this is a wonderful idea!!  Yes, please
do it!

Arnold
-- 
Aharon (Arnold) Robbins arnold AT skeeve DOT com

Re: Bash crash

[Aharon Robbins]

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)mp == -1)
>goto morecore_done;
>
>The script just runs when my equipment boots up. Also it is hard to
>reproduce in my environment. Only every few times of my equipment
>booting up, it generates a coredump file.
>
>-Original Message-
>From: Chet Ramey [mailto:chet.ra...@case.edu] 
>Sent: 2015年10月20日 21:31
>To: Kai Wang X; bug-bash@gnu.org
>Cc: chet.ra...@case.edu
>Subject: Re: Bash crash
>
>On 10/19/15 10:47 PM, Kai Wang X wrote:
>> Dear,
>> 
>>  
>> 
>> We have two products which are using bash 4.2 and 4.3 separately. They 
>> all meet bash crash issue. Please refer to the attached files.
>> 
>> It is hard for me to understand the bash source code to find the root 
>> cause out.
>
>It really looks like sbrk(2) is failing here, but since I don't have any
>way to reproduce it, that may not be it.  This could be caused by your
>process exceeding its memory resource limit or your system's swap space
>being exhausted.
>
>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/


-- 
Aharon (Arnold) Robbins arnold AT skeeve DOT com

Re: Feature Request re: syslog and bashhist

[Aharon Robbins]

In article mailman.8184.1439375524.904.bug-b...@gnu.org,
aixtools  aixto...@gmail.com 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 cents,

Arnold
-- 
Aharon (Arnold) Robbins arnold AT skeeve DOT com

Re: Not so useless use of cat

[Aharon Robbins]

In article mailman.9035.1410965700.1147.bug-b...@gnu.org,
Chet Ramey  chet.ra...@case.edu 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
 
 This is what gawk does. I haven't had any complaints about this,
 and once you do it that way you can claim that Bash is being consistent
 across all systems.  (That's one of the reasons I did it that way.)
 My two cents, of course.

Sure.  It's a choice between internal and external consistency.  If I
emulated /dev/std* (and maybe /dev/fd/*) internally in bash, bash would
behave the same everywhere, but, as Andreas said, I'd get questions
about why `foo -o /dev/stdout' and `foo /dev/stdout' behaved differently.

Yes, I live with the damned-if-you-do, damned-if-you-don't all the
time too.  It sounds like you've already decided which way you want
things to be. :-)
-- 
Aharon (Arnold) Robbins arnold AT skeeve DOT com
P.O. Box 354Home Phone: +972 8 979-0381
Nof Ayalon
D.N. Shimshon 9978500   ISRAEL

Re: Not so useless use of cat

[Aharon Robbins]

In article mailman.8994.1410897983.1147.bug-b...@gnu.org,
Chet Ramey  chet.ra...@case.edu 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 of what the OS
provides, but I'd get just as many complaints if I did that.

Chet

This is what gawk does. I haven't had any complaints about this,
and once you do it that way you can claim that Bash is being consistent
across all systems.  (That's one of the reasons I did it that way.)
My two cents, of course.

Arnold
-- 
Aharon (Arnold) Robbins arnold AT skeeve DOT com
P.O. Box 354Home Phone: +972 8 979-0381
Nof Ayalon
D.N. Shimshon 9978500   ISRAEL

Re: let's establish BASH_MINIMUM_TIME_BETWEEN_INTERACTIVE_COMMAND

[Aharon Robbins]

In article mailman.13136.1391044881.10748.bug-b...@gnu.org,
 jida...@jidanni.org 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_BETWEEN_INTERACTIVE_COMMAND=1.0

I bet Chet would be happy to evaluate a patch to the code and documentation
once you submit it (the other proposed solutions notwithstanding).

Arnold
-- 
Aharon (Arnold) Robbins arnold AT skeeve DOT com
P.O. Box 354Home Phone: +972 8 979-0381
Nof Ayalon
D.N. Shimshon 9978500   ISRAEL

Re: locale specific ordering in EN_US -- why is aAbByYzZ?

[Aharon Robbins]

[ 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 longer true. Ranges are now
implementation defined. This is what gives us the leeway to move to
range interpretation not based on locales.

Although in theory locales seem like a good idea, and having '[a-z]'
include all kinds of other characters between the ASCII 'a' and 'z'
sounds nice, well over 10 years of experience has shown me, at least,
that it only confuses users and leads to problems.

For example, in some vendor en_US.UTF-8 locales, the ordering is

AaBb ... YyZz

and in others it is:

aAbB ... yYzZ

So try and explain why '[a-z]' includes all of a...z but only A...Y
or B...Z !!!

In short, nothing but pain and confusion and endless bug reports.

By defining '[a-z]' as using the machine's character set, you
know what you're getting, and you are compatible with original
Unix practice. (You are in for slight confusion on an EBCDIC
machine, but that was always the case anyway, and that is several
orders of magnitude less of a problem than the mess created by locales.)

After moving gawk to historic range interpretation, the number
of bug reports related to this has dropped to close to zero.
I'm happier, and my users are happier.

I'd be thrilled if the GLIBC locale tables would be fixed. But
in the meantime, I have decided to leave this whole issue behind me.

I'll go crawl back under my rock now.

Arnold

Re: locale specific ordering in EN_US -- why is aAbByYzZ?

[Aharon Robbins]

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 wild.  Therefore there's no
other practical choice but to fix each program to provide Rational
Range Interpretation.

Fortunately, gawk and grep are already there, and I think the sed in
the git repo is as well.  Once Bash turns this on as default, the
world will definitely be a better place, independent of GLIBC.

Arnold

Re: locale specific ordering in EN_US -- why is aAbByYzZ?

[Aharon Robbins]

 Date: Thu, 27 Jun 2013 15:27:40 +0200
 From: Paolo Bonzini bonz...@gnu.org
 Subject: Re: locale specific ordering in EN_US -- why is aAbByYzZ?

 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
  of range expressions.  */
   regex_t re;
   char pattern[6] = { '[', 0, '-', 0, ']', 0 };
   char subject[2] = { 0, 0 };
   c1 = c;
   if (case_fold)
 {
   c1 = tolower (c1);
   c2 = tolower (c2);
 }

   pattern[1] = c1;
   pattern[3] = c2;
   regcomp (re, pattern, REG_NOSUB);
   for (c = 0; c  NOTCHAR; ++c)
 {
   if ((case_fold  isupper (c))
   || (MB_CUR_MAX  1  btowc (c) == WEOF))
 continue;
   subject[0] = c;
   if (regexec (re, subject, 0, NULL, 0) != REG_NOMATCH)
 setbit_case_fold_c (c, ccl);
 }
   regfree (re);
 #else
   c1 = c;
   if (case_fold)
 {
   c1 = tolower (c1);
   c2 = tolower (c2);
 }
   for (c = c1; c = c2; c++)
 setbit_case_fold_c (c, ccl);
 #endif

 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.

Arnold

Re: No such file or directory

[Aharon Robbins]

In article mailman.16481.1357062499.855.bug-b...@gnu.org,
Michael Williamson  michael.h.william...@gmail.com 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 for bash to provide a better error message
in this case?

Thanks,
-Mike

It's not Bash. That is the error returned from the OS in errno when
it tries to do an exec(2) of the file.  Bash merely translates the
error into words.

Depending on the distro, it's usually not too hard to install the 32 bit
compatibility files to support 32 bit executables.  The enterprise
distibutions tend to do that by default, whereas the more free ones
(Fedora, Ubuntu, ...) require that you do it yourself.

I agree, it's confusing.  But it's a decision made by the kernel guys,
not Bash.

HTH,

Arnold
-- 
Aharon (Arnold) Robbins arnold AT skeeve DOT com
P.O. Box 354Home Phone: +972  8 979-0381
Nof Ayalon  Cell Phone: +972 50 729-7545
D.N. Shimshon 99785 ISRAEL

Re: Any chance of multi-dimensional arrays?

[Aharon Robbins]

In article mailman.13825.1353909089.855.bug-b...@gnu.org,
Eduardo Bustamante  dual...@gmail.com 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.

Off topic, but current GNU Awk has true multidimensional arrays.

Arnold
-- 
Aharon (Arnold) Robbins arnold AT skeeve DOT com
P.O. Box 354Home Phone: +972  8 979-0381
Nof Ayalon  Cell Phone: +972 50 729-7545
D.N. Shimshon 99785 ISRAEL

Re: tab completion with variable expansion broken

[Aharon Robbins]

In article mailman.10999.1350260234.855.bug-b...@gnu.org,
Chet Ramey  chet.ra...@case.edu 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' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/src/gnu/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib 
-g -O2
 uname output: Linux jeanubu 3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26
21:32:50 UTC 2012 i686 athlon i386 GNU/Linux
 Machine Type: i686-pc-linux-gnu
 
 Bash Version: 4.2
 Patch Level: 37
 Release Status: release
 
 Description:
  If I have ul=/usr/local in the environment, I may want to
  use a reference to it together with tab completion to go to
  the directory /usr/local/share/emacs/site-lisp.

If you indeed are using bash-4.2.37, you can enable variable expansion
by running `shopt -s direxpand'.  This will produce the behavior you
want.

I'm wondering if you've got programmable completion enabled, or whether
you're running a different version of bash than bashbug indicates, because
stock 4.2.37 doesn't quote the dollar sign.

-- 
``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/


Is there something that can be done for 4.2.24 (/bin/bash on Ubuntu 12.04)?

Thanks,

Arnold
-- 
Aharon (Arnold) Robbins arnold AT skeeve DOT com
P.O. Box 354Home Phone: +972  8 979-0381
Nof Ayalon  Cell Phone: +972 50 729-7545
D.N. Shimshon 99785 ISRAEL

Re: square bracket vs. curly brace character ranges

[Aharon Robbins]

Hi Bob,

In article mailman.8995.1347754350.855.bug-b...@gnu.org,
Bob Proulx  b...@proulx.com 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 same issue?  I am
out of touch on the details of them these days.

The problem exists on other systems as well, such as Mac OS X and
Solaris, and I think also HP/UX.  Not sure about AIX.  It is definitely
not endemic to just GLIBC.

Not that fixing GLIBC wouldn't help, but it's not GLIBC-specific.

Getting bash, grep, sed and gawk fixed will go a long way though. :-)

Arnold
-- 
Aharon (Arnold) Robbins arnold AT skeeve DOT com
P.O. Box 354Home Phone: +972  8 979-0381
Nof Ayalon  Cell Phone: +972 50 729-7545
D.N. Shimshon 99785 ISRAEL

Re: square bracket vs. curly brace character ranges

[Aharon Robbins]

In article mailman.8905.1347655706.855.bug-b...@gnu.org,
Bob Proulx  b...@proulx.com 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
for bash.  I would like to see it addressed in libc so that it would
be uniform across all projects.  But that isn't likely to happen.  But
if libc isn't going to do it then it is beneficial if projects do it
themselves outside of libc.  Eventually in the future when libc
addresses the problem then those hacks can be removed.

Hi Bob.

You are ssuming here that everyone uses GLIBC.  Not so.  The projects
that are dong something about it* will have to maintain their own code anyway.
(More's the pity.)

Arnold

* I take credit here, having started it in gawk and pushed grep into it :-)
I think sed will eventually pick it up, and bash too. Karl Berry coined
the lovely phrase Rational Range Interpretation.  The campaign for Rational
Ragne Interpretation is in full swing! :-)
-- 
Aharon (Arnold) Robbins arnold AT skeeve DOT com
P.O. Box 354Home Phone: +972  8 979-0381
Nof Ayalon  Cell Phone: +972 50 729-7545
D.N. Shimshon 99785 ISRAEL

Re: locale specific ordering in EN_US -- why is aAbByYzZ?

[Aharon Robbins]

In article mailman.1485.1337627992.855.bug-b...@gnu.org,
Linda Walsh  b...@tlinx.org 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
 
 As you can see, the two en_US.iso88591 implementations are not the same.


   Great!...

So which is correct?

Both!  Isn't this fun!  Current POSIX leaves this up to the implementation.
I believe that the Debian order is what earlier POSIX required.

Anyone wanting to reference an upper or lower case range
[a-z] or [A-Z], is gonna hurt from this.

This is why I started the Campaign For Rational Range Interpretation,
now part of gawk and I believe in the most recent grep also, which
returns us to the sane days of yesteryear, where [a-z] got only lowercase
letters and [A-Z] got only uppercase ones.

My OS uses en_US.UTF-8.

I personally have had

export LC_ALL=C

in my .profile / .bashrc for many years now, to keep the behavior G-d
intended.

You'd think unicode would have something to say about collation
order that wouldn't allow such randomness, but maybe not.

It actually makes sense that it doesn't, since Unicode is more or less
a mapping of code points to glyphs, which is language independant. The
rules for collating depend upon the language.
-- 
Aharon (Arnold) Robbins arnold AT skeeve DOT com
P.O. Box 354Home Phone: +972  8 979-0381
Nof Ayalon  Cell Phone: +972 50 729-7545
D.N. Shimshon 99785 ISRAEL

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

[Aharon Robbins]

In article mailman.795.1333964833.20052.bug-b...@gnu.org,
Linda Walsh  b...@tlinx.org 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.

Actually it was a version of 'sh',

On many GNU/Linux systems, sh is a link to bash.

Might be a good reason to ditch bash and stick with something that supports a 
syntax that's been around for 20 years.

You might want to start at http://www2.research.att.com/~gsf/download/ to
get the current source code for ksh93.

 Like it costs how much?  I would **bet** that it cost more code to support
 (()) than to support [] as arith ops .. so if you want my opinion,
 lets toss (())...

As has been pointed out, for better or for worse, $((...)), is existing
practice (from ksh93) and is what is standardized by POSIX.  I suspect
that many people would agree with you w.r.t. aethestics, code maintainability,
and so on.

Unfortunately, in the case of the shell language, and many other nooks
and crannies of the Unix toolset, it's just plain too late to change.
(You might want to find a copy of the Unix version of the 'rc' shell,
which shows the results of one person's starting over from scratch.)

As has also been pointed out, although possibly not too recently in
this forum, membership in the POSIX working groups is open to anyone
who wishes to participate. It is a worthwhile experience (I was involved
in POSIX in the early 1990s), and *that* truly is the way to influence
the standards and the code that implements them.
-- 
Aharon (Arnold) Robbins arnold AT skeeve DOT com
P.O. Box 354Home Phone: +972  8 979-0381
Nof Ayalon  Cell Phone: +972 50 729-7545
D.N. Shimshon 99785 ISRAEL

Re: documentation bug re character range expressions

[Aharon Robbins]

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 make similar fixes to the
other prominent GNU utilities, since this has to be one of the most
Frequent of the FAQs.

Please pray for us!

Thanks,

Arnold

In article mailman.148.1307084802.836.bug-b...@gnu.org you write:
Is it really a programmer mistake, though, to assume that [A-Z] is only 
capital letters? A through Z are a contiguous range in every 
representation system except EBCDIC, and it is even contiguous the 
modern unicode.

In the world of programming characters are numbers, and programmers know 
this (especially if they've ever learned any C). For the example of 
[a-c], programmers are treating letters the way the machine treats them, 
as numbers.

How is the person typing [a-c] the one making the mistake when it 
results in matching against values outside of that range? To make it 
plainer, type it as [\0x61-\0x63] -- if you saw that in a program, you 
would expect that to cover 0x61, 0x62, 0x63, wouldn't you? If you were 
designing a programming language, wouldn't you make it do that?

If person A types [\0x61-\0x63] on software written by person B and it 
comes out matching 0x61, 0x41, 0x62, 0x42, 0x63, and perhaps something 
completely different when the same code is run on a computer in Russia, 
who would you say made the programming mistake? Surely not person A.

This is something that wasn't a bad programming habit until somewhere, 
someone made a decision that removed meaning from a sensible, 
logical-looking syntax.

Let's compare the syntaxes:

Under the old notation, there was:

- a succinct way to specify lowercase letters: [a-z]

- likewise for uppercase: [A-Z]

- likewise for case-insensitive: [A-Za-z]

- an easy way to specify ranges of letters of a particular case: [a-m], 
[A-M]

- case-insensitive ranges: [A-Ma-m]

Under the new notation, those things are written as:

- lowercase letters: [[:lower:]] (over twice as long to type)

- uppercase letters: [[:upper:]] (likewise)

- case-insensitive: [[:alpha:]] (not as bad, but still longer)

- how *are* you supposed to specify case-sensitive ranges? 
[abcdefghijklm] looks ridiculous.

- case-insensitive ranges: [a-M] (looks like an error at first glance: 
why is the M uppercase? you need to know something about the system 
internals to see why that's not wrong. And that something is a lot more 
complicated to explain than computers represent letters as numbers)


Bash is a shell. Shells should have a quick, brief, plain language so 
that one can get things done in them. Shells should also be quite 
portable: syntax that works on one system should work on any other as 
much as possible.

[[:alpha:]] is too difficult to type to make it useful for the kind of 
quick pattern-matching that character ranges are used for on the 
interactive shell. Try it. Open-bracket, colon is an awkward sequence 
compared to something like [a-z].

But usually one doesn't want all of the alphabet, nor case 
insensitivity. I have actually never had occasion to say [A-Za-z] on the 
command line, or even [A-Ca-c]. I have, however, very often wanted to 
grab everything with a lowercase 'a' through lowercase 'k', for instance.

Previously, that would have been [a-k]. Now I have no way to specify it 
except [abcdefghijk], and I'm not typing that. A useful feature is gone.

You say this is not only a bash problem because it's a programmer's 
mistake to assume that [a-c] means the same thing in bash as it does in 
Perl, Python, Java, C/C++ (POSIX regex.h, with system locale set!), 
JavaScript, PHP, sed, grep, and on and on -- you can see why one might 
make this mistake.

And these aren't historical examples, these are modern implementations 
of these languages that I just tested this on to double-check, on a 
system with its locale set to something that collates 
case-insensitively. Bash is the *only* thing I know of that treats 
character ranges this way, so I would say that does make it only a bash 
problem.

Even grep, whose man page says it obeys LC_COLLATE and the locale, 
actually has [a-c] equivalent to [abc] on all locales. Someone must have 
snuck in and fixed it. I'm guessing that if grep were to start using 
locale-aware character ranges, a heck of a lot more people would 
complain than do about bash. This is a seldom-used feature in bash but 
many, many people rely on grep being predictable and standard.

~Felix.


On 2011-06-02 22:32, Jan Schampera wrote:
 Hi,


 just as side note, not meant to touch the maintainer discussion.

 This is not only a Bash problem. The programmer/user mistake to use
 [A-Z] for only capital letters, capital A to capital Z is a very
 common one.

 But I'm not sure if every official application-level documentation
 should cover 

Re: Readline : move to previous/next path component

[Aharon Robbins]

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 skeeve DOT com
P.O. Box 354Home Phone: +972  8 979-0381
Nof Ayalon  Cell Phone: +972 50  729-7545
D.N. Shimshon 99785 ISRAEL

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

[Aharon Robbins]

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 have I wanted it to consider those ^P's and ^R's.

So even though you said that was a early design choice, perhaps you
could still leave (behind for posterity) a toggle variable or new
binding to do my dumber mode.

My http://www.useit.com/alertbox/ style survey of many years with
hundreds of hours with, er, 1 user, indicates, as they say in the
medical business, that this is needed.

Surely you (all) are not such constant hammerers of ESC . as I. Vote
for Choice.

Re: nocaseglob

[Aharon Robbins]

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 helpful.
 Down with system default locale.

Chet Ramey wrote:
You need to force the issue.  Add

export LC_COLLATE=C

to your startup files.

Chet

I prefer to use an even bigger hammer:

export LC_ALL=C

HTH,

Arnold
-- 
Aharon (Arnold) Robbins --- Pioneer Consulting Ltd. arnold AT skeeve DOT com
P.O. Box 354Home Phone: +972  8 979-0381Fax: +1 206 350 8765
Nof Ayalon  Cell Phone: +972 50  729-7545
D.N. Shimshon 99785 ISRAEL


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