Execute a program in another directory

What needs to be done in oder to execute another program in a different directory (other from the directory from which it is called), i.e.1) the actual program is started in c:\prog\test.exe2) somewhere in test.exe another program c:\users\test2.exe is called3) test2.exe will look in c:\prog (current directory) for any files (by default) and not in c:\users

Question: How can I force my current directory (c:\prog) form the calling program to be c:\users for the time test2.exe is called?

When I debug the calling directory is ..\debug\win32 and the program that is being debugged is will look for files in ..\..\. I do hope that my question is clear.

From an FTN95 program you can call ATTACH@.

This works fine for our application and is sort of a work-around for the following situation: We automatise software of which we do not have the source code. Without the attach@ subroutine we have to copy our executable in the project directory. Obviuos this becomes undesired with an increase in the number of projects. The code is as follows: write(,'(1X,'Change to ',A)') trim(PATH)
call attach@(PATH,error_code) !Change to project directory call doserr@(error_code) if (ik == 1) then write(,'(1X,'Clean directory')')
call cissue('delete.bat',i) endif write(,'(1X,'Write A_cpff')')
call change_mlo_file(Ld_Lq_Up) !Update the input file write(,'(1X,'Start batch file')') call cissue('A_cpff.bat',i) !Call program write(,'(1X,A)') 'Rename BCH ...'
call cissue('ren_BCH.bat',i) write(,'(1X,A)') 'Read BCH ...' call read_BCH_file(Ld_Lq_Up)
call cissue('delete.bat',i) !Clean the directory

Each time the software starts the window is maximised and becomes the top window of the desktop. For the time we have no better solution. It would be nice to have a trick to avoid this, i.e. be able to contol the windows.

I think you have a number of alternative options available, including:

1. install all .exe and .bat files into a general directory and include this directory in the path.
2. as you are using .bat files, you could include the project directiory path in the .bat files.
3. you could use an environment variable (see dos SET command) to define the project area for each run and use this in the .bat file

One of the problems I have found with the attach@ routine is that on exit from the control program, the default directory reverts to the original directory. I always had problems with that and I'm not sure if the changed directory will be kept when using cissue, start_process@ or start_pprocess@. Defining a project directory environment variable, which is available in the .bat files may be a useful solution. Again, if you define this in the program by using cissue ('SET Project_Directory=c:\user\project_3'), (or whatever is the correct syntax !!), the extent of the availability of this variable definition in subsequent CISSUE calls may still be a problem. So (in XP) you may need to define the project variable outside your program using Control Panel > System > Advanced > Environment Variables. I think you need Administrator status to do this, which I typically do not have. I find this a very frustrating problem!

I tried the following program, but it does not work, (or my method of testing does not work), as I think I have the SET syntax wrong.

! Program is
      integer*4 i
      call cissue('set project_directory=c:\\group\\project_02',i) 
      write (*,*) 'i=',i
      call cissue('set',i) 
      call cissue('ss.bat',i) 
      call cissue('set',i) 
      end

! ss.bat is
set project_directory=test_02
set

FTN95 also use a number of these variables.

Good luck

John

We indeed use the environment variable in the batch file (the external program allows this). Copying all the executables in one directory is a possible solution. However if we change the code one needs to copy the this again. In oder to avoid this we have 1. c:\control_program and2. c:\external_program where we put our control program and external program respectively.

Since the have different versions of the external program it is better to set the environment variable in the batch file rather than in the source code. For our application the attach@ functions works good. The batcg file looks like: rem rem Runs wfemag rem

set femdir=C:\\external_program\\2009_08

%femdir%\\wfemag A_cpff.MLO

In the given example we use version 2009_08 of the external program. This allow a users to freely specify the version to be used. I prefer the cissue command rather than start_process@. To be honest I do not understand start_process@ or start_pprocess@ - at least for what we are doing.

I tested your code and can report the same experience than you: It does not work. Unfortunately I cannot explain why it does not work 😦

My take on why the attach@ works in your control program, but my use of SET to change environment variables does not transfer between CISSUE is that:- Attach@ is an initial 'environment' setting which is applied to all run environments it initiates via CISSUE, while; Each CISSUE starts with the environment of the control program, but any changes made in this process are lost when it ends.

This is demonstrated in my program, where within the 3rd CISSUE, SET shows the variable has been changed, while the 4th CISSUE use of SET shows the changes are lost.

I previously tried to write a program GO.exe, where you could specify a directory, and the program would search the disk for a tree name that contained the directory, go there and then exit. The idea was to save on typing the full tree name. You can do it in a batch file, but not using a .exe with an attach@, as the effective CD is lost when the program ends.

I may have this all wrong, so would welcome any corrections to my misconceptions !!

John

The underlying issue concerns the way in way the Windows API CreateProcess is called. If you look up the details on MSDN then you will see that it is possible for the new process to inherit the existing environment. Chances are that CISSUE etc do not do this.

Paul,

I have attempted to change directory and exit the program to the new directory using 2 possible ways and both appear to fail after exiting the program. Can either of these be modified to achieve my aim ? I can later use goo.bat as a command, but that's another command.

I use recursive calls to files@ to search the disk for possible values of target_path, which works very well, after the first time it is used.

!
      write (*,*) 'Attaching to ', trim (target_path)
      call attach@ (target_path, error_code)
      call doserr@ (error_code)
!      call exit (0)                               ! did not work
!
!--- Create a goo.bat file if all else fails
      open  (unit=11, file='c:\\tmp\\goo.bat')
      write (11,*) 'cd ', trim (target_path)
      write (11,*) 'cd'
      close (unit=11)
!
      call cissue ('c:\\tmp\\goo.bat',i)    ! also did not work

      end

Both CISSUE and START_PROCESS@ end up calling CreateProcess. The only difference is that CISSUE prepends 'cmd /c' to the given command. The result is that CISSUE launches a new command shell (presumably a shell within a shell).

Anyway, the problem is that CreateProcess does not pass the so-called 'environment block' to the spawned process. Also the current working directory is not and cannot be inherited by the call to CreateProcess.

It looks like we need to be using CreateProcessAsUser or CreateProcessWithLogonW in order to get the spawned process to inherit the current working directory.

Given time, I could probably provide a new Fortran library routine (a variant of START_PROCESS@) that does the trick but not in time for the inpending new release.

In the mean time users could try writing their own function in C. Calling CreateProcessAsUser directly from Fortran is probably not an option.

I put my .exe program in a batch file 'go.bat' which consists of:

go_find.exe %1
\\tmp\\goo

This solves the problem, as batch files can modify the current directory

Hi John,

we do it in a similar way. The batch file that we call from our executable has the following format: set femdir=C:\Programme\femag\2009_08

%femdir%\\wfemag %1

If we know the log file which the (external) program should run on start the %1 is replaced with the name of the logfile, i.e. [color=green:5dc87272c3]%femdir%\wfemag logfile.MLO [/color:5dc87272c3](for example).

I am not clear as to whether this issue has now been resolved but I need to correct an error in my previous post.

CreateProcess has an argument for the current working directory. If this argument is NULL (as it is within CISSUE and START_PROCESS@) then the new process inherits the cwd of the calling process.

Paul thanks for your last comment. For us this issue is resolved and we can continue our project as planned (the FTN95 attach@ function works fine for us). From the last post from John it seems like he has a solution as well.

The START_PROCESS@ and CISSUE functions is clear as well.