Re: Regular expression match operation with character classes fails in bash 3.2
John E. Wulff wrote: I have just updated from openSUSE 10.2 to openSUSE 11.0 Linux. My backup shell script is now broken. I tracked the problen down to the latest version of bash. The relatively new binary operator =~ does not match a regular expression which contains a character class in square brackets: eg. $xp =~ [0-9]10 The behaviour is the same on a 32 bit machine with openSUSE 11.0 and GNU bash, version 3.2.39(1)-release (i586-suse-linux-gnu) All three script lines below match correctly on SuSE Linux 9.3 with GNU bash, version 3.00.16(1)-release (i586-suse-linux) Unfortunately I no longer have access to the bash version which worked correctly with openSUSE 10.2 My observation is the fault was introduced fairly recently. Repeat-By: The following very simple regular expression matches: xp=310; if [[ $xp =~ 310 ]]; then echo $xp matched; else echo $xp not matched; fi This does not match in Bash Version 3.2 xp=310; if [[ $xp =~ [0-9]10 ]]; then echo $xp matched; else echo $xp not matched; fi This does not match either (more like the line in my broken shell script) xp=310; if [[ $xp =~ [0-9][0-9]* ]]; then echo $xp matched; else echo $xp not matched; fi That has been discussed some days ago, it's the expected behavior. See http://lists.gnu.org/archive/html/bug-bash/2008-06/msg00083.html -- D.
Bash error message for unterminated heredoc is unhelpful.
Dear All,
In some cases, bash gives exceptionally unhelpful error messages, of the
sort Unexpected end of file. This is next-to-useless as a debugging
aid, since there is no way to find out where the error really lies.
I'm using bash version: bash-3.2-7mdv2008.1
Here are 2 shell scripts with examples.
bug-example.sh demonstrates the problem.
bug-example2.sh is where bash gets it right.
Thanks very much,
Richard
[EMAIL PROTECTED] ~]$ cat bug-example.sh
-
#!/bin/bash
#This is an example of bash being unhelpful with syntax errors.
function usage () {
cat -EOT
This help text is a heredoc
EOT
#NOTE that the line above contains a trailing TAB, and
# is therefore NOT valid as the end of the heredoc.
}
usage
echo A long script goes here...
echo Many lines later...
exit 0
#This script generates the following error:
# ./bug-example.sh: line 37: syntax error: unexpected end of file
#That is really not helpful, since there's no way to track down where
#the error started. Line 37 is not interesting. What we need is a
#warning about line 6.
#At a minimum, we should get this error message:
# ./bug-example.sh: line 37: syntax error: unexpected end of file
# (started at line 6)
#Better, would be this error message:
# ./bug-example.sh: line 6: syntax error: unterminated heredoc.
#An additional buglet is that in fact, trailing whitespace after
#a heredoc terminator should probably be ignored anyway?
-
[EMAIL PROTECTED] ~]$ cat bug-example2.sh
-
#!/bin/bash
#This is an example of bash being *helpful* with syntax errors.
X=$((1 + 2) #NOTE missing trailing ).
echo X is $X #Should print 'X is 3'
echo A long script goes here...
echo Many lines later...
exit 0
#This script gets it right with the error message.
# ./bug-example2.sh: line 5: unexpected EOF while looking for
# matching `)'
# ./bug-example2.sh: line 20: syntax error: unexpected end of file
#So, we can quickly find the bug.
-
Re: Bash error message for unterminated heredoc is unhelpful.
Richard Neill wrote: Dear All, In some cases, bash gives exceptionally unhelpful error messages, of the sort Unexpected end of file. This is next-to-useless as a debugging aid, since there is no way to find out where the error really lies. For better or worse, bash allows end-of-file to delimit a here document. That is historical sh behavior. The end-of-file syntax error message comes when the shell tries to read the token following the here document. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: Bash error message for unterminated heredoc is unhelpful.
Chet Ramey wrote:
Richard Neill wrote:
Dear All,
In some cases, bash gives exceptionally unhelpful error messages, of the
sort Unexpected end of file. This is next-to-useless as a debugging
aid, since there is no way to find out where the error really lies.
For better or worse, bash allows end-of-file to delimit a here document.
That is historical sh behavior.
The end-of-file syntax error message comes when the shell tries to read
the token following the here document.
Chet
Thanks for your reply.
Fair point. But nevertheless, couldn't bash still tell us why the EOF is
unexpected, and where the _start_ of the offending syntax lies?
That was the point of my second example: the error is still an
unexpected EOF, but in that case, bash also informs the user that the
missing ')' is due to a '(' which was on line 5.
Also, bash should tell us *why* the end-of-file is unexpected...
Incidentally, bash is similarly unhelpful in the case of an 'if'
statement which is missing its 'fi', or a case missing its esac.
If the script is a long one, there's no easy way to locate the offending
token, short of laboriously commenting out sections and doing the
divide-and-conquer method.
Regards,
Richard
