error message for missing fi is not helpful
++ 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' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/bash-7fckc0/bash-4.4=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -no-pie -Wno-parentheses -Wno-format-security uname output: Linux eeyore 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3 (2017-12-03) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu 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 was mentioned in http://lists.gnu.org/archive/html/bug-bash/2008-06/msg00105.html but never replied to. I don't know whether bash allows an if statement to be terminated by EOF (as it does for a here document which was the original subject of the cited post) but even if it does, a warning message might be helpful. This applies to case not being terminated by esac (and possibly other commands) as well. ++ Repeat-By: + run the following script in bash: --snip #!/bin/bash if true then exit 0 # fi missing exit 1 -- snip + expected output: ./test.bash: line 2: syntax error: if without corresponding fi or at least ./test.bash: line 2: warning: if without corresponding fi + actual output: ./test.bash: line 8: syntax error: unexpected end of file
[PATCH] decode_signal: allow all sane forms of SIGRTMIN+n
I have a program I'd like to send SIGRTMIN+20, because that's the
spelling used in its documentation. Currently, bash only accepts the
symbolic names in the signal_names array, meaning I'd have to spell it
SIGRTMAX-10 on linux.
One workaround is of course to use
kill -n $(($(kill -l SIGRTMIN) + 20)) pid
but it's more user-friendly to allow the form
kill -s SIGRTMIN+20 pid
For symmetry, also accept SIGRTMAX-n expressions.
Signed-off-by: Rasmus Villemoes
---
trap.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/trap.c b/trap.c
index eb8ecf3a..dd80c220 100644
--- a/trap.c
+++ b/trap.c
@@ -242,6 +242,21 @@ decode_signal (string, flags)
if (legal_number (string, &sig))
return ((sig >= 0 && sig < NSIG) ? (int)sig : NO_SIG);
+#if defined(SIGRTMIN) && defined(SIGRTMAX)
+ if (STREQN (string, "SIGRTMIN+", 9)) {
+if (legal_number (string + 9, &sig) && sig >= 0 && sig <= SIGRTMAX -
SIGRTMIN)
+ return SIGRTMIN + sig;
+else
+ return NO_SIG;
+ }
+ if (STREQN (string, "SIGRTMAX-", 9)) {
+if (legal_number (string + 9, &sig) && sig >= 0 && sig <= SIGRTMAX -
SIGRTMIN)
+ return SIGRTMAX - sig;
+else
+ return NO_SIG;
+ }
+#endif
+
/* A leading `SIG' may be omitted. */
for (sig = 0; sig < BASH_NSIG; sig++)
{
--
2.16.4
Re: error message for missing fi is not helpful
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 someone would like to build the structures required to keep track of which conditional command the shell is currently parsing, and incorporate that into an error message, I'd be happy to look at it. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: error message for missing fi is not helpful
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 do in a bison-generated parser. If someone would like to
build the structures required to keep track of which conditional command
the shell is currently parsing, and incorporate that into an error
message, I'd be happy to look at it.
Chet
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)
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 it started on would be enough for most users.
--- (eoftest.sh)
#!/bin/bash
if ((1)); then
for i in 1 2 3; do
echo wow
---
./bash eoftest.sh
eoftest.sh: line 10: syntax error: unexpected end of file from line 4.
The wording was just what I threw in. I don't _need_ attribution for
this if that makes it easier.
--- parse.y.orig 2016-09-11 08:31:46.0 -0700
+++ parse.y 2018-09-12 19:14:45.542809731 -0700
@@ -6020,9 +6020,21 @@
print_offending_line ();
}
else
-{
- msg = EOF_Reached ? _("syntax error: unexpected end of file") : _("syntax error");
+{
+ char * msg0;
+ if (EOF_Reached && word_top>=0) {
+msg0 = (char *) xmalloc(128*sizeof(char));
+sprintf(msg0, "syntax error: unexpected end of file from line %d.", word_lineno[word_top]);
+ }
+
+ /* if (word_top>=0) {
+ msg = EOF_Reached ? _("syntax error: unexpected end of file from line %d."), word_lineno[word_top] : _("syntax error");
+ } else {
+ msg = EOF_Reached ? _("syntax error: unexpected end of file") : _("syntax error");
+ }*/
+ msg = EOF_Reached ? _(msg0) : _("syntax error");
parser_error (line_number, "%s", msg);
+ xfree(msg0);
/* When the shell is interactive, this file uses EOF_Reached
only for error reporting. Other mechanisms are used to
decide whether or not to exit. */
