Re: Bug in syntax checking causes unintended running of a function
On Tue, Apr 19, 2016 at 10:45 PM, David Maas 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.)
Re: [patch] /* XXX - possibly run Coproc->name through word expansion? */
On 4/19/16 11:03 AM, Piotr Grzybowski wrote: > > - if it expands to a legal identifier create the coproc > > This isn't necessary; there's no reason to restrict a coproc name to > something stricter than the set of valid executable names. I suppose > I could see restricting it to the same set of valid names as shell > functions. > > > ok, but I thought along these lines: if the name is not a valid > identifier, how are you going to refer by this name to the array with the > descriptors? but maybe checking legal_identifier is too much. That's a really good point. We can let people do unwise things (creating coprocs with weird names) and not let them pollute the shell's namespace at the same time. 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/
Re: Bug in syntax checking causes unintended running of a function
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 wrote: > On Tue, Apr 19, 2016 at 10:45 PM, David Maas 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.) >
Re: Bug in syntax checking causes unintended running of a function
Incidentally, is it possible that somehow )) is simply interpreted the same as } in this situation? It would also explain the perceived behavior. On Wed, Apr 20, 2016 at 12:55 AM, konsolebox wrote: > On Tue, Apr 19, 2016 at 10:45 PM, David Maas 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.) >
Re: Bug in syntax checking causes unintended running of a function
On Wed, Apr 20, 2016 at 08:30:48AM -0700, David Maas wrote:
> So if you really want my opinion, the shell should be aware that it's in a
> function.
Agreed, unless it's really hard to do.
> You could possibly implement this by keeping track of the parent
> pid.
Nonsense. Function calls do not create a child process. But the
issue here has nothing to do with function calls in the first place.
It's about parsing the script.
You wanted this:
a() {
an egregious syntax error
b
}
c
To be parsed like this:
c
But bash parsed it like this:
b
}
c
> Another solution would be to not check the syntax of the function
> until the function is actually run.
Then how do you know where the function definition ends? You have to
parse the function definition at the time you are reading that piece
of the script.
Could the parser's error handling be improved? Certainly. But I won't
be the one to write it, and I don't feel it's fair to demand that Chet
write it either. At some point, the script programmer has to take
responsibility for the script's errors.
Re: Bug in syntax checking causes unintended running of a function
Fair enough.
On Wed, Apr 20, 2016 at 8:44 AM, Greg Wooledge wrote:
> On Wed, Apr 20, 2016 at 08:30:48AM -0700, David Maas wrote:
> > So if you really want my opinion, the shell should be aware that it's in
> a
> > function.
>
> Agreed, unless it's really hard to do.
>
> > You could possibly implement this by keeping track of the parent
> > pid.
>
> Nonsense. Function calls do not create a child process. But the
> issue here has nothing to do with function calls in the first place.
> It's about parsing the script.
>
> You wanted this:
>
> a() {
> an egregious syntax error
> b
> }
>
> c
>
> To be parsed like this:
>
> c
>
> But bash parsed it like this:
>
> b
> }
> c
>
> > Another solution would be to not check the syntax of the function
> > until the function is actually run.
>
> Then how do you know where the function definition ends? You have to
> parse the function definition at the time you are reading that piece
> of the script.
>
> Could the parser's error handling be improved? Certainly. But I won't
> be the one to write it, and I don't feel it's fair to demand that Chet
> write it either. At some point, the script programmer has to take
> responsibility for the script's errors.
>
Re: Bug in syntax checking causes unintended running of a function
On 4/20/16 8:33 AM, David Maas wrote: > Incidentally, is it possible that somehow )) is simply interpreted the same > as } in this situation? It would also explain the perceived behavior. No. The parser resynchronizes at newline when performing error recovery. -- ``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/
