#1047 sh: -c: line errors

[Joshua Nekl]

As reported by other people, I see several instances of the following error.

sh: -c: line 0: unexpected EOF while looking for matching ``'
sh: -c: line 1: syntax error: unexpected end of file

This is caused by the command
ierr=256 in command='find /usr/local /bin /sbin /usr/bin /usr/sbin /opt/bin /opt/sbin -name '*gcc*' -exec ./xisgcc '{}' \;'!

On a RHEL6 system, the stock find command returns

/usr/bin/gcc
/usr/bin/gccmakedep
/usr/bin/gcc34
/usr/bin/x86_64-redhat-linux-gcc
/usr/bin/gnatgcc
/usr/bin/x86_64-redhat-linux-gcc34
find: `/opt/bin': No such file or directory
find: `/opt/sbin': No such file or directory

$ find --version
find (GNU findutils) 4.4.2

For missing directories, find returns an error message that contains a backtick ` and ends with an apostraphe '. Looking at IsGcc.c calls CompIsGcc() in altconf_misc.c which calls atlsys_1L in atlas_sys.h that tries to invoke this command using system(). The system() function will attempt to execute the find error message using /bin/sh.

Looking at CONFIG/src/probe_comp.c, I see several 'find' commands which call atlsys().
In CONFIG/include/atlas_sys.h:252, I see both stdout and stderr are redirected to the output file.

252       sprintf(sp, "%s > %s 2>&1\n", cmnd, tnam);
253    }
254    i = system(sp);

Changing stderr redirection 2>/dev/null (and increasing the preceding strlen to adequate buffer size 16>24) eliminates the error.

I can understand retaining stderr would help with debug messages, but I don't think stderr output should be used as result of the command for other commands. It would be better to redirect stderr to a separate tmpfile if the results should be displayed under higher verbosity for diagnostics.