forums.silverfrost.com

[jjgermis]

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.exe

2) somewhere in test.exe another program c:\users\test2.exe is called

3) 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.

[PaulLaidler]

From an FTN95 program you can call ATTACH@.

[jjgermis]

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:

[JohnCampbell]

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.

[jjgermis]

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 and

2. 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:

[JohnCampbell]

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

[PaulLaidler]

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.

[JohnCampbell]

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.

[PaulLaidler]

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.

[JohnCampbell]

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

[jjgermis]

Hi John,

we do it in a similar way. The batch file that we call from our executable has the following format:

[PaulLaidler]

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.

[jjgermis]

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.