Re: Bug in syntax checking causes unintended running of a function

[David Maas]

So if you really want my opinion, the shell should be aware that it's in a function. You could possibly implement this by keeping track of the parent pid. Another solution would be to not check the syntax of the function until the function is actually run. I wouldn't do strict posix soley because that's what PHP does and doing that makes php programs stop on errors that really should be recoverable. Thats not the most wonderful reason however. Regarding comments that it's not a function, of course it's a function! It says function at the beginning. Nagging implementation problems do not make it not a function.

The argument that syntax errors should actually be checked beforehand is a good one, however that's not how bash is currently implemented in non-posix mode. This is definetely a bug, because:

- The script errors out about a syntactically valid ending }
- The script is confused about what is and isn't a function

- This issue can lead to programmer unanticipated behavior.

I really feel that programming languages shouldn't have "gotchas" - things that work contrary to the way you would expect something universal (like a function with a scope) to work. Anyway if you guys don't want to fix it, I doubt that many people would notice, but it is definitely a bug!

Thank you for discussing it,

David

On Wed, Apr 20, 2016 at 12:55 AM, konsolebox <konsolebox@gmail.com> wrote:

On Tue, Apr 19, 2016 at 10:45 PM, David Maas <david.maas@gmail.com> wrote:
> Running the echo and other contents of the function really doesn't seem like
> the correct behavior. If the function isn't called, then its contents
> shouldn't be executed.

Choose: Should the shell stop execution or not?  Can you give a theory how a
shell can make sure that an ending brace is the real ending brace of a function
when a syntax error happens?  (In all possible cases.)

> Hypothetically, what if the author was partway through writing a backup
> script that removes backed up data? The behavior of bash in this instance
> could cause a serious problem.

That's bad scripting practice IMO.  You don't test script you just wrote with
real data.  Syntax errors only happen once, unless you don't fix them right
away, or if you don't know how to use `eval` when you _have_ to use it.
(Please avoid quoting this obvious thing about `eval` again.)