EXECUTE_COMMAND_LINE problem

[John4]

Hi,

With the new version of the compiler, the EXECUTE_COMMAND_LINE intrinsic fails under circumstances the SYSTEM() function didn't.

In a particular program, many of the commands I execute have ">/dev/null 2>&1" at the end (without the quotes), and that causes sh (both as bash and dash) to return with "sh: 1: Syntax error: Bad fd number".

When the command contains quotes (e.g., EXECUTE_COMMAND_LINE('cp -t "./" "/some/file"')), sh shows that the intrinsic subroutine seems to append some garbage characters that end with \220. And combined with redirection, the message shown by sh is "sh: 1: ambiguous redirect" or syntax error due to unexpected token.

In all the cases, the actual argument is an expression (since I have ">/dev/null 2>&1" as a parameter defined somewhere else, and it's just being concatenated, and I'm also applyign concatenation for quoting the files in the command). And in all those cases, the EXECUTE_COMMAND_LINE intrinsic reports 0 in EXITSTAT and CMDSTAT.

I already checked all the commands being passed, and they're fine (and work properly with SYSTEM and SYSTEMQQ), so the problem should lie in the implementation of the EXECUTE_COMMAND_LINE intrinsic.

I apologize for not providing a test case, but so far I haven't been able to create a small test case.

[Kevin_D_Intel]

Some other issues were reported with EXECUTE_COMMAND_LINE here and perhaps some of what you reported seeing related to EXITSTAT and CMDSTAT may be related to the earlier report.

As noted in the earlier post, the issues are expected to be fixed in IPS XE 2015 Update 1 (tentatively due out next month). If you are able to recreate the issues in a reproducer that you feel comfortable sharing with us (large or small) then we can certainly check to see if the issues will be addressed in that update and forward to Developers if not.

[Steven_L_Intel1]

There is a known bug in EXECUTE_COMMAND_LINE on Linux and OS X where it fails to nul-terminate the command, leading to unexpected behavior, This will be fixed in Update 1. A workaround is to concatenate a nul (CHAR(0) or ''C) yourself.

CMDSTAT will be 0 unless something horribly goes wrong, not just a failure of the command.

[John4]

Hmmm, so that explains the whole behavior.  The frequent \220 in sh's error message might just be a coincidence.

I agree that CMDSTAT should only return values that can be explained through CMDMSG (I mentioned it in the related comp.lang.fortran's thread).

For now, it's easier to just keep using my wrapper to SYSTEM().

[TimP]

call execute_command_line("uname -ps > uname.txt"//achar(0))

works for me. gfortran doesn't require the explicit nul character on either linux or Windows.

[Steven_L_Intel1]

The explicit NUL is just a workaround for the bug that will be fixed in Update 1.

[Kevin_D_Intel]

Here is internal tracking number for the bug Steve noted.

(Internal tracking id: DPD200360461)