Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #14579 > unrolled thread
| Started by | Manuel Reiter <manuel.reiter@dwd.de> |
|---|---|
| First post | 2018-09-14 16:26 +0200 |
| Last post | 2018-09-14 16:26 +0200 |
| Articles | 1 — 1 participant |
Back to article view | Back to gnu.bash.bug
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: error message for missing fi is not helpful Manuel Reiter <manuel.reiter@dwd.de> - 2018-09-14 16:26 +0200
| From | Manuel Reiter <manuel.reiter@dwd.de> |
|---|---|
| Date | 2018-09-14 16:26 +0200 |
| Subject | Re: error message for missing fi is not helpful |
| Message-ID | <mailman.783.1536935190.1284.bug-bash@gnu.org> |
[Multipart message — attachments visible in raw view] — view raw
On 13.09.2018 04:29, L A Walsh wrote: > This isn't *exactly* what you wanted, but this gives the line number > of the last unmatched statement (but doesn't tell you what the statement > was). The diff was against bash-4.4.23 (4.4 base w/23 patches) Thank you for taking the time to look into this! There seems to be a problem with your code though: if word_top is zero and EOF_Reached is true, you set msg to msg0 without initializing msg0 first. Reviving the code you commented out (your first attempt?) I came to the attached result. I also added if/fi to the compound commands tracked by word_top. There are probably others that I have missed missed. > Anyway, if you store the word in a separate array where the line # > is stored, you _could_ list the matching word, but I suspect just the > line it started on would be enough for most users. I totally agree with that. Thanks and best regards, Manuel
Back to top | Article view | gnu.bash.bug
csiph-web