! or system() or unix() - input redirection

I am trying to execute a system command from within Matlab (there is no input or output from/to Matlab, I just need it to call the program and wait).

./forward < input

This works fine in a bash terminal (MACI64), but not from Matlab. I have tried,

!./forward < input

system('./forward < input')

and

unix('./forward < input')

Each time, the input file is ignored.

(I also tried making a shell script containing the full command, but the extra input was still ignored. Also, if I change the name of the input file to one that doesn't exist (e.g. input_null, I get the following error: "/bin/bash: input_null: No such file or directory")

Is there any way to make this work?

thanks.

PS, simpler commands like

!grep -i string < input

work fine from Matlab

[Walter Roberson]

The program you are trying to run -- was it compiled in gfortran ?

[Ben Ward]

It was: gfortran 4.8.0

BTW: to get it to just compile and run without the input file, I had to add to update the path in /Applications/MATLAB_R2012a.app/bin/matlab ...

export PATH=/Library:/opt/local/bin:/opt/local/sbin:$PATH

export PATH=$PATH:/usr/local/bin:/usr/X11/bin:/usr/texbin

and remove the default fortran libraries from /Applications/MATLAB_R2012a.app/sys/os/maci64/

[Ben Ward]

Here is the file used to read the input file...

      module io_mod
      integer driver_ref,shift_obs
      contains
      subroutine driver_init
      use piped_mod
!-----------------------------------------------------------------------
      CHARACTER(LEN=255) :: message           ! use for I/O error messages
      integer, parameter :: stdin=5
!
      namelist /driver_io_nml/
     & site,
     & latitude,
     & physics_dir,
     & eco_dir,
     & physics_mod,
     & output_dir,
     & year1,
     & eval_input,
     & eval_output,
     & n_eval,
     & twin,
     & startelite
!
!-----------------------------------------------------------------------
!   default namelist settings
!-----------------------------------------------------------------------
      site        = 'BATS'
      latitude    = 32.1667
      physics_dir = '../../data/phys_data'
      eco_dir     = '../../data/eco_data'
      physics_mod = 'OCCAM'
      output_dir  = '../output'
      year1       = 1990
      eval_input  = 'hypercube.dat'
      eval_output = 'hypercost.dat'
      n_eval      = 1
      twin        = 0
      startelite  = 0
!
      read(unit=stdin, nml=driver_io_nml,iostat=ios,iomsg=message)
      if(iostat.ne.0)then
        write(*,*)'ERROR: ',ios
        write(*,*)message
      endif
!
      end subroutine driver_init
      end module io_mod

Answer 1

[Ben Ward]

Work-around from MathWorks...

Executing a GFORTRAN executable within a Apple terminal window is not equivalent to executing it within MATLAB. In particular, MATLAB will set various environment variables and this can have unexpected results which seems to be the case here.

To work around this issue you need to set your environment variables for the GFORTRAN-compiled programs correctly within MATLAB before you execute them. You can use the SETENV function for this purpose. Please execute your FORTRAN script as follows:

setenv(‘GFORTRAN_STDIN_UNIT’, ‘5’) 
setenv(‘GFORTRAN_STDOUT_UNIT’, ‘6’) 
setenv(‘GFORTRAN_STDERR_UNIT’, ‘0’)

!./forward < input 

setenv(‘GFORTRAN_STDIN_UNIT’, ‘-1’) 
setenv(‘GFORTRAN_STDOUT_UNIT’, ‘-1’) 
setenv(‘GFORTRAN_STDERR_UNIT’, ‘-1’)

Note that after executing the FORTRAN script, I set the environment variables back to their default values.

For more information on the SETENV function, please refer to the following link:

SETENV : http://www.mathworks.com/help/techdoc/ref/setenv.html

[Sönke]

This workaround works as well for linux(Ubuntu 10.04 LTS)

Strange though that matlab2012a prevents by these environment variables even executing pipes from scripts... (stdout pipes > though worked)

do !env from within matlab2012a to see the environment variables. The above environment variables dont exist in matlab2010a for example (That's how I found this thread by googling for GFORTRAN_STDIN_UNIT)

[Sönke]

There is yet another way to get fortran programs to work use the env command and undefine the variables this will kill your standard input and output but matlab restores them anyway, somehow.

env -u GFORTRAN_STDIN_UNIT -u GFORTRAN_STDOUT_UNIT -u GFORTRAN_STDERR_UNIT "command including pipes"

from a script

could work

but putting them into a shell file separately from "command including pipes" will somehow still restore the GFORTRAN_XXX_UNIT environment variables even from within the script ??

[Natalie]

Thanks for the answer! This fixed a similar problem I was having trying to pipe a file into a fortran executable

Answer 2

[Walter Roberson]

Please have a look at http://www.mathworks.co.uk/matlabcentral/answers/43640-a-peculiar-problem-when-using-system-command-to-run-a-c-shell-script-from-matlab and at http://www.mathworks.co.uk/matlabcentral/answers/38589-system-or-unix-command-run-compiled-fortran-binary-fails-but-it-runs-fine-from-a-terminal

[Ben Ward]

Hi Walter,

thanks for the suggestions. I'll address the second one first...

I'm on a Mac, so to find the libraries for the executable, I used otool -L. This yielded identical output inside Matlab and the Terminal...

Matlab:

>> !otool -L forward

forward:

  /usr/local/lib/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
  /usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
  /usr/local/lib/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0)

Terminal:

$ otool -L forward

forward:

  /usr/local/lib/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
  /usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
  /usr/local/lib/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0)

using echo $DYLD_LIBRARY_PATH instead of echo $LD_LIBRARY_PATH yields nothing in the terminal, but the following in Matlab:

/Applications/MATLAB_R2012a.app/sys/os/maci64:/Applications/MATLAB_R2012a.app/bin/maci64/../../Contents/MacOS:/Applications/MATLAB_R2012a.app/bin/maci64:/Applications/MATLAB_R2012a.app/extern/lib/maci64:/Applications/MATLAB_R2012a.app/runtime/maci64

I tried clearing this completely in Matlab, but it made no difference.

Regarding the first suggestion, I'm not sure I fully understand, but I don't think the input is going to STDERR? The read parameter is set to 5, which should equal standard input, but it is quite likely there is something I am missing here.

[Ben Ward]

Having just made that last comment, I have hust realised there is a lot of output to the screen that shows up in Terminal, but not in Matlab.

Also, running

!./forward < input > tmp

does not output to tmp as it should.

In both cases, the output goes to fort.6, without having read the input file

[Walter Roberson]

The thread that had the stderr issue happened to be the first and most detailed of a series dealing with I/O problems with executables compiled with gfortran when used under R2012a . The problem likely is not restricted to stderr.

The reports have been against various operating systems; the library problems might only occur on some of them.

I would recommend contacting Mathworks about this issue; perhaps they have a work-around by now. But in the meantime, it appears that using a different compiler such as g77 makes a difference.

[Ben Ward]

I can hack it to work by copying input to fort.5 before calling the executable. Thanks for the suggestions. If you have a more elegant solution, I would be very glad to hear it. cheers, Ben

[Walter Roberson]

Interesting work-around.