Re: [MiNT] Strange getcwd() return value

[Jo Even Skarstein <joska@online.no>]

On Thu, 2013-10-24 at 23:11 +0200, Ole wrote:

>  You can never predict the CWD of a process. <subdir>\netsurf.rsc could 
>  be
>  anything. And relative paths mostly means that OS has to translate

It's not as simple as that :) Yes, from the application's point of view
"<subdir>\\netsurf.rsc" depends on the application's current directory.
But it's not the application that is loading the resource file, it's the
AES. And unless you specify an absolute path, the AES will via shel_find
look in the directory the application was *started from*, not it's
current directory. So as long as the file exists, the AES will always
find "<subdir>\\netsurf.rsc".

>From xa_shel.c:

/*
 * search-strategy:
 *
 * 1. filename has an absolute path -> goto 6.
 *
 * 2. split path from filename -> filepath, filename
 *
 * 3. if usehome is true do wildcard-search for $HOME\[filepath
\]filename
 *
 * 4. do wildcard-search for client-home\[filepath\]filename
 *    client-home is the directory where the client was started from
 *
 * 5. if filename does not contain a path-component do a wildcard-search
for filename in $PATH
 *
 * 6. look for filename without any processing
 *
 * wildcard-search: case-insensitive, wildcards ? and * possible
(DOS-like pattern-matching)
 *
 */

>  it to an absolute path by using the CWD. (It would be better to use
>  the directory of the executable, but there is no way in ANSI C to read 
>  that
>  directory!)

As stated above, you don't need that. But if you want too, you can find
the path to the executable both in the basepage and in u:\kern\self
\cmdline.

>  the CWD is /usr/src/foobar and I bet 5 bucks that the AES fails to 
>  resolve
>  <subdir>\netsurf.rsc (because the CWD is /usr/src/foobar). But maybe it 
>  fails
>  because I used / instead of \.

See above. My PayPal account is joska@online.no :D

>  btw. do you see the path: /usr/src/ ?? this would translate
>  to <whateverdrive>/usr/src in the MiNT view on Filesystems,
>  which is an totally incorrect thing.
>  / must the the root of the unified filesystem. That's the only thing 
>  that makes sense.

What makes sense and not is very much in the eye of the beholder. What
you say is true for a unix-oriented person, but that doesn't apply for
most people.

But it's very easy. If you want to think "unix" on the Atari, use
MiNTlib. Just keep in mind that you're dealing with MiNTlib and not the
OS, so if you want to talk directly to the OS you must deal with the
situation. Prepend your unix path with "u:" before you pass it to the OS
and you're OK.

Jo Even