On 9/13/2018 1:21 PM, Chet Ramey wrote:
I'm sure you noticed that word_lineno isn't set for every compound command
and that it's limited.
Actually I didn't notice. Under what circumstances is it not set?
What is it's purpose if it's not to keep track of a stack of nested
conditio
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! Th
On 9/12/18 10:29 PM, L A Walsh wrote:
> I can't speak for formatting or base-specific function usage, but I don't
> think there was any of those.
>
> 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 i
On 9/12/2018 6:35 AM, Chet Ramey wrote:
On 9/12/18 5:17 AM, Manuel Reiter wrote:
Bash Version: 4.4
Patch Level: 12
Release Status: release
++ Description:
When an if statement is not terminated by a fi, bash's error message is
not helpful in locating the problem.
This is tough to
On 9/12/18 5:17 AM, Manuel Reiter wrote:
> Bash Version: 4.4
> Patch Level: 12
> Release Status: release
>
> ++ Description:
>
> When an if statement is not terminated by a fi, bash's error message is
> not helpful in locating the problem.
This is tough to do in a bison-generated parser. If som
++ Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPAC