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 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 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 >> comm
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. > >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: 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 >> >> 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: 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 >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: 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 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: 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' -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: 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. 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: 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 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: 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 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 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
> 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: 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. > > You've also never tried understanding why you cannot "just do it" > without fixing glibc. Not true. I have tried. I have simply failed. You can try (again) using words of one syllable to explain it to me and maybe I'll get it. But don't feel like you have to, since I know you've not enjoyed the experience. Best wishes, Arnold
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 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: 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: > > >1) PATH is used by the kernel (exec family) to determine how commands are > > > executed. The way PATH is used by the kernel is not likely to change. > > > Having the shell treat it differently would lead to confusion. > > > > Actually, PATH searching is implemented in the C library and always > > has been; there is only one real system call. The confusion likely arises > > from the traditional practice of documenting all the exec calls on the > > same manpage. > > Oh, really? That's very misleading and confusing. > > HP-UX 10.20 exec(2) says: > > The exec*() system calls, in all their forms, ... > > So that's a complete lie, I guess. A small fiction. The man pages were that way since at least V7, and probably further back. IIRC the BSD folks at 4.2 left execve in section 2 and moved the rest to section 3. It is certianly that way now on GNU/Linux systems. > (And they do appear to be defined in > /lib/libc.a if I'm reading the output of nm correctly.) All the system calls are in /lib/libc.a. They are implemented as regular C wrappers around a special function (usually) written in assembly that traps into the kernel passing the system call number and the parameters and returning the result code. On a Linux system see syscalls(2), syscall(2) and possibly _syscall(2) (the latter is marked obsolete). As Chet said, most people don't really need to know about this fiction. Thanks, Arnold
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_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: 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 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: 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 >> >> 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: 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 "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
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 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: 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 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: 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 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: 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. 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: 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 engine at all. I assume you mean "shell implementations". :-) Gawk's printf supports it, if that's of any use to anyone. Arnold -- Aharon (Arnold) Robbins arnold AT skeeve DOT com
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 cents, Arnold -- Aharon (Arnold) Robbins arnold AT skeeve DOT com
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)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
