[petsc-dev] [petsc-users] make test failed
Satish Balay
balay at mcs.anl.gov
Tue Jun 19 23:51:19 CDT 2012
On Tue, 19 Jun 2012, Barry Smith wrote:
> > It appears that the extra '\r' char is causing bash to process strings
> > incorrectly.
> Yes, but exactly how? Run the winzip to get the extra \r in
> them.
BTW: unix2dos is equivalent to winzip wrt reproduction.
> Then start removing them as you run the script to determine
> exactly where the grief comes from. I do not think the extra \r are
> always harmful, just if they come up in the wrong place. If you
> determine this you can reformat the original code to not have the
> bad \r cause grief.
Assume the extra char is 'x' [instead of '\r'] for illustration.
i.e:
var='foo'\r
is represented as
var='foo'x
Note: the above is valid syntax [but 'var' will have extra stuff that
wasn't intended]
The primary issue is - if you have the following code [in dos formatted text]:
>>>
if [ 'a' == 'a']
then
echo "yes"
else
echo "no"
fi
<<<
It is interpreted as:
>>>
if [ 'a' == 'a']x
thenx
echo "yes"x
elsex
echo "no"x
fix
<<<
And you get the error "syntax error: unexpected end of file"
One way to workarround is to add 'var=foo' before '\r' and
get some valid bash syntax. i.e something like:
>>>
if [ 'a' == 'a'] then a='a'x
echo "yes"; a='a'x
else a='a'x
echo "no"; a='a'x
fi; a='a'x
<<<<
So the fixed mpiexec.uni looks something like:
>>>>>
$ cat mpiexec.uni
#!/bin/sh
if [ $1 != "-np" -a $1 != "-n" ]; then a=a
progname=$*; a=a
elif [ $2 = "1" ]; then a=a
shift ; shift; a=a
progname=$* ; a=a
else a=a
echo "Uniprocessor version of MPI can only use one processor"; a=a
exit 1; a=a
fi; a=a
a=a
# Execute the program
$progname;a=a
exit 0;a=a
<<<<<<<
There is an alternative of setting the following env before running
bash scripts in cygwin - but these commands appear to be cygwin/bash
specific [so cannot easily automate?]
>>>>>>>
export SHELLOPTS
set -o igncr
<now run the script>
<<<<<<<<
Satish
More information about the petsc-dev
mailing list