EXECUTE_COMMAND_LINE behavior

[Harald]

It appears that the behavior of EXECUTE_COMMAND_LINE does not conform to the F2008 standard, section 13.7.57.

program ifort_execute_cmd_line
  integer :: stat, cstat
  call execute_command_line ("/bin/true",  exitstat=stat, cmdstat=cstat)
  print *, stat, cstat
  call execute_command_line ("/bin/false", exitstat=stat, cmdstat=cstat)
  print *, stat, cstat
  call execute_command_line ("/bin/true",  exitstat=stat)
  print *, stat
  call execute_command_line ("/bin/false", exitstat=stat)
  print *, stat
end

produces:

           0           0
           0           0
           0
sh: -c: line 0: syntax error near unexpected token `&'
sh: -c: line 0: `/bin/false & &'
         256

The error message text is quite surprising, and the last line probably should not print.

I would expect something along what xlf does:

 0 0
 1 1
 0
"ifort_execute_cmd_line.f90", line 9: 1525-610 Error encountered while attempting to execute the command:
/bin/false

[Steven_L_Intel1]

Thanks, we'll take a look. 

[TimP]

Which libraries, for which targets, have added support for execute_command_line?  I'd want it at least for all of intel64 windows/linux/MIC before changing the #if __INTEL_COMPILER clauses to use the standard source path.  The documents page doesn't indicate any requirement for a USE file or special library linkage.

I supposed the delay in beginning to offer this might have been due to the large number of requirements posed by the standard.

[Harald]

Tim Prince wrote:

Which libraries, for which targets, have added support for execute_command_line?  I'd want it at least for all of intel64 windows/linux/MIC before changing the #if __INTEL_COMPILER clauses to use the standard source path.  The documents page doesn't indicate any requirement for a USE file or special library linkage.

I supposed the delay in beginning to offer this might have been due to the large number of requirements posed by the standard.

I understand that EXECUTE_COMMAND_LINE was added only recently.  I tried:

Intel(R) Fortran Compiler XE for applications running on IA-32, Version 15.0.0.090 Build 20140723

Unfortunately other compilers have issues here, too, even if they supported it for quite some time (e.g. gfortran).

[Steven_L_Intel1]

EXECUTE_COMMAND_LINE is an intrinsic - no USE or libraries needed. It was added late in the beta.

It should be supported on all platforms. On Linux and OS X, it's really just "system" underneath (with some logic to deal with wait/don't wait and exit statuses.) It's more complicated on Windows (due to the desire to not put up a console window for a non-console application.)

[Steven_L_Intel1]

Ok, I figured out the error message text. Workaround is to concatenate a NUL to the end of the string to execute. We'll fix that.

Still working on the exitstat issue. I don't understand why xlf gives the error message on the last call, though. That seems wrong to me. The standard doesn't say an error occurs if the exit status is non-zero, only if the command was unable to be executed and CMDSTAT not supplied.

[Steven_L_Intel1]

I think the xlf results are incorrect. There's certainly no excuse for CMDSTAT to have returned 1.

[Still working on /bin/false exit status]

[Harald]

Steve Lionel (Intel) wrote:

I think the xlf results are incorrect. There's certainly no excuse for CMDSTAT to have returned 1.

[Still working on /bin/false exit status]

Looking at my copy of the F2008 draft standard, I find:

13.7.57 EXECUTE_COMMAND_LINE

[...]

CMDSTAT (optional) shall be a default integer scalar. It is an INTENT (OUT) argument. It is assigned the
         value −1 if the processor does not support command line execution, a processor-dependent positive
         value if an error condition occurs, or the value −2 if no error condition occurs but WAIT is present
         with the value false and the processor does not support asynchronous execution. Otherwise it is
         assigned the value 0.

So, assuming that a non-zero exit status is considered an error condition, I find that xlf behaves correctly.

Furthermore, a few lines below the above paragraph, the standard says:

If a condition occurs that would assign a nonzero value to CMDSTAT but the CMDSTAT variable is not present,
error termination is initiated.

Again, xlf's behavior looks consistent to me.  Did the wording change in the final version of the standard, or am I missing something?

Harald

[Steven_L_Intel1]

CMDSTAT should give you an error indication only if it was unable to run the command (system returning -1). It looks as if xlf is treating a non-success exit status as a command execution error, which I think is wrong. If a nonzero exit status was also a command error, what's the point of a separate EXITSTAT?

[Harald]

Steve Lionel (Intel) wrote:

CMDSTAT should give you an error indication only if it was unable to run the command (system returning -1). It looks as if xlf is treating a non-success exit status as a command execution error, which I think is wrong. If a nonzero exit status was also a command error, what's the point of a separate EXITSTAT?

I asked that question on c.l.f:

https://groups.google.com/forum/?hl=en#!topic/comp.lang.fortran/6ymZIb6flDg

and there was a consensus that xlf gets this wrong.  With xlf there's no way to figure out whether the command could be executed at all.

According to the Linux man page, system(3) does not necessarily give all the information to distinguish the different ways of failures...

Harald

[Steven_L_Intel1]

Right. system(3) returns -1 if it was unable to execute the command, but that's all you get. We convert that to a single error code, since there's no additional information.

[Steven_L_Intel1]

The problems noted will be fixed in Update 1.

[Harald]

Steve Lionel (Intel) wrote:

The problems noted will be fixed in Update 1.

Indeed Update 1 works for me.

Thanks,

Harald