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

[Mike Frysinger]

On 21 Mar 2015 20:19, Chet Ramey wrote:
> 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.

i love very detailed changelogs, but their up-front usefulness is curtailed 
when 
they can't be clearly attributed to file changes.  this is why the idiom of one 
logical change per git commit works out nicely -- when there's a problem, 
you've got specific commits & their reasons, and you can use git bisect to help 
automate tracking down regressions.
-mike


signature.asc
Description: Digital signature

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

[Chris F.A. Johnson]

On Sun, 22 Mar 2015, 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.

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))?


  Balance the parentheses:

echo $(case "yes" in (yes) echo yes; ;; (no) echo no; ;; esac)

--
Chris F.A. Johnson, 

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

[Jon Seymour]

Thanks for reply and the workaround.

jon.

On Sun, Mar 22, 2015 at 4:49 PM, Chris F.A. Johnson
 wrote:
> On Sun, 22 Mar 2015, 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.
>>
>> 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))?
>
>
>   Balance the parentheses:
>
>
> echo $(case "yes" in (yes) echo yes; ;; (no) echo no; ;; esac)
>
> --
> Chris F.A. Johnson, 

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

[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

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

[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: Experiment to provide a mirror of bash with detailed git history

[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

[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-