bug/enhancement: Problem in system calls and stdour/stderr redirection

[markelg]

I found several problems in how this is handled right now in wrapper.py. The exec_cmd function used to call the shell uses subprocess.Popen shell=True option, but this by default uses the /bin/sh shell, even ignoring the default shell of the linux distro.

WRF4G/wrf4g/utils/command.py

Lines 50 to 56 in 272b1e4

	def exec_cmd( cmd, stdout = subprocess.PIPE, stderr = subprocess.PIPE, env = os.environ ):
	logging.debug( "Executing command ... " + cmd )
	p = subprocess.Popen( cmd, shell = True, stdout = stdout,
	stderr = stderr, env = env )
	output = p.stdout.read().strip() + p.stderr.read().strip()
	code = p.wait()
	return code, output

The problem is that /bin/sh does not recognize the typical syntax used in BASH to redirect standart output and standard error to a file:

/bin/sh -c "echo test >& test.txt"
/bin/sh: 1: Syntax error: Bad fd number

This causes the following line to fail in ubuntu, in other linux it may work (like centos) because /bin/sh is redirected to a shell compatible with this syntax:

WRF4G/lib/python/wrf4g/wrapper.py

Line 847 in 767a26d

code, output = exec_cmd( "ungribprocessor.%s >& %s" % ( pp, preprocessor_log ) )

The following line is also wrong because the "&>" is not redirecting the output to the log file.

WRF4G/lib/python/wrf4g/wrapper.py

Line 780 in 767a26d

code, output = exec_cmd( "preprocessor.%s %s %s %s %s &> %s" % (

We can either remove this "&" or set BASH to be the default shell to use by using the executable="/bin/bash" argument of subprocess.Popen.