Re: Experiment to provide a mirror of bash with detailed git history

2015-03-21 Thread Chet Ramey
On 3/16/15 4:54 PM, Eduardo A. Bustamante López wrote:
 I know that some people are interested in a more detailed commit history in
 bash's git repository. After all, it's easier for all of us to just learn to
 use a tool, and use that for everything.
 
 The changelog files distributed with bash are useful, *but*, I claim that it'd
 be more useful to use the facilities that git provides for this. Because, it
 already has many useful things, like bisect, blame, log, and so on, that only
 work properly if you follow the good practice of making logical commits.

I'm interested in how well this turns out.  I'm also interested in how
useful you find the changelog entries, since I try to make them very
detailed.

-- 
``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: LS_COLORS with ln=target not working

2015-03-21 Thread Chet Ramey
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 3/20/15 4:47 PM, andr...@stapelspeicher.org wrote:
 When using ln=target in LS_COLORS and having colored-stats on, I 
 get targetm in front of every symlink when using tab-completion, as 
 well as indenting problems. The implementation in 
 lib/readline/colors.c just doesn't work.
 
 I appended a small patch that shows the relevant parts and works well
  for me.

Thanks for the report.  This 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/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlUN8hQACgkQu1hp8GTqdKsI/ACfaAOVkuCKoP/cushse2XGbNXc
Zs4An1Tu0gZGUfqWb+D4OvAA6NZhrvJH
=HKQD
-END PGP SIGNATURE-



Should nested case statements within command substitutions work on in bash 3.2.x?

2015-03-21 Thread Jon Seymour
I was surprised that this didn't work with the OSX version of bash 3.2:

 /bin/bash -c 'echo $(case yes in yes) echo yes; ;; no) echo no; ;; esac)'

/bin/bash: -c: line 0: syntax error near unexpected token `;;'
/bin/bash: -c: line 0: `echo $(case yes in yes) echo yes; ;; no)
echo no; ;; esac)'

It does work with bash 4.x.

Is this a known issue with 3.2 or is it particular to the OSX
implementation (which in my case is 3.2.53(1))?

jon.



Re: Should nested case statements within command substitutions work on in bash 3.2.x?

2015-03-21 Thread Bob Proulx
Jon Seymour wrote:
 I was surprised that this didn't work with the OSX version of bash 3.2:
 
  /bin/bash -c 'echo $(case yes in yes) echo yes; ;; no) echo no; ;; 
 esac)'
 
 /bin/bash: -c: line 0: syntax error near unexpected token `;;'
 /bin/bash: -c: line 0: `echo $(case yes in yes) echo yes; ;; no)
 echo no; ;; esac)'

 It does work with bash 4.x.

It was improved later.  But I see that zsh as of 5.0.7 still has the
same problem with that construct.

 Is this a known issue with 3.2 or is it particular to the OSX
 implementation (which in my case is 3.2.53(1))?

It is that way in 3.2 and not specific to your OS X implementation.

Of course you know that if you match the parens then it will parse
correctly.  Matching parens has been the standard way to handle this
case for all of the shells.

  $ bash -c 'echo $(case yes in (yes) echo yes ;; (no) echo no ;; esac)'
  yes

Bob