no apostrophe allowed in comment

When the comment is inside of a substituted process. #! /bin/bash -ex # tee >( # this is nifty echo hi there ) The above works. Whereas the below fails. #! /bin/bash -ex # tee >( # ain't this nifty echo hi there ) It burps thusly: ./foo.sh: line 7: bad substit

test -nt not sane

Or maybe I'm not groking. When one compares against a b0rk symlink, the result of -nt (newer than) is true--when it isn't! mkdir directory ln -s noexist symlink touch -hr directory symlink test directory -nt symlink &&echo yes ||echo no They have identical mtimes (as set by touch)--i.e

Re: process substitution in PROMPT_COMMAND

On Sun, 7 Aug 2011, Chet Ramey wrote: On 8/7/11 6:00 PM, Curtis Doty wrote: local job jobcount=0 while read job do ((jobcount++)) done < <(jobs) As you suspect, the problem is with this part of the function. It doesn't really have anything to do with PROMPT_COMMAND, t

process substitution in PROMPT_COMMAND

I've recently refactored my PROMPT_COMMAND function to avoid superfluous fork()s. In the body of the function, what was once this line: local jobcount=$(jobs |wc -l) is now this: local job jobcount=0 while read job do ((jobcount++)) done < <(jobs) This works fine on bash 4. However,

Re: read into array Segfaults

On Tue, 21 Jun 2011, Chet Ramey wrote: declare -A foo read -a foo << Yes. It certainly shouldn't crash the shell. Try the attached patch and let me know that it works for you. Thanks for the report. Yep, thanks. Verified no segfault; only the error. Tested on 4.0, 4.1, and 4.2 in F

read into array Segfaults

I did a stupid thing. Tried to read into an array--which is indexed--but the variable is already an associative array. declare -A foo read -a foo <

Re: exit status question

11:30am Eric Blake said: On 12/20/2010 11:25 AM, Curtis Doty wrote: Not exactly sure if this is a bug. But I don't understand why only the first time running ((i++)) returns an error exit status. Because it follows the same semantics as 'expr', where status 1 is reserved for a

exit status question

Not exactly sure if this is a bug. But I don't understand why only the first time running ((i++)) returns an error exit status. Here's my script: #! /bin/bash echo $BASH_VERSION ${BASH_VERSINFO[5]} set -x #set -e i=0 ((i++)) echo $? ((i++)) echo $? And here's what the output looks like: 4.1.7