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' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib
-g -O2 -Wall
uname output: Linux Xubuntu 2.6.31-22-generic #73-Ubuntu SMP Fri Feb 11
17:36:01 UTC 2011 i686 GNU/Linux
Machine Type: i486-pc-linux-gnu
Bash Version: 4.0
Patch Level: 33
Release Status: release
Description:
The case modification won't work with pattern.
I have a simple script a.sh, please see below:
#! /bin/bash
var=abcabc
echo var: ${var}
echo replace the leading \ab\ to uppercase: ${var^ab} # expect
to get ABcabc ?
echo replace all the \ab\ to uppercase: ${var^^ab}# expect
to get ABcABc ?
Case modification does not work the way you expected. It operates on single
chars other than strings.
echo replace the first \a\ to uppercase: ${var^a}
echo replace all \a\ to uppercase: ${var^^a}
Then the result is:
mylogin@Xubuntu:~/shell$ ./a.sh
var: abcabc
replace the leading ab to uppercase: abcabc -- incorrect
replace all the ab to uppercase: abcabc -- incorrect
replace the first a to uppercase: Abcabc -- correct
replace all a to uppercase: AbcAbc-- correct
Repeat-By:
--
Jerry Wang jerry.j.w...@alcatel-lucent.com
--
Clark J. Wang
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' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib
-g -O2 -Wall
uname output: Linux Xubuntu 2.6.31-22-generic #73-Ubuntu SMP Fri Feb 11
17:36:01 UTC 2011 i686 GNU/Linux
Machine Type: i486-pc-linux-gnu
Bash Version: 4.0
Patch Level: 33
Release Status: release
Description:
The case modification won't work with pattern.
I have a simple script a.sh, please see below:
#! /bin/bash
var=abcabc
echo var: ${var}
echo replace the leading \ab\ to uppercase: ${var^ab} # expect
to get ABcabc ?
echo replace all the \ab\ to uppercase: ${var^^ab}# expect
to get ABcABc ?
echo replace the first \a\ to uppercase: ${var^a}
And here it actually replaces the *leading* `a' other than the *first* `a'.
echo replace all \a\ to uppercase: ${var^^a}
Then the result is:
mylogin@Xubuntu:~/shell$ ./a.sh
var: abcabc
replace the leading ab to uppercase: abcabc -- incorrect
replace all the ab to uppercase: abcabc -- incorrect
replace the first a to uppercase: Abcabc -- correct
replace all a to uppercase: AbcAbc-- correct
Repeat-By:
--
Jerry Wang jerry.j.w...@alcatel-lucent.com
--
Clark J. Wang
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't even have a [[ command. This is all bash.
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 character* of var to the *glob pattern* which
follows the ^. If the character matches the glob, it gets capitalized.
No single character is ever going to match the glob ab, because it's
two characters long.
The closest you're going to get is:
imadev:~$ var=abcabc; echo ${var^[ab]}
Abcabc
The leading a matches the glob [ab] and so it's capitalized.
A better description of ^ might be conditional capitalization. Its
purpose is to capitalize the first character of a string, or of each
string in an array, because people frequently want that.
imadev:~$ arr=(the quick brown fox); echo ${arr[@]^}
The Quick Brown Fox
Specifying a glob after the ^ lets you skip certain letters, if for some
reason you wanted to do that. I can't think of any real-life examples
where that would be desirable, at the moment.
echo replace all the \ab\ to uppercase: ${var^^ab}# expect to
get ABcABc ?
What ^^ does is compare *each* character of var, one by one, to the glob
pattern that follows the ^^. It doesn't operate on multi-character
substrings.
You can use ^^ to capitalize every a and every b in var, but you cannot
use it to capitalize only instances of ab without also capitalizing
a and b in isolation:
imadev:~$ var=abcacb; echo ${var^^[ab]}
ABcAcB
More often, it's used to capitalize every character in a string:
imadev:~$ arr=(the quick brown fox); echo ${arr[@]^^}
THE QUICK BROWN FOX
Prior to bash 4, the only way to do that was to call tr(1).
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 exceeded (error token is a) 1 POSIX doesn't even have a [[ command. This is all bash. Not really. There is substantial agreement among shells that implement arithmetic expansion. bash, ksh93, zsh, mksh (and other pdksh derivatives that implement `[[') all behave the same way. For the most part, it's the same way with `['; zsh is a notable exception there. 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/
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 cause the build to fail... it just generates invalid results. Sometimes (not often but sometimes) an innocuous clue with will buried deep within thousands (or tends of thousands) of lines of make all output. And by output, I mean STDERR. 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 highlight on...highlight off. Of course, that also implies that your writes to wherever STDERR eventually goes are atomic and won't be interspersed with output from STDOUT. I'll let someone more intimate with the particulars of stdio and tty drivers and line disciplines figure that bit out. This would be nice because it would allow one to quickly identify and isolate potentially detrimental error messages from mundane but profuse output that logs commands being invoked, etc. Does this seem doable? Thanks, -Philip
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 highlight on...highlight off. This doesn't strike me as remotely within the domain of responsibilities that should belong to bash, mainly because: 1. it has nothing to do with anything that shells normally do. 2. putting it in bash specifically, would rob other, non-bash related commands, the possibility of having such a feature. 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, inserting highlights around any data it copies from the STDERR pipe. -- Micah J. Cowan http://micah.cowan.name/
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 STDERR with highlight on...highlight off. That's very much outside the scope of bash. Bash just sets up FDs for stdout and stderr (if requested -- otherwise, it doesn't even have to do that much) and execs some other program. It's the other program that does the writing. And it's the terminal that gets the data, in your case. It can't be done at the terminal level either, because the terminal doesn't know whether the data it's getting went through the slot marked 1 or the slot marked 2 on the sender's side. It's just input. So, you'd need some sort of independent program to sit between the app you're running and the terminal. Note that a lot of people attempt to do this using things like: red=... normal=... exec 2 (while read -r; do echo $red$REPLY$normal; done) Which may be good enough in some cases, but certainly isn't a robust answer. (You can't get a robust solution using just a shell.)
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 highlight on...highlight off. Of course, that also implies that your writes to wherever STDERR eventually goes are atomic and won't be interspersed with output from STDOUT. I'll let someone more intimate with the particulars of stdio and tty drivers and line disciplines figure that bit out. This would be nice because it would allow one to quickly identify and isolate potentially detrimental error messages from mundane but profuse output that logs commands being invoked, etc. 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 specified on the command line), and managed input and output would be acceptable. There look to be a few packages out there that could be adapted for this. Even a pty sniffing program would do the trick. 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/
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\'=;|('
$'@ \t\n\'=;|('
bash-4.2#
And other bind command like bind set completion-ignore-case on can also
reproduce.
This has to do with whether or not you run this command before readline
initializes. It will be fixed in the next version of bash.
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/
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 STDERR with highlight on...highlight off. This doesn't strike me as remotely within the domain of responsibilities that should belong to bash, mainly because: 1. it has nothing to do with anything that shells normally do. 2. putting it in bash specifically, would rob other, non-bash related commands, the possibility of having such a feature. 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, inserting highlights around any data it copies from the STDERR pipe. You could, but that would entail modifying every Makefile (a couple of hundred), plus automake, etc. -Philip
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 output from STDERR with highlight on...highlight off. snip 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, inserting highlights around any data it copies from the STDERR pipe. The idea intrigued me somewhat, so I hacked up a Perl script that attempts to do this (no guarantees of error-free code). Find it at http://micah.cowan.name/hg/demarcate/raw-file/tip/demarcate Set it to executable, and then try it out like: mkfifo out mkfifo err ./demarcate some program out 2err -- HTH, Micah J. Cowan http://micah.cowan.name/
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 commands in a pseudo-tty and then bracketing the output from STDERR with highlight on...highlight off. This doesn't strike me as remotely within the domain of responsibilities that should belong to bash, mainly because: 1. it has nothing to do with anything that shells normally do. 2. putting it in bash specifically, would rob other, non-bash related commands, the possibility of having such a feature. 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, inserting highlights around any data it copies from the STDERR pipe. You could, but that would entail modifying every Makefile (a couple of hundred), plus automake, etc. Nonsense. Just use shell redirections over the full command you're running. -- Micah J. Cowan http://micah.cowan.name/
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, inserting highlights around any data it copies from the STDERR pipe. You could, but that would entail modifying every Makefile (a couple of hundred), plus automake, etc. Nonsense. Just use shell redirections over the full command you're running. Or just run automake/make via the program I talked about. -- ``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/
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 output from STDERR with highlight on...highlight off. Of course, that also implies that your writes to wherever STDERR eventually goes are atomic and won't be interspersed with output from STDOUT. I'll let someone more intimate with the particulars of stdio and tty drivers and line disciplines figure that bit out. This would be nice because it would allow one to quickly identify and isolate potentially detrimental error messages from mundane but profuse output that logs commands being invoked, etc. 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 specified on the command line), and managed input and output would be acceptable. There look to be a few packages out there that could be adapted for this. Even a pty sniffing program would do the trick. 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? -- Micah J. Cowan http://micah.cowan.name/
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 commands in a pseudo-tty and then bracketing the output from STDERR with highlight on...highlight off. snip 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, inserting highlights around any data it copies from the STDERR pipe. The idea intrigued me somewhat, so I hacked up a Perl script that attempts to do this (no guarantees of error-free code). Find it at http://micah.cowan.name/hg/demarcate/raw-file/tip/demarcate Set it to executable, and then try it out like: mkfifo out mkfifo err ./demarcate some program out 2err Note that you can also just do: exec out 2err instead of running a specific program under it; but note that 1. this works somewhat poorly if your prompt is colorized, or clears graphical attributes 2. your prompt will now be highlighted, since readline emits it to stderr. 3. bash can apparently do line-editing this way; ksh93 seems to have a problem doing so. Basically, I don't recommend this, but it can work for some needs. (Idea for improving this program: allow for giving a shell command as an argument, eliminating the need for silly named pipes; just have the script redirect the specified command through normal pipes.) -- Micah J. Cowan http://micah.cowan.name/
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 make where 'magicthing' is the wrapper program that sets up the FIFOs/whatever and then executes make (or whatever's in argv[]) in that environment.
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 in a pseudo-tty and then bracketing the output from STDERR with highlight on...highlight off. Of course, that also implies that your writes to wherever STDERR eventually goes are atomic and won't be interspersed with output from STDOUT. I'll let someone more intimate with the particulars of stdio and tty drivers and line disciplines figure that bit out. This would be nice because it would allow one to quickly identify and isolate potentially detrimental error messages from mundane but profuse output that logs commands being invoked, etc. 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 specified on the command line), and managed input and output would be acceptable. There look to be a few packages out there that could be adapted for this. Even a pty sniffing program would do the trick. 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? Obviously, you have to separate them. We're all saying the same thing: the key to making this work is a program that sits in front of make and manages its input and output. 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/
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 specified on the command line), and managed input and output would be acceptable. There look to be a few packages out there that could be adapted for this. Even a pty sniffing program would do the trick. 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? Obviously, you have to separate them. We're all saying the same thing: the key to making this work is a program that sits in front of make and manages its input and output. Sorry; I guess I misinterpreted you to be saying that somehow you accomplish the trick by using ptys, when I suppose you were just saying that this program could provide a pty so that bash is running in a proper terminal (My cheap FIFO hack avoids allocating ptys, which should be fine for running make through it, and in the case of FIFOs (but not a spawned shell-cmd idea) should even work with bash and exec out 2err; but of course won't work on anything that expects its output fds to be ttys, as well as the inputs.) -- Micah J. Cowan http://micah.cowan.name/
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 have the option of running commands in a pseudo-tty and then bracketing the output from STDERR with highlight on...highlight off. snip 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, inserting highlights around any data it copies from the STDERR pipe. The idea intrigued me somewhat, so I hacked up a Perl script that attempts to do this (no guarantees of error-free code). Find it at http://micah.cowan.name/hg/demarcate/raw-file/tip/demarcate Set it to executable, and then try it out like: mkfifo out mkfifo err ./demarcate some program out 2err Note that you can also just do: execout 2err instead of running a specific program under it; but note that 1. this works somewhat poorly if your prompt is colorized, or clears graphical attributes 2. your prompt will now be highlighted, since readline emits it to stderr. 3. bash can apparently do line-editing this way; ksh93 seems to have a problem doing so. Basically, I don't recommend this, but it can work for some needs. (Idea for improving this program: allow for giving a shell command as an argument, eliminating the need for silly named pipes; just have the script redirect the specified command through normal pipes.) 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. -Philip
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 forces a terminal. The script command might do; I'm sure there are others. Such programs are not usually part of a build process, though (that I can think of). Anyway, my implementation is more of a proof-of-concept than anything truly, generally useful. -- Micah J. Cowan http://micah.cowan.name/
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 short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
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 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 highlight on...highlight off. snip 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, inserting highlights around any data it copies from the STDERR pipe. The idea intrigued me somewhat, so I hacked up a Perl script that attempts to do this (no guarantees of error-free code). Find it at http://micah.cowan.name/hg/demarcate/raw-file/tip/demarcate Set it to executable, and then try it out like: mkfifo out mkfifo err ./demarcate some program out 2err Note that you can also just do: execout 2err instead of running a specific program under it; but note that 1. this works somewhat poorly if your prompt is colorized, or clears graphical attributes 2. your prompt will now be highlighted, since readline emits it to stderr. 3. bash can apparently do line-editing this way; ksh93 seems to have a problem doing so. Basically, I don't recommend this, but it can work for some needs. (Idea for improving this program: allow for giving a shell command as an argument, eliminating the need for silly named pipes; just have the script redirect the specified command through normal pipes.) 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. That's why I suggested adapting a pty program for this. 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/
Re: case modification won't work with pattern
On Thu, Mar 10, 2011 at 9:31 PM, Greg Wooledge wool...@eeg.ccf.org 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 terse, admittedly.
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.
What the ^ operator
does is compare the *first character* of var to the *glob pattern* which
follows the ^. If the character matches the glob, it gets capitalized.
No single character is ever going to match the glob ab, because it's
two characters long.
--
Clark J. Wang
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 perilous because cross-compilation often suffers regression. The problem is that a lot of the regressions don't cause the build to fail... it just generates invalid results. Sometimes (not often but sometimes) an innocuous clue with will buried deep within thousands (or tends of thousands) of lines of make all output. And by output, I mean STDERR. 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 highlight on...highlight off. I've ever seen some util like colorgcc. Is that what you want? Of course, that also implies that your writes to wherever STDERR eventually goes are atomic and won't be interspersed with output from STDOUT. I'll let someone more intimate with the particulars of stdio and tty drivers and line disciplines figure that bit out. This would be nice because it would allow one to quickly identify and isolate potentially detrimental error messages from mundane but profuse output that logs commands being invoked, etc. Does this seem doable? Thanks, -Philip -- Clark J. Wang
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 wool...@eeg.ccf.org 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 terse, admittedly.
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 requests were for a way to change the first letter or
every letter to uppercase or lowercase, like ksh typeset -l/-u, using
word expansion syntax (one request was for a new builtin command to
do it). That's what you get if you don't use the pattern part of the
expansion. I invented the pattern following the case specifier to allow
each character to be separately modified.
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/
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 wool...@eeg.ccf.org 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 terse, admittedly.
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 requests were for a way to change the first letter or
every letter to uppercase or lowercase, like ksh typeset -l/-u, using
word expansion syntax (one request was for a new builtin command to
do it). That's what you get if you don't use the pattern part of the
expansion. I invented the pattern following the case specifier to allow
each character to be separately modified.
I suggested using parameter expansion with patterns in
http://lists.gnu.org/archive/html/bug-bash/2006-02/msg00020.html:
$ foo=bar
$ echo ${foo^} ## Convert first character
Bar
$ echo ${foo^^} ## Convert all characters
BAR
$ echo ${foo^[a-m]} ## Convert first character that matches pattern
Bar
$ echo ${foo^^[a-m]} ## Convert all characters that match pattern
BAr
--
Chris F.A. Johnson, http://cfajohnson.com/
Author:
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Re: case modification won't work with pattern
On Fri, Mar 11, 2011 at 11:56 AM, Chris F.A. Johnson
ch...@cfajohnson.comwrote:
I suggested using parameter expansion with patterns in
http://lists.gnu.org/archive/html/bug-bash/2006-02/msg00020.html:
$ foo=bar
$ echo ${foo^} ## Convert first character
Bar
$ echo ${foo^^} ## Convert all characters
BAR
$ echo ${foo^[a-m]} ## Convert first character that matches pattern
Bar
$ echo ${foo^^[a-m]} ## Convert all characters that match pattern
BAr
This sounds more reasonable to me.
--
Chris F.A. Johnson, http://cfajohnson.com/
Author:
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
--
Clark J. Wang
Re: case modification won't work with pattern
On Fri, Mar 11, 2011 at 11:33 AM, Chet Ramey chet.ra...@case.edu 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 requests were for a way to change the first letter or every letter to uppercase or lowercase, like ksh typeset -l/-u, using word expansion syntax (one request was for a new builtin command to do it). That's what you get if you don't use the pattern part of the expansion. I invented the pattern following the case specifier to allow each character to be separately modified. One specific user's requirement is specific. I think the feature can be implemented in a more flexible way which can also meet user's requirement. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/ -- Clark J. Wang
[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/tct/tip) and Python has PEP (Python Enhancement Proposal: http://www.python.org/dev/peps/). -- Clark J. Wang
Re: [BUG] Bash not reacting to Ctrl-C
* Chet Ramey chet.ra...@case.edu 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 with this. Thanks! Mind attaching the final patch to this thread, so that people can try out and test the patch you mean? Thanks, Ingo
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 ]]; echo $? bash: [[: a: expression recursion level exceeded (error token is a) 1 POSIX doesn't even have a [[ command. This is all bash. Not really. There is substantial agreement among shells that implement arithmetic expansion. bash, ksh93, zsh, mksh (and other pdksh derivatives that implement `[[') all behave the same way. For the most part, it's the same way with `['; zsh is a notable exception there. Chet Personally, I would much rather see (( a )) fail if a doesn't contain a number rather than go search for a parameter named by its contents. If the parameter a contains a word that's not a number, I can't imagine any case where this would be an expected and wanted scenario, rather than a bug. If it were expected, the author would've used the indirection operator directly. Which leaves us with a bug, one that's often terribly hard to detect and diagnose. That's ignoring the fact that you're leaving the door wide open for user input to go and load any parameter it chooses in its stead. Really, whenever this happens, it's either breaking things in completely unexpected and often invisible ways or it's somebody exploiting your code to do something it wasn't supposed to or reveal something it doesn't want to show. Why would we want this feature?
