Re: case modification won't work with pattern

On Thu, Mar 10, 2011 at 10:22 AM, Jerry Wang < jerry.j.w...@alcatel-lucent.com> wrote: > Configuration Information [Automatically generated, do not change]: > Machine: i486 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' > -DCONF_OSTYPE='linux-gnu' -D

Re: case modification won't work with pattern

On Thu, Mar 10, 2011 at 10:22 AM, Jerry Wang < jerry.j.w...@alcatel-lucent.com> wrote: > Configuration Information [Automatically generated, do not change]: > Machine: i486 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' > -DCONF_OSTYPE='linux-gnu' -D

Re: variable name and its' value are the same characters causes recursion error

On Thu, Mar 10, 2011 at 10:18:26AM +0800, Clark J. Wang wrote: > Actually I don't like the recursion here. Does POSIX require that? > > > For example: > > > > unset a; declare a="a"; [[ a -lt 3 ]]; echo $? > > bash: [[: a: expression recursion level exceeded (error token is "a") > > 1 POSIX doesn

Enhancement - hostname in punycode format

Is there any interest to support hostnames in punycode format? I mean to display unicode resresentation rather than ascii (punycode). RR

Re: case modification won't work with pattern

On Thu, Mar 10, 2011 at 10:22:12AM +0800, Jerry Wang wrote: > var="abcabc" > echo "var: ${var}" > echo "replace the leading \"ab\" to uppercase: ${var^ab}" # expect to > get "ABcabc" ? The documentation is a bit terse, admittedly. What the ^ operator does is compare the *first

Re: variable name and its' value are the same characters causes recursion error

On 3/10/11 8:14 AM, Greg Wooledge wrote: > On Thu, Mar 10, 2011 at 10:18:26AM +0800, Clark J. Wang wrote: >> Actually I don't like the recursion here. Does POSIX require that? >> >>> For example: >>> >>> unset a; declare a="a"; [[ a -lt 3 ]]; echo $? >>> bash: [[: a: expression recursion level exce

Hightlighting in bash

Hi. First off, this isn't a bug report so much as a feature request. I do a lot of cross-compilation of linux and various packages for embedded distros. Version bumps are always perilous because cross-compilation often suffers regression. The problem is that a lot of the regressions don't ca

Re: Hightlighting in bash

(03/10/2011 11:42 AM), Philip Prindeville wrote: > My request is simple. Using termcap/ncurses info (which you need anyway > for the readline stuff), it would be nice to have the option of running > commands in a pseudo-tty and then bracketing the output from STDERR with > This doesn't strik

Re: Hightlighting in bash

On Thu, Mar 10, 2011 at 11:42:25AM -0800, Philip Prindeville wrote: > My request is simple. HAH! Lies > Using termcap/ncurses info (which you need anyway > for the readline stuff), it would be nice to have the option of running > commands in a pseudo-tty and then bracketing the output from

Re: Hightlighting in bash

On 3/10/11 2:42 PM, Philip Prindeville wrote: > My request is simple. Using termcap/ncurses info (which you need anyway > for the readline stuff), it would be nice to have the option of running > commands in a pseudo-tty and then bracketing the output from STDERR with > > > Of course, that

Re: Why escape char `:' with `\' when auto completing filenames?

On 2/20/11 10:11 PM, Clark J. Wang wrote: > I just tried with a very simple ~/.bashrc: > > COMP_WORDBREAKS=${COMP_WORDBREAKS//[:@]/} > printf '%q\n' "$COMP_WORDBREAKS" > > bind "set bell-style none" > printf '%q\n' "$COMP_WORDBREAKS" > > When bash starts, I can see: > > $' \t\n"\'><=;|&(' > $'

Re: Hightlighting in bash

On 3/10/11 11:53 AM, Micah Cowan wrote: (03/10/2011 11:42 AM), Philip Prindeville wrote: My request is simple. Using termcap/ncurses info (which you need anyway for the readline stuff), it would be nice to have the option of running commands in a pseudo-tty and then bracketing the output from S

IMPLEMENTATION [Re: Hightlighting in bash]

(03/10/2011 11:53 AM), Micah Cowan wrote: > (03/10/2011 11:42 AM), Philip Prindeville wrote: >> My request is simple. Using termcap/ncurses info (which you need anyway >> for the readline stuff), it would be nice to have the option of running >> commands in a pseudo-tty and then bracketing the out

Re: Hightlighting in bash

(03/10/2011 12:27 PM), Philip Prindeville wrote: > On 3/10/11 11:53 AM, Micah Cowan wrote: >> (03/10/2011 11:42 AM), Philip Prindeville wrote: >>> My request is simple. Using termcap/ncurses info (which you need anyway >>> for the readline stuff), it would be nice to have the option of running >>>

Re: Hightlighting in bash

On 3/10/11 3:28 PM, Micah Cowan wrote: >>> It wouldn't be difficult to write as a separate program, which is really >>> how this should be handled. You could redirect a pipeline's STDOUT and >>> STDERR to individual named pipes (FIFOs), and have a separate program >>> read from both pipes, inserti

Re: Hightlighting in bash

(03/10/2011 12:07 PM), Chet Ramey wrote: > On 3/10/11 2:42 PM, Philip Prindeville wrote: > >> My request is simple. Using termcap/ncurses info (which you need anyway >> for the readline stuff), it would be nice to have the option of running >> commands in a pseudo-tty and then bracketing the outp

Re: IMPLEMENTATION [Re: Hightlighting in bash]

(03/10/2011 12:28 PM), Micah Cowan wrote: > (03/10/2011 11:53 AM), Micah Cowan wrote: >> (03/10/2011 11:42 AM), Philip Prindeville wrote: >>> My request is simple. Using termcap/ncurses info (which you need anyway >>> for the readline stuff), it would be nice to have the option of running >>> comm

Re: Hightlighting in bash

On Thu, Mar 10, 2011 at 12:49:27PM -0800, Micah Cowan wrote: > When both stdout and stderr are the same tty, how do you expect to use > this method to detect which text should be hilighted and which shouldn't? Arrange so that's not the case. Most likely by running something like magicthing ma

Re: Hightlighting in bash

On 3/10/11 3:49 PM, Micah Cowan wrote: > (03/10/2011 12:07 PM), Chet Ramey wrote: >> On 3/10/11 2:42 PM, Philip Prindeville wrote: >> >>> My request is simple. Using termcap/ncurses info (which you need anyway >>> for the readline stuff), it would be nice to have the option of running >>> commands

Re: Hightlighting in bash

(03/10/2011 12:55 PM), Chet Ramey wrote: > On 3/10/11 3:49 PM, Micah Cowan wrote: >> (03/10/2011 12:07 PM), Chet Ramey wrote: >>> This doesn't seem like it has to be done in bash. A small program that >>> allocated and opened a pty, ran bash in the pty (or an arbitrary command >>> and arguments sp

Re: IMPLEMENTATION [Re: Hightlighting in bash]

On 3/10/11 12:50 PM, Micah Cowan wrote: (03/10/2011 12:28 PM), Micah Cowan wrote: (03/10/2011 11:53 AM), Micah Cowan wrote: (03/10/2011 11:42 AM), Philip Prindeville wrote: My request is simple. Using termcap/ncurses info (which you need anyway for the readline stuff), it would be nice to hav

Re: IMPLEMENTATION [Re: Hightlighting in bash]

(03/10/2011 02:03 PM), Philip Prindeville wrote: > A lot of programs don't behave properly (or perhaps, "don't behave the > same") when they detect that stdout isn't a terminal. But I think > someone else mentioned this already. Yeah. You could always run the program under another program that fo

Re: [BUG] Bash not reacting to Ctrl-C

> So the above trace is one that my patch would have handled correctly > (since it has no EINTR). Maybe a combination of the two approaches > would work even better? I installed what is essentially the union of your changes and mine. Thanks for everyone's help with this. Chet -- ``The lyf so s

Re: IMPLEMENTATION [Re: Hightlighting in bash]

On 3/10/11 5:03 PM, Philip Prindeville wrote: > On 3/10/11 12:50 PM, Micah Cowan wrote: >> (03/10/2011 12:28 PM), Micah Cowan wrote: >>> (03/10/2011 11:53 AM), Micah Cowan wrote: (03/10/2011 11:42 AM), Philip Prindeville wrote: > My request is simple. Using termcap/ncurses info (which you

Re: case modification won't work with pattern

On Thu, Mar 10, 2011 at 9:31 PM, Greg Wooledge wrote: > On Thu, Mar 10, 2011 at 10:22:12AM +0800, Jerry Wang wrote: > > var="abcabc" > > echo "var: ${var}" > > echo "replace the leading \"ab\" to uppercase: ${var^ab}" # expect > to get "ABcabc" ? > > The documentation is a bit t

Re: Hightlighting in bash

On Fri, Mar 11, 2011 at 3:42 AM, Philip Prindeville < philipp_s...@redfish-solutions.com> wrote: > Hi. > > First off, this isn't a bug report so much as a feature request. > > I do a lot of cross-compilation of linux and various packages for embedded > distros. > > Version bumps are always perilou

Re: case modification won't work with pattern

On 3/10/11 9:04 PM, Clark J. Wang wrote: > On Thu, Mar 10, 2011 at 9:31 PM, Greg Wooledge wrote: > >> On Thu, Mar 10, 2011 at 10:22:12AM +0800, Jerry Wang wrote: >>> var="abcabc" >>> echo "var: ${var}" >>> echo "replace the leading \"ab\" to uppercase: ${var^ab}" # expect >> to

Re: case modification won't work with pattern

On Thu, 10 Mar 2011, Chet Ramey wrote: On 3/10/11 9:04 PM, Clark J. Wang wrote: On Thu, Mar 10, 2011 at 9:31 PM, Greg Wooledge wrote: On Thu, Mar 10, 2011 at 10:22:12AM +0800, Jerry Wang wrote: var="abcabc" echo "var: ${var}" echo "replace the leading \"ab\" to uppercase:

Re: case modification won't work with pattern

On Fri, Mar 11, 2011 at 11:56 AM, Chris F.A. Johnson wrote: > > I suggested using parameter expansion with patterns in > : > > $ foo=bar > $ echo ${foo^} ## Convert first character > Bar > $ echo ${foo^^} ## Convert all characte

Re: case modification won't work with pattern

On Fri, Mar 11, 2011 at 11:33 AM, Chet Ramey wrote: > On 3/10/11 9:04 PM, Clark J. Wang wrote: > > > > Agree. Almost all of the poeple around me don't understand why it works > that > > way. Maybe some background of the feature requirement can help us to > > understand better. > > The original re

[suggestion] Also document users' requirements for new features

When new features are added to bash I suggest some background info about the feature requirements be also included in the bash doc (like NEWS or ChangeLog). This will help people to understand the feature well. Other languages like Tcl has TIP (Tcl Improvement Proposal: http://www.tcl.tk/cgi-bin/t

Re: [BUG] Bash not reacting to Ctrl-C

* Chet Ramey wrote: > > So the above trace is one that my patch would have handled correctly > > (since it has no EINTR). Maybe a combination of the two approaches > > would work even better? > > I installed what is essentially the union of your changes and mine. Thanks > for everyone's help w

Re: variable name and its' value are the same characters causes recursion error

On 10 Mar 2011, at 15:23, Chet Ramey wrote: > > On 3/10/11 8:14 AM, Greg Wooledge wrote: >> On Thu, Mar 10, 2011 at 10:18:26AM +0800, Clark J. Wang wrote: >>> Actually I don't like the recursion here. Does POSIX require that? >>> For example: unset a; declare a="a"; [[ a -lt 3 ]];