* wrong error msg @ 2017-03-02 2:20 Ray Andrews 2017-03-02 16:47 ` Bart Schaefer 0 siblings, 1 reply; 12+ messages in thread From: Ray Andrews @ 2017-03-02 2:20 UTC (permalink / raw) To: Zsh Users Probably not worth reporting but: echo "Restore \"${previous?\"? (y/n)" in a script reports: " unmatched " " whereas it should be an unmatched curly where the first question mark mistakenly is . Mind, it's quite something how the parser usually figures these things out, and sometimes it must be a judgment call trying to discern one's intentions. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: wrong error msg 2017-03-02 2:20 wrong error msg Ray Andrews @ 2017-03-02 16:47 ` Bart Schaefer 2017-03-02 20:32 ` Ray Andrews 2017-03-04 14:00 ` Martijn Dekker 0 siblings, 2 replies; 12+ messages in thread From: Bart Schaefer @ 2017-03-02 16:47 UTC (permalink / raw) To: Zsh Users On Mar 1, 6:20pm, Ray Andrews wrote: } Subject: wrong error msg } } Probably not worth reporting but: } } echo "Restore \"${previous?\"? (y/n)" } } in a script reports: " unmatched " " whereas it should be an unmatched } curly The error message is correct. Try it outside of a script and you can see what's happening: torch% echo "Restore \"${previous?\"? (y/n)" dquote braceparam dquote> Note it's still waiting for you to close the inner quote, the brace, and an outer quote. If end-of-file is received there, the first error (unwinding the stack right to left) is unmatched quote. It doesn't report the other two things that aren't matched. This is because for example echo "Outer quote ${var:="inner quote"} outer again" is valid syntax -- you can include nested double quotes inside ${...}. The result might be a "bad substitution" depending on what else is or isn't inside the braces but that doesn't affect parsing the quotes. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: wrong error msg 2017-03-02 16:47 ` Bart Schaefer @ 2017-03-02 20:32 ` Ray Andrews 2017-03-02 23:14 ` Bart Schaefer 2017-03-04 14:00 ` Martijn Dekker 1 sibling, 1 reply; 12+ messages in thread From: Ray Andrews @ 2017-03-02 20:32 UTC (permalink / raw) To: zsh-users On 02/03/17 08:47 AM, Bart Schaefer wrote: > torch% echo "Restore \"${previous?\"? (y/n)" > dquote braceparam dquote> Well shucks. I never understood those things, I always presumed it was some bizarre message, not a triple message. So bloody obvious now that I see it. But I don't see how the parser finds trouble with dquotes. Boiling it down: $ echo "${previous" dquote braceparam dquote> Are you saying that, working left to right, the parser sorta can't consider the dquote closed since it becomes 'distracted' by the unclosed brace? IOW, until the brace is closed it doesn't know that the second dquote is 'available' since it could be something that's ... echo "Outer quote ${var:="inner quote"} outer again" ... right, the dquote could be within braces so the parser doesn't know that it is free to close the outside quote and leaves the issue unresolved and then simply reports the unresoved issues. Thus the second dquote is actually seen as another error -- an unclosed quote within an unclosed brace within and unclosed quote, yes? Whereas a human would tend to parse it outside-in and thus match the dquotes first and then see the unmatched brace -- thus a single error. But an interpreted language probably doesn't have that liberty. I think I get it. But why is it 'worse' in a script? I'd expect more finality at EOF and thus, if anything, better messages. Anyway I think I can finally really use those error messages, that's huge, many thanks. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: wrong error msg 2017-03-02 20:32 ` Ray Andrews @ 2017-03-02 23:14 ` Bart Schaefer 2017-03-02 23:37 ` Ray Andrews 0 siblings, 1 reply; 12+ messages in thread From: Bart Schaefer @ 2017-03-02 23:14 UTC (permalink / raw) To: zsh-users On Mar 2, 12:32pm, Ray Andrews wrote: } } ... right, the dquote could be within braces so the parser doesn't know } that it is free to close the outside quote and leaves the issue } unresolved and then simply reports the unresoved issues. Thus the } second dquote is actually seen as another error -- an unclosed quote } within an unclosed brace within and unclosed quote, yes? Yes. } Whereas a human would tend to parse it outside-in and thus match the } dquotes first and then see the unmatched brace -- thus a single error. As usual, computers are much better at following what you did say than they are at following what you intended to say. } But why is it 'worse' in a script? It's not really 'worse' -- but in a script there's no opportunity to print the PS2 prompt and wait for you to figure out what you meant. It just goes on reading from the file until it manages to find a matching quote, and then goes on until it finds a matching brace, and so on, probably piling up mismatched elements until it reaches end of file and has to pick one of them to complain about. Note that *none* of this is actually an *error* until the point at which the input runs dry and there is still something left to close, or until all the pairs have been closed and the thing that remains doesn't make sense (e.g., "bad substitution"). ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: wrong error msg 2017-03-02 23:14 ` Bart Schaefer @ 2017-03-02 23:37 ` Ray Andrews 2017-03-03 16:21 ` Bart Schaefer 0 siblings, 1 reply; 12+ messages in thread From: Ray Andrews @ 2017-03-02 23:37 UTC (permalink / raw) To: zsh-users On 02/03/17 03:14 PM, Bart Schaefer wrote: > As usual, computers are much better at following what you did say than > they are at following what you intended to say. Although IIRC the most natural parsing system is the way we do it -- outside-in, as, I believe, C does it, but I think the point needs to be hammered in that that's not available to an interpreter. One of those deep breakages that ruin your life. > > } But why is it 'worse' in a script? > > It's not really 'worse' -- but in a script there's no opportunity to > print the PS2 prompt and wait for you to figure out what you meant. > It just goes on reading from the file until it manages to find a > matching quote, and then goes on until it finds a matching brace, > and so on, probably piling up mismatched elements until it reaches > end of file and has to pick one of them to complain about. I see, so rather than collect a cascade of errors, since it can't show the prompt it doesn't even try. Well .... it could try couldn't it? I can see that it might have to abort that tho. I'd have found my error faster if the command line style message had been shown. And in the case of unclosings of every kind, isn't it a fairly simple list? > > Note that *none* of this is actually an *error* until the point at > which the input runs dry and there is still something left to close, > or until all the pairs have been closed and the thing that remains > doesn't make sense (e.g., "bad substitution"). > Absolutely. Although surely there are constructions that can't go on for ever? Or are there? My editor has nice syntax highlighting, and if you erase a closing quote, the entire rest of the file turns green (for quoted text) so there's no limit to that, at least. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: wrong error msg 2017-03-02 23:37 ` Ray Andrews @ 2017-03-03 16:21 ` Bart Schaefer 2017-03-03 17:07 ` Ray Andrews 0 siblings, 1 reply; 12+ messages in thread From: Bart Schaefer @ 2017-03-03 16:21 UTC (permalink / raw) To: zsh-users On Mar 2, 3:37pm, Ray Andrews wrote: } } Although IIRC the most natural parsing system is the way we do it -- } outside-in, as, I believe, C does it, but I think the point needs to be } hammered in that that's not available to an interpreter. One of those } deep breakages that ruin your life. Well, no, that's not really it. The trouble here is that your "natural" parse is wrong, and the difficulty arises from starting and ending the matched pair with visually-indistinguishable tokens. If we replace the quote marks with square brackets for readability -- The actual meaning: echo [Restore \"${previous?\"? (y/n)[ Your "natural" parse: echo [Restore \"${previous?\"? (y/n)] Whether the parse is left-to-right or outside-in doesn't matter. C does not allow nesting of visually-indistinguishable tokens, so this can't arise there. } I see, so rather than collect a cascade of errors, since it can't show } the prompt it doesn't even try. Well .... it could try couldn't it? The "unmatched" message is coming from the lexer; the PS2 prompt comes from the interactive input loop after the lexer stops. There isn't any "cascade of errors", there's only incomplete parser state, which in a script is not really available at that point (due to differences in the way input is processed for interactive vs. a file). Hmm, you could force interactive mode to syntax-check your script like this: zsh -o interactivecomments +o banghist -fnis < scriptfile % dquote braceparam dquote> zsh: unmatched " % % but you'll get a LOT of output. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: wrong error msg 2017-03-03 16:21 ` Bart Schaefer @ 2017-03-03 17:07 ` Ray Andrews 0 siblings, 0 replies; 12+ messages in thread From: Ray Andrews @ 2017-03-03 17:07 UTC (permalink / raw) To: zsh-users On 03/03/17 08:21 AM, Bart Schaefer wrote: It gets to be a rather deep subject Sensei, probably not right for the list, but my interest in the subject is profound, tho I come at it from the study of language in general not programming languages per se. > Well, no, that's not really it. The trouble here is that your "natural" > parse is wrong, I'd say that 'natural' is whatever folks would be expected to do, and I'd assert that 'my way' is what most folks would do and that any consistent rule could be used, so nothing is 'wrong' a priori, tho of course it might not be the rule actually used! (Unless of course my 'natural' parse cannot ever be consistent!) > C does not allow nesting of visually-indistinguishable tokens, so this > can't arise there. That's an excellent point. Indeed we use quotes with the same presumed syntactic effect as {}[]() even tho, as you say, they are not visually different. So whereas *we* know what we mean, the parser has no ability to mind-read. Which makes nesting of quote marks necessarily illegal. It's merely theoretical at this point, perhaps that does defeat my view of this. Anyway, I understand what zsh is doing now which is what is relevant here. > Hmm, you could force interactive mode to syntax-check your script like > this: > > zsh -o interactivecomments +o banghist -fnis < scriptfile > % dquote braceparam dquote> zsh: unmatched " > % % > > but you'll get a LOT of output. Deep magic. Too deep for an innocent like me. > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: wrong error msg 2017-03-02 16:47 ` Bart Schaefer 2017-03-02 20:32 ` Ray Andrews @ 2017-03-04 14:00 ` Martijn Dekker 2017-03-04 15:33 ` Ray Andrews 2017-03-04 18:31 ` Bart Schaefer 1 sibling, 2 replies; 12+ messages in thread From: Martijn Dekker @ 2017-03-04 14:00 UTC (permalink / raw) To: Bart Schaefer, zsh-users Op 02-03-17 om 16:47 schreef Bart Schaefer: > On Mar 1, 6:20pm, Ray Andrews wrote: > } Subject: wrong error msg > } > } Probably not worth reporting but: > } > } echo "Restore \"${previous?\"? (y/n)" > } > } in a script reports: " unmatched " " whereas it should be an unmatched > } curly > > The error message is correct. Try it outside of a script and you can > see what's happening: > > torch% echo "Restore \"${previous?\"? (y/n)" > dquote braceparam dquote> > > Note it's still waiting for you to close the inner quote, the brace, > and an outer quote. If end-of-file is received there, the first > error (unwinding the stack right to left) is unmatched quote. It > doesn't report the other two things that aren't matched. Perhaps it would be a useful feature to report the other two things, too. yash does exactly that: $ yash -c 'echo "Restore \"${previous?\"? (y/n)"' yash -c:1: syntax error: the double quotation is not closed yash -c:1: syntax error: `}' is missing yash -c:1: syntax error: the double quotation is not closed Would this be difficult to implement in zsh? - M. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: wrong error msg 2017-03-04 14:00 ` Martijn Dekker @ 2017-03-04 15:33 ` Ray Andrews 2017-03-04 18:31 ` Bart Schaefer 1 sibling, 0 replies; 12+ messages in thread From: Ray Andrews @ 2017-03-04 15:33 UTC (permalink / raw) To: zsh-users On 04/03/17 06:00 AM, Martijn Dekker wrote: > > yash does exactly that: > > $ yash -c 'echo "Restore \"${previous?\"? (y/n)"' > yash -c:1: syntax error: the double quotation is not closed > yash -c:1: syntax error: `}' is missing > yash -c:1: syntax error: the double quotation is not closed That is the lap of luxury. From one's first day with yash, one would know exactly what is wrong. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: wrong error msg 2017-03-04 14:00 ` Martijn Dekker 2017-03-04 15:33 ` Ray Andrews @ 2017-03-04 18:31 ` Bart Schaefer 2017-03-04 19:31 ` Ray Andrews 1 sibling, 1 reply; 12+ messages in thread From: Bart Schaefer @ 2017-03-04 18:31 UTC (permalink / raw) To: zsh-users On Mar 4, 2:00pm, Martijn Dekker wrote: } } $ yash -c 'echo "Restore \"${previous?\"? (y/n)"' } yash -c:1: syntax error: the double quotation is not closed } yash -c:1: syntax error: `}' is missing } yash -c:1: syntax error: the double quotation is not closed } } Would this be difficult to implement in zsh? It's messy. Zsh goes to some effort to *prevent* more than one error from being reported, i.e., the routines that actually output the error messages internally keep track of whether they've already been called and skip printing if called again. Anyway in zsh the unmatched quote is not the same one that yash is reporting, if I'm interpreting the call stack correctly. Zsh has hit the error while trying to close the very first opening quote, having already abandoned the input of the "${' and the second quote. So the error in zsh wouldn't change without completely rearranging the lexer/parser. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: wrong error msg 2017-03-04 18:31 ` Bart Schaefer @ 2017-03-04 19:31 ` Ray Andrews 2017-03-04 22:55 ` Bart Schaefer 0 siblings, 1 reply; 12+ messages in thread From: Ray Andrews @ 2017-03-04 19:31 UTC (permalink / raw) To: zsh-users On 04/03/17 10:31 AM, Bart Schaefer wrote: > } Would this be difficult to implement in zsh? > > It's messy. Zsh goes to some effort to *prevent* more than one error > from being reported, i.e., the routines that actually output the error > messages internally keep track of whether they've already been called > and skip printing if called again. Sounds like it could be an option to just let her rip. In my case, if I'd seen all three errors I'd have been able to figure out what was going on quite easily. And there would have been the implicit message to remember that parsing is left to right. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: wrong error msg 2017-03-04 19:31 ` Ray Andrews @ 2017-03-04 22:55 ` Bart Schaefer 0 siblings, 0 replies; 12+ messages in thread From: Bart Schaefer @ 2017-03-04 22:55 UTC (permalink / raw) To: zsh-users On Mar 4, 11:31am, Ray Andrews wrote: } } Sounds like it could be an option to just let her rip. Sigh. No. That would lead to the SAME error being reported multiple times, by various parts of the code, and in other situations unrelated to lexing/parsing (these error printing routines are used *everywhere*). I'm done with this thread. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-03-04 22:55 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-03-02 2:20 wrong error msg Ray Andrews 2017-03-02 16:47 ` Bart Schaefer 2017-03-02 20:32 ` Ray Andrews 2017-03-02 23:14 ` Bart Schaefer 2017-03-02 23:37 ` Ray Andrews 2017-03-03 16:21 ` Bart Schaefer 2017-03-03 17:07 ` Ray Andrews 2017-03-04 14:00 ` Martijn Dekker 2017-03-04 15:33 ` Ray Andrews 2017-03-04 18:31 ` Bart Schaefer 2017-03-04 19:31 ` Ray Andrews 2017-03-04 22:55 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).