Re: semicolon at beginning of line

[Elliott Forney]

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.

> 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