Odd GET_COMMAND_ARGUMENT behavior

I needed access to more than just the program name.

I first call CMPROGNM@ to get the executable name.

I then executed the following sequence, but it didn't pick up the second command line argument

if(cmnargs@() .ge. 1) then ! --- we have a copmmand line argument. Assume it is the COALCNFG.DAT pathname call get_command_argument(1,CONFIG,l,istat) print *,'L,istat=',l,istat
print *,'New coalcnfg.dat file is: ',trim(CONFIG) endif

This yields a length of zero (L=0) and a status (ISTAT = 1 [error])

However, if I add the same call, but attempt to pick up the command name first, this call yields the L=0 and ISTAT=1, but the second yields L=20 (proper length), ISTAT=0 (success), and properly returns the second command line argument. if(cmnargs@() .ge. 1) then ! --- we have a copmmand line argument. Assume it is the COALCNFG.DAT pathname call get_command_argument(0,CONFIG,l,istat) print *,'L,istat=',l,istat
call get_command_argument(1,CONFIG,l,istat) print *,'L,istat=',l,istat
print *,'New coalcnfg.dat file is: ',trim(CONFIG) endif

This makes no sense to me, but there has to be a reason! Bill

What does Get_Command return ?

I do not have the source code for the FTN95 library to hand so I don't have a direct answer.

There is a mix of old (FTN77) and new (Fortran 2003) routines here. So maybe this is the cause. Command_argument_count is the 2003 routine to use with get_command_argument.

There are some idiosyncracies in the command line argument routines, probably as Paul says because this particular wheel has been reinvented several times. In Fortran 77 the routines are extensions, and in a later version of Fortran they are standard-defined routines.

In one program of mine, I tested for whether the program was being launched from the Start menu (or clicking on its icon on the desktop) vs by clicking on a filename and the program being launched from its association, by counting the command line arguments:

      INVOKED = CMNARGS@() 

Then, if INVOKED told me that there was something on the command line other than the program name, I went looking for the filename with the following inelegant loop:

       IF (INVOKED .GE. 1) THEN
           FILEN  = CMNAM()
           FILENM = FILEN(2:257)
           DO 10 I=1,256
           IF (FILENM(I:I) .EQ. ''') FILENM(I:I)=' '
 10        CONTINUE
           ENDIF

For reasons that escape me now, I had to throw away the first character returned by CMNAM, and rid what was left of double quote marks!

On reflection I probably used a routine that made life harder than it needed to be to get the first argument from the command line after the program name. This program is SDI not MDI so only needs to capture the first filename.

Eddie

Can anyone modify this demo to work? That damn thing with command line arguments harassed me for a long time so i stopped using it. But started today and the same story - demo does not work, the larger code sometimes does work sometimes doesn't. May be new Fortran function will give better stability

include <clearwin.ins>
integer cmnargs@

n_ofArguments_inCommand_line = cmnargs@()
print*, 'n_argComm_line=', n_ofArguments_inCommand_line
end

Because, Dan, you aren't printing out the number you got from the function!

Not:

   n_ofArguments_inCommand_line = cmnargs@() 
   print*, 'n_argComm_line=', n_argComm_line 
   end

But

   n_ofArguments_inCommand_line = cmnargs@() 
   print*, 'n_argComm_line=', n_ofArguments_inCommand_line
   end

Eddie

I know, that was quick typo, sorry, i changed that almost immediately while you were typing, but change did not cam through due to server error. Changed again. It still does not work. Does it work in your case?

From the FTN95 help file :

When calling CMNARGS@ you must declare it as INTEGER(KIND=2).

Thanks mecej4. Damid, is this Integer2 again? Why the hell this was designed as integer2? Integer*2 must be pesticided out of this compiler's library

If you don't like the INTEGER*2 version, there's always the more futureproof COMMAND_ARGUMENT_COUNT

There's a whole section in FTN95.CHM on command lines.

I see that in the F2003 intrinsic

GET_COMMAND_ARGUMENT(NUMBER, VALUE, LENGTH, STATUS)

that VALUE is optional. Perhaps there's an expert out there who will explain to me what the point is of:

CALL GET_COMMAND_ARGUMENT(1)

(i.e. opting not to provide a variable for VALUE) or from experience what happens if NUMBER is greater than the value returned by COMMAND_ARGUMENT_COUNT

Eddie

How anyone will like how this functionality was done if you use integer*2 only for this purpose and never again? Of course there is no reason for that and so you do not expect such counteruntuitive requirement. Result is an error. And hell knows why the FTN95-specific function also has to be in declarations, can't developers declare them themselves?

I wrote many times here my request to kill integer2 out of library, I lost disproportional amount if time debugging that making errors every time I try to use such functions again. Every single time I am on the hook with integer2, I always think that adding such functions will take a minute or two but in reality lose a day and even ask help here. I even found one old program where I tried many times and gave up.