Al Greynolds
www.ruda.com
> INQUIRE(FILE='some directory specification',EXIST=ex) correctly tests
> for the existence of a directory with all my Windows compilers
> (g95,gfortran,lf95) except IVF. Does anybody know the reason for this
> and what the standard says if anything?
it would be ambiguous? On some systems, there isn't even a concept of a
directory. There may be a "qualifier/account number" associated, but
nothing like a directory, so the standard shouldn't really say that a
"file" and a "directory" should be detected portably across OS'. There
are situations when you actually want to differentiate between a file
and a directory, and you can't using this syntax without prior
knowledge. Didn't IVF add some extensions specifically for querying
directories? CVF does handle directories with the above inquire statement.
>
> Al Greynolds
> www.ruda.com
>
>
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
Yes they did, but I was looking for something that is portable (at
least among the compilers I use). Its interesting that they changed
the default behavior from CVF to IVF.
Anyway its not a big deal just a curiosity.
Al
> INQUIRE(FILE='some directory specification',EXIST=ex) correctly tests
> for the existence of a directory with all my Windows compilers
> (g95,gfortran,lf95) except IVF. Does anybody know the reason for this
> and what the standard says if anything?
The Fortran standard does not even have the concept of a directory (and
Fortran has been implemented on systems that don't have such a thing),
so it says nothing about it.
As I recall, the C standard is actually quite simillar in not having
such a concept. Sure there are widely used C libraries that do, but I
don't recall that it was directly in the C standard.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
> On Aug 21, 2:31 pm, Gary Scott <garylsc...@sbcglobal.net> wrote:
>
>>Didn't IVF add some extensions specifically for querying
>>directories?
>
>
> Yes they did, but I was looking for something that is portable (at
> least among the compilers I use). Its interesting that they changed
> the default behavior from CVF to IVF.
I'm pretty sure I was one that complained about the way DVF or CVF
implemented this. I had a specific situation where I needed to
differentiate a directory from a file (file names don't have to have
extensions/types suffixed to them). So I may or may not have had some
tiny influence on it being changed (don't know, assume it would take
lots of complaints or some other serious reason to change it).
>
> Anyway its not a big deal just a curiosity.
>
> Al
Note: this is a memory, which may be wrong.
I personally use non-portable methods myself..
On Windows and Linux/UNIX/OSX a directory contains a special
file named ".". You might try:
INQUIRE( FILE = 'mydirectory/.', EXIST = exists )
Regards,
Arjen
To be a little bit more portable, I also use an environment variable
called for instance DELIMITER which is equals to "\" on Windows and
"/" on unix :
CHARACTER :: delimiter
...
CALL get_environment_variable('DELIMITER',delimiter)
INQUIRE(file='mydirectory'//delimiter//'.',EXIST=exist)
Of course :), though I recently tried to see if a forward slash
would be acceptable on Windows (I used three different compilers)
and they all accepted both a / and a \ as a directory delimiter.
Regards,
Arjen
Even a microsoft compiler ?
> Of course :), though I recently tried to see if a forward slash
> would be acceptable on Windows (I used three different
> compilers)
> and they all accepted both a / and a \ as a directory
> delimiter.
>
> Regards,
>
> Arjen
Even a microsoft compiler ?
At least my old MS Fortran 77 ver. 5.0
Kurt
I tested CVF 6.6C, g95 (under MinGW) and gfortran (under Cygwin).
For the latter two it was surprising that they supported \.
(I haven't tried MSVC yet - but I would welcome an opportunity
to get rid of backslashes :). And I do not have a copy of any
MicroSoft Fortran compiler anymore)
Mind you: just as in C, a backslash is sometimes used as an
escape character, making its use in program text slightly
awkward.
Regards,
Arjen
> Of course :), though I recently tried to see if a forward slash
> would be acceptable on Windows (I used three different compilers)
> and they all accepted both a / and a \ as a directory delimiter.
Should just work. See
http://blogs.msdn.com/larryosterman/archive/2005/06/24/432386.aspx
for example.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
>>Of course :), though I recently tried to see if a forward slash
>>would be acceptable on Windows (I used three different compilers)
>>and they all accepted both a / and a \ as a directory delimiter.
> Even a microsoft compiler ?
As I understand it, at least since DOS 3.2, (the first
version I ran) and continuing through current Windows systems,
either / or \ is accepted by system calls, such as open.
The command interpreter uses / to indicate command options,
and so will not accept them is separators.
It is normal to use / for C #include even on DOS/Windows.
It should also word for the Fortran OPEN statement
when used on DOS/Windows.
For system(), I believe it executes a command interpreter
(CMD.EXE) which would disallow / as part of a file path.
-- glen
> As I recall, the C standard is actually quite simillar in not having
> such a concept. Sure there are widely used C libraries that do, but I
> don't recall that it was directly in the C standard.
Some people get confused between the C library and unix
system library. Even more, some non-unix C systems
include unix library functions as extensions.
-- glen
We decided that the CVF behavior was a bug because you could not OPEN a
directory.
As others have noted, you are trying to extend INQUIRE into something
beyond its definition.
--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH
For email address, replace "invalid" with "com"
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://support.intel.com/support/performancetools/fortran
My Fortran blog
http://www.intel.com/software/drfortran
Actually, / is allowed even in command interpreter, starting
from... some Windows version; might be something like 2000 or XP.
It's fairly easy to try it yourself.
It probably doesn't work in all places, as MS likely implemented some
heuristics to distinguish file paths from command line switches
(heh, compare "." as derived-type-component-access-token in
some Fortran extension), but it works as expected most of the time.
--
Jugoslav
___________
www.xeffort.com
Please reply to the newsgroup.
You can find my real e-mail on my home page above.
> Actually, / is allowed even in command interpreter, starting
> from... some Windows version; might be something like 2000 or XP.
> It's fairly easy to try it yourself.
Not in 2000, but it does seem to be in Vista.
> It probably doesn't work in all places, as MS likely implemented some
> heuristics to distinguish file paths from command line switches
> (heh, compare "." as derived-type-component-access-token in
> some Fortran extension), but it works as expected most of the time.
Yes, not all.
One that Windows has had for a long time, maybe even DOS
is that blank space is not a separator in some commands
that only allow one argument.
Compare:
cd \program files
dir \program files
dir "\program files"
It seems that cd in Vista (maybe XP) is also special.
There is only one option allowed: /d
cd /tmp
changes to the \tmp directory
cd /dmp
changes to the \mp directory
For dir, it doesn't seem to work even for letters that
don't have a command option.
-- glen