On Tue, Apr 10, 2012 at 16:38, Elliott Forney <elliott.for...@gmail.com>wrote:
> On Tue, Apr 10, 2012 at 1:22 AM, Maarten Billemont <lhun...@lyndir.com>
> wrote:
> > People should stop trying to execute code by parameter expansion, and
> specifically stop thinking that parameter-expanded words are evaluated as
> bash code.
>
> I still think the behavior is interesting. The statement may not be
> empty but nothing other than the expansion is executed.
>
> > OK, so you're saying, let's change bash so that an empty statement
> becomes a noop statement.
>
> Yes. It already is when a newline is received. Why not when an empty
> statement is terminated with a semicolon?
>
> >Except for when that empty statement is preceded by a semicolon and
> happens to have no whitespace, because then it could be a case delimiter.
>
> Yes. Just like "$(" differs from "$((" and "[" from "[[" and ">" from
> ">>". This would not be unique syntax in bash.
>
> > Frankly, what are you hoping to gain from this?
>
> I simply believe it is intuitive; this is the behavior I would expect
> before trying it.
>
+1
>
> > This will just introduce new rules with new exceptions and
> inconsistencies. If it were possible to do a blanket rule: empty
> statements before a semicolon are noops, I might be OK with it, but if it
> requires adding additional addendums to the rule, "oh wait, except for this
> and that case", my vote is out.
>
> I really don't think it would cause lots of problems. This belief is
> supported by the fact that this is already implemented in other
> shells. Try the examples I have given in zsh and you will see the
> behavior I would expect. Try it in ksh and you will see something
> closer to the blanket rule you suggest.
>
> If no one else agrees then that's cool but my vote is to change it.
>
> Thanks,
> Elliott Forney
>
>
