Some compilers, e.g. ifort, Compaq Visual Fortran and VMS provide a complete file name, including the path and (Where appropriate) the device as the return NAME= argument to INQUIRE. These compilers interpret symbolic links and symbols.

Some compilers, e.g. Oracle/SUN Studio, gfortran and g95, only return the name passed as the FILE= argument. However it is usually possible to capture a complete file name and path using the C library routine realpath.

realpath is not supported under MacOS. Perhaps this is because a path may pass through case sensitive and case insensitive directories. Is there an alternative to realpath which would return a canonical file name under MacOS and gfortran?

Thank you for your help,

John

On Wednesday, May 26, 2021 at 9:36:33 AM UTC-7, john.c...@simconglobal.com wrote:

(snip)

> realpath is not supported under MacOS.

On my macOS Sierra machine, man realpath gives the manpage for it,
as with Linux, says it came from 4.4BSD.

I didn't try actually using it.

> Perhaps this is because a path may pass through case sensitive and
> case insensitive directories. Is there an alternative to realpath which would
> return a canonical file name under MacOS and gfortran?

I don't think that would be a problem. The case-insensitive HFS are still case
preserving.

But yes, lots of fun with different file systems. I run my OS X system with an
NFS mounted disk that I use for most of the files, which is case sensitive like
usual Unix disks. I have never had an actual problems caused by case, but
it is possible.

On 5/26/21 3:11 PM, gah4 wrote:
> On Wednesday, May 26, 2021 at 9:36:33 AM UTC-7, john.c...@simconglobal.com wrote:
>
> (snip)
>
>> realpath is not supported under MacOS.
>
> On my macOS Sierra machine, man realpath gives the manpage for it,
> as with Linux, says it came from 4.4BSD.
>
> I didn't try actually using it.
>
>> Perhaps this is because a path may pass through case sensitive and
>> case insensitive directories. Is there an alternative to realpath which would
>> return a canonical file name under MacOS and gfortran?
>
> I don't think that would be a problem. The case-insensitive HFS are still case
> preserving.
>
> But yes, lots of fun with different file systems. I run my OS X system with an
> NFS mounted disk that I use for most of the files, which is case sensitive like
> usual Unix disks. I have never had an actual problems caused by case, but
> it is possible.

I don't know the answer to this question, but my guess is that this is
more of a shell function than an OS or file system function, so it might
be helpful to look at shell commands that perform the desired
translations and work back from there to see how they do it.

In MacOS, you can have several filesystems mounted simultaneously, some
of which are case sensitive and some of which aren't. When initializing
file systems, this is a standard option, so you can even have different
conventions on the same physical disk. And then you can have symbolic
links that go back and forth between them, and shell variables can be
defined that include multiple path steps between them, so there are
relatively few limitations on the possibilities. MacOS also supports the
usual hard links within a file system. There is also the MacOS Finder
alias facility, which is not exactly a hard link and not exactly a
symbolic link, but something in between. If you have to do all this
yourself, there are a lot of possibilities, so it would probably be best
to look at how your favorite shell does it and start from there.

$.02 -Ron Shepard

On Thursday, May 27, 2021 at 10:30:17 AM UTC-7, Ron Shepard wrote:

(snip)
> I don't know the answer to this question, but my guess is that this is
> more of a shell function than an OS or file system function, so it might
> be helpful to look at shell commands that perform the desired
> translations and work back from there to see how they do it.

There is getcwd() to get the current working directory, to prepend to
any relative file name. It seems that realpath() also follows symbolic
links (that isn't so obvious), removes excess /, and also undoes /./
and /../ in the path.

Most shells, and programs that pretend to work like shells, also expand
a leading ~ as the user's home directory, or ~user as the home directory
of another user. Most programs that are not shells, or pretending to
be shells, don't do that, and it looks like realpath() also doens't do it.

In any case, since it comes from 4.4BSD, and is also in Linux, there should
be an open source version available.

But on my system, OS X has it already.

On Thursday, May 27, 2021 at 1:36:33 AM UTC+9, john.c... wrote:
>
> realpath is not supported under MacOS.

I've searched the net with keywords "osx realpath", and there seem several
workarounds, e.g.

* realpath for OS X
https://github.com/harto/realpath-osx
# The subtitle is interesting :) (a.k.a. "the only useful C program I ever wrote")

* Use homebrew
$ brew install coreutils

But on my mac, "$ man realpath" shows some man page, so it might be
already available from other libraries or something (or possibly by default?)
https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/realpath.3.html

* Some other pages...
https://stackoverflow.com/questions/3572030/bash-script-absolute-path-with-os-x