[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