Get current directory

[Alessandro_D_]

Dear users,

I would like to get the name of the current directory in Fortran. I tested the following code but it doesn't work:

program test
implicit none
character(len=128) :: pwd
call get_environment_variable('CD',pwd)
print *, "The current working directory is: ",trim(pwd)
pause
end program

The original example was call get_environment_variable('PWD',pwd) but since I am on Windows I replaced PWD with CD. But even then, it doesn't display anything

[FortranFan]

If I recall correctly, "CD" (or the alternate "CHDIR") are pseudo environment variables on Windows OS and as such, you may not be able to fetch the value via Fortran intrinsic 'get_environment_variable' on this OS.

A safer bet is the Windows API 'GetCurrentDIrectory':

https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getcurrentdirectory

If portability across different Fortran compilers is not a concern, you can consider using Intel Fortran solution via their provided Fortran module 'KERNEL32':

   use ifwin, only : GetCurrentDirectory
   character(len=256) :: CurrentDir
   integer :: ilen
   ilen = GetCurrentDirectory( len(CurrentDir), CurrentDir )
   print *, "Current directory: ", trim(CurrentDir)
end

[FortranFan]

Oops, I meant 'use kernel32, only : GetCurrentDirectory' but 'use ifwin ..' should also work.

[Steve_Lionel]

Neither CD nor PWD are environment variables automatically created by Windows. Instead, they are commands.

[jimdempseyatthecove]

You could try

result = SYSTEMQQ("cd>HereIAm.txt")

Then open "HereIAm.txt" and read it.

Jim Dempsey

[GVautier]

Why not use getcwd function?

[FortranFan]

Why not use getcwd function?

It's a vendor-specific solution that may further constrain portability.

[Steve_Lionel]

First, I'll ask why you need this. Perhaps there's a better solution.

Second, I'll propose the following standard code (it does leave the file around, though):

implicit none
character(256) :: filespec
integer :: i
open (newunit=i,file="dummy.xyz",status='unknown')
inquire (unit=i,name=filespec)
close (i)
i = index(filespec,"dummy.xyz",back=.true.)
filespec = filespec(1:i-1)
print *, trim(filespec)
end

[Alessandro_D_]

Thanks for your answer! Indeed it is probably better if I explain what I would like to do. I want to write all the results generated by my program in some txt files stored in a subfolder called "output". The structure of my project folder is the follwing

Main folder contains these subfolders:

--> Console1, where sln,vproj files are located (under Console1, there are Debug and Release)

--> output, where I want to store txt files generated by Fortran

--> src, where I store the source .f90 files

Then in my code I define a character with the path to the "output" folder i.e.

character(len=10) :: savedir

and I assign it as 

savedir='..\output\'

Last, if I want to save the array x to the file x.txt and store x.txt in the folder "output", I write

open(15,file=savedir//'x.txt',iostat=ierr,status='replace')
if (ierr/=0) call myerror("cannot open file")
write(15,*) x
close(15)

The key part is to specify savedir correctly. This is why I wanted to know what folder is considered as current folder by visual studio

[mecej4]

A word of caution is in order.

An EXE may be run using the command processor or a batch file, and may be invoked by another program. This other program may be your program or a program such as VS, and may itself have been called by using a long pathname. Part of the path prefix may not be explicit, but obtained by using %PATH% or other environmental variables.

Therefore, it is incorrect to assume that there is a unique current directory for a given EXE. To illustrate this, we may run Steve L's program twice, once from the directory containing the EXE, and then from the parent directory.

S:\LANG>ifx /Od /MD showdir.f90
S:\LANG>showdir
 S:\LANG\
S:\LANG>cd ..

S:\>lang\showdir
 S:\

[JohnNichols]

A simpler way is to use a small subroutine in C# and use its standard function and simply return the name. 

[Steve_Lionel · Accepted solution]

Visual Studio considers the folder with the .vfproj file to be the "current directory". You can change this with the "Start in" property on the Debug property page. But I agree that you should not depend on this, as if you run the program from outside VS, it will be different.

Instead, I suggest that you prompt the user for where to store the files. Windows has the GetSaveFileName API for this purpose.

[GVautier]

At this point getdrivedirqq may be a solution

https://software.intel.com/content/www/us/en/develop/documentation/fortran-compiler-oneapi-dev-guide-and-reference/top/language-reference/a-to-z-reference/g-1/getdrivedirqq.html

[jimdempseyatthecove]

Generally, excepting during development, it is a bad Idea to place your data files in some place in your development folders.

If the program is launched with doubleclick/click,open you have no assurances of what the current directory is.

It may be best to require passing the input and output folder(s) and/or file names as command line arguments. Note, launched with doubleclick/click,open it would have no arguments, and to which you could display a complaint and exit.

You can easily specify these in the Debug properties for development.

From command line:

CD \YourDesieredWoekingFolder
YourProgram .\input .\output arg arg arg

or

YourProgram "\This is your input folder" "\And your output folder" arg arg arg

Jim Dempsey

[Norman_K_]

What Steve said but with

close(i, status="delete")

[GVautier]

You must test if the file already exists before opening and delete it only if not. You must also find an unused unit number to avid side effects. It's somewhat complicated.

Furthermore, that method will fail if the current drive/directory is readonly.

[David_Billinghurst]

> You must also find an unused unit number to avoid side effects.

The Fortran 2008 NEWUNIT specifier on the open statement avoids this issue.  It automatically chooses an unused (negative) unit number.

[David_Kinniburgh]

This solution assumes that INQUIRE returns the full path. As discussed before, the standard merely requires that the processor returns a name that will find the correct path. While Intel compilers do return the full path, gcc and NAG, for example, do not and so in these cases, this routine returns a blank result. I do not understand why all compilers do not return a full path as this would provide a neat solution to what can be a tricky problem. Is it simply backward compatibility or a Fortran desire to avoid getting involved in any details of the operating system? Such a change would not require a change in the standard.

PS Adding status='DELETE' to the CLOSE statement should get rid of the temporary file.

[Steve_Lionel]

There can be more than one "full path" to the same file, and some platforms may not have the ability to return the full path for an opened file. The standard requires that the returned string be suitable for use in an OPEN statement. 

[Pathan]

Please try this simple solution

use msflib

use portlib

.

.

.

integer * 4 iostat

iostat=getcwd(fil)

.

.

.