Re: semicolon at beginning of line

[Clark Wang]

On Tue, Apr 10, 2012 at 16:38, Elliott Forney <elliott.forney@gmail.com>wrote:

> On Tue, Apr 10, 2012 at 1:22 AM, Maarten Billemont <lhunath@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
>
>