GETCWD returns blanks ?

[WSinc]

Character*80  CWD

call getcwd(CWD)

when I print that out it gives all blanks.

Is that the way it is supposed to be used ?

I want to know what directory I am pointing to.

[andrew_4619]

No it isn't the way to use it. Did you try looking in the help file on how to use it?

[WSinc]

I did look at the HELP file, but there is a lot of confusion as to whether its supposed to be a FUNCTION or reference via a CALL statement.

It would be nice to have some actual examples to look at.

I could change the function call from a subroutine call, see what happens.

I think the important thing is to be to be SURE that I am actually opening the file I want, rather going off into lala land and trying to access a file that does not exist.

If it opens a scratch file, I dont get a clue about that. But I still dont see why a file with 236K bytes if it made one.

If I get the file name wrong, then is there a way to know about that ? In other words, I dont was to open a scratch file by mistake.

Maybe there is an example of how to do that properly ?

[Steve_Lionel]

Show us the actual program and the actual output, along with something that tells us what the directory should be (don't you tell us, show us what Windows says.)

I just tried it with your snippet:

D:\Projects>type t.f90
Character*80  CWD

call getcwd(CWD)
print *, CWD
end
D:\Projects>ifort t.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.1.1.216 Build 20200306
Copyright (C) 1985-2020 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.26.28806.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:t.exe
-subsystem:console
t.obj

D:\Projects>t.exe
 D:\Projects

Your turn.

[WSinc]

curr work dir=
input file name:
lafa.mid
Access method:
stream
LGU 2 file opened OK
words per record:
1
reading record # 1
forrtl: severe (24): end-of-file during read, unit 2, file C:\Users\Administrator\Documents\Visual Studio 2010\Projects\Console8\Console8\lafa.mid
Image PC Routine Line Source
libifcoremdd.dll 77E519D2 Unknown Unknown Unknown
libifcoremdd.dll 77E8ED7F Unknown Unknown Unknown
Console8.exe 00DA2F34 _GETMIDI 35 CONSOLE8.F90
Console8.exe 00DA416F _MAIN__ 7 CONSOLE8.F90
Console8.exe 00DA5EEF Unknown Unknown Unknown
Console8.exe 00DA48AF Unknown Unknown Unknown
Console8.exe 00DA46DF Unknown Unknown Unknown
KERNEL32.DLL 76B16359 Unknown Unknown Unknown
ntdll.dll 77467B74 Unknown Unknown Unknown
ntdll.dll 77467B44 Unknown Unknown Unknown

Here is the source code:

The first few lines illustrate the problem.

Why isnt it consistent with what you have ?

subroutine getmidi()
character*20 FN /"LAFA.MID" /
character*20 AM
character*60 cwd/"barf"/
integer(4) midirec(60)
!!!!!!!!!!!!!!!!!!
110 format(A20)
12 call getcwd(CWD)
print *,"curr work dir=",cwd
print *,"input file name:"
READ(*,110)FN
print *,"Access method:"
READ(*,110)AM
open(2,file=FN,access=AM, form="UNFORMATTED")
35 print *,"LGU 2 file opened OK"
print *,"words per record:"
read(*,*)nwds
do irec=1,100
print *,"reading record #",irec
! this is where it falls apart
! It gives me an EOF, rather than reading in any data.
! I am trying to use STREAM input
read(2)midirec(1:nwds)
print *,"record ",irec," read"
print *,"contents:",midirec
enddo
end

[WSinc]

I cant figure out how to return that entire file back to you.

But the current issue is: Why doesnt GETCWD give me the path name ?

It only returns a blank line.

I was trying to use that to make sure my path name was pointing correctly.

Of course, if YOU have the file, then its path name will be different, right ?

[WSinc]

I didnt return the entire program, because I thought you would only want to see the part that was causing trouble, not several hundred other source lines that were not relevant.

So I sent you that one subroutine.

[Steve_Lionel]

Hmm, that's a rather long path for your current directory. I wonder how many characters it is? (That's a hint...)

[Steve_Lionel]

I will also point you to the documentation for GETCWD - it is a function that returns a value which you could test. You should add USE IFPORT to use any of the portability procedures. (You WILL need this if you reference it as a function.)

[WSinc]

Well, I took your suggestion, and still got the same result.

I could not help noticing the problems others had in the past about this issue.

anyway, please take a look at my  "FIX"

I am NOT using the drag and drop, since there is only ONE attachment, see below.

================================

program getmidi
use ifport
character*20 FN /"LAFA.MID" /
character*20 AM
character*80 cwd,dir
integer(4) midirec(60)

110 format(A20)
12 istat=getcwd(dir)
if(istat == 0)&
    print *,"curr work dir=",dir
1 print *,"input file name:"
READ(*,110)FN
print *,"Access method:"
READ(*,110)AM
open(2,file=FN,access=AM, &
form="UNFORMATTED")
35 print *,"LGU 2 file opened OK"
print *,"words per record:"
read(*,*)nwds
do irec=1,100
print *,"reading record #",irec
! this is where it falls apart
! It gives me an EOF, rather than reading in any data.
! I am trying to use STREAM input
read(2)midirec(1:nwds)
print *,"record ",irec," read"
print *,"contents:",midirec
enddo
end

[Steve_Lionel]

The documentation of GETCWD is here - it is unambiguously a function, not a subroutine. There is even an example (though incomplete - needs an END.) There's also the example I posted for you earlier.

Bill, it is difficult to follow all of your threads that relate to the same problem. Can't you stick to one thread?

Please provide a link to "problems others have had in the past about this issue" (not sure exactly which of your multiple issues you're referring to.) I am unaware of any issues with GETCWD. The basic problem you had was that the variable you were passing was too short to hold the current directory path.

May I suggest that you declare variable dir to be longer than 80? Maybe 120 or so. You don't use "cwd" at all.

Looking again at your latest program version, I note that "words per record" is something you input. What are you putting in there? It doesn't make a lot of sense to me as the MIDI file format uses two-byte "words", not the four-byte you declare. You also are not parsing the header.

As far as I can tell, all of your problems are of your own making.

[mecej4]

Bill, your questions regarding GETCWD  set aside, note that these lines from the code that you posted guarantee that the program will fail.

open(2,file=FN,access=AM, &
form="UNFORMATTED")
35 print *,"LGU 2 file opened OK"
!...
do irec=1,100
print *,"reading record #",irec
! this is where it falls apart
! It gives me an EOF, rather than reading in any data.
! I am trying to use STREAM input
read(2)midirec(1:nwds)

Fortran unformatted files contain metadata in addition to the actual user content. One such metadata item is the length of each record. A Midi file, a Jpeg file or a Zip file will not contain this metadata, since the standards for those file formats do not include that information, and people who work with such files probably used languages other than Fortran.

Therefore, your program will interpret some data bytes as containing record length metadata. 

The first four bytes of a MIDI file, according to https://www.cs.cmu.edu/~music/cmsip/readings/Standard-MIDI-file-format-updated.pdf, are 'M','T','h','d'. In hexadecimal, these four bytes would be written as Z'6468544D', which in decimal is 1,682,461,773. By using FORM='UNFORMATTED" for such a file, you are guaranteeing failure, because the Fortran READ will to read that many bytes (or 4 X that many, if the record length unit is words rather than bytes).  The very first attempted READ wants to see a record that is many thousands of times longer than the entire length of your file, fails, and signifies EOF.

You used just the specifier FORM='UNFORMATTED', but then talk of using stream I/O. You do not get stream I/O unless you ask for it, with the specifier ACCESS='STREAM'.

[WSinc]

Of COURSE it will fail.

I am trying to find an approach that does NOT fail.

[andrew_4619]

I did a google and downloaded the first midi file I found ( teddybears picnic) . I then make a simple sub 20 line program to read it. I don't see any problem reading it. The files are attached.

(BTW drag and drop on the target box would not work for me in Chrome, I had the click the "browse" button and then pick the file)

[WSinc]

OK, I will try your source code.

Anything that works is fine.

[Steve_Lionel]

@mecej4 "You used just the specifier FORM='UNFORMATTED', but then talk of using stream I/O. You do not get stream I/O unless you ask for it, with the specifier ACCESS='STREAM'."

He reads in the ACCESS method from the terminal, but never told us what he uses for input values. It does work if STREAM is entered - and by work, I mean data is read.

[mecej4]

Steve_Lionel wrote:

"He reads in the ACCESS method from the terminal, but never told us what he uses for input values. It does work if STREAM is entered"

Let us grant that he may have entered the correct string, "STREAM". Even then, since he did not specify STATUS='OLD',  or any status string at all, if the working directory was not already the same as the one containing his MIDI file, the OPEN would have created a new zero length file, and reading that file would fail with EOF. 

Andrew_4619 provided a complete solution. It is up to WSincl to try that solution and learn from it.