forums.ps2dev.org

[Alberto]

Hi all,

sorry to ask maybe a stupid question, but I'm dealing with paths and filenames, and would like to know if there si a function for expanding a relative path to an absolute one.
I'm "pretty" new to the "C" language, and after having find'd grep'd the pspdsk and the internet with my friend google, I haven't came across anything...

Something like the Borland Pascal FExpand, that for "./currentfolder/../common/fonts" should return "ms0:/PSP/GAME/MYSW/common/fonts", provided the current working directory was "ms0:/PSP/GAME/MYSW".

Thank you for any tips, I would like to avoid writing one from scrap... ;-)

Cheers, A.

[m0skit0]

I don't know if there's a function that returns the current working directory path (like pwd on *IX systems), but your application should just keep track of the current directory, it's easier and cleaner.
_________________

[Zer01ne]

[Alberto]

Thank you both for the answer.
actually, I don't need to change the directory, so sceIoChdir has no use for me.
Finally I ended up writing a function from scratch; it _does_ know the base folder to use in case of relative paths (the running folder I can get from argv[0], and that would eventually change, shall I adopt any Chdir...), and returns a fully qualified absolute path, from the "ms0:/" and on.

First, I split the path in its components and fill a list with them (adds a little overhead, but at the end is a lot easier to use). Then I just remove the ".." entries together with the previous one. The "." entries are just removed.
Finally I just repack the path.

In the graphical "open file dialog" I made, if I reach a root, where ".." isn't there, I just add it to the "list", and when applying it to a root, I just clean and fill the list only with devices like "ms0:/", "host0:/" etc.

Works good for what are my needs.
It took me a day, but a good 50% was for the graphical part, icons, etc.

Cheers, A.

[jsharrad]

If you're using newlib you can just getCwd(); if not then yeah getting it from argv[0] is what I do too.

[jimparis]

Use realpath:

[Alberto]

[carl0sgs]

I think this is what you need:

[Coldbird]

I just wanna note that relying on argv[0] for boot path checks isn't a clever idea as the OFW isn't providing anything of the sort when loading modules (the argument isnt given!).

So if you rely on argv[0] to get your path you will run into trouble if you run your module from flash0 using pspbtcnf loading lists...

If you only intend to run your modules on "sane areas" - like cfw ms0 loaders (game.txt, etc...) or using your own prx loader that provides argv[0] for you then its fine though.

But I must admit I'm doing it the same way, grabbing from argv[0] whenever possible.

I'm sure though there just has to be a function to grab the cwd natively built into the PSP firmware... probably somewhere in sascore or something...
_________________
Been gone for some time. Now I'm back. Someone mind getting me up-2-date?

[TyRaNiD]

There is sceIoGetThreadCwd but annoyingly it is kernel mode only from what I remember. This is why the C library maintains its own copy based on argv[0] but as that doesn't have to match where the file really comes from it isn't ideal.

[Torch]

I thought even official games used hardcoded paths for custom memory stick data?

[carl0sgs]

[jimparis]

[Alberto]

[jimparis]

It's there... maybe you have an old newlib or you're using psplibc or something. try:

[Alberto]

[jimparis]

Nope, don't USE_PSPSDK_LIBC. Your grep shows that realpath is defined in libc, so either you're compiling against the wrong libc or something else. Post the full output of your compilation, maybe we can see what's wrong.

[Alberto]

Ok,

let me arrange a smaller app that gives me the errors and I'll post everything later on, today.

Thanks for the support,
A.

[Alberto]

here's the compilation log (hope it's what you asked)

[jimparis]

Oh, you said C, not C++.
Wrap the prototype:

[Alberto]

[Alberto]

ok, as I said, it works... but...

is it correct, that if I try to explode a path that doesn't exist, it returns NULL?
I see in the man pages that it's buggy, so does this behavior fall into the word "buggy"?
If it _is_ so, I think I'll stuck with my implementation; maybe extend it a little to comply properly with chdir, and that's it. ;-)

Anyway, thanks again for getting it to compile and link.


Cheers, A.

[jimparis]

Yes, it needs to exist -- just like any implementation of realpath. I don't know what you mean by "buggy", but returning NULL and errno=ENOENT, ENOTDIR, etc is normal behavior when files or dirs don't exist.

If that's not what you want, you can try using the low-level and nonstandard __psp_path_absolute function from newlib.

[Alberto]

Hi,

sorry, I meant "broken by desing"... but haven't read to the end the manpage. It's "broken" for it's impossible to determine a suitable size for the output buffer, not for the behavior.

TTYTT, I can write C ot C++ code -more or less- easily; what I don't know is the complete library functions... I'm still at the beginning :-(
Most of the times I search the man pages and succeed in finding suitable things; but this time had no clue of realpath (and anyway I would have still hit the missing export thing...)

So I don't discuss what the function does or does not, but it doesn't do what I was expecting it to. I come mainly from Borland's Pascal and Delphi (on Windows envs.), and there, the functions FExpand and ExpandFilePath do exactly what I want: just resolve the "." and "..", shrink any non-leading "//", and add the cwd in front of paths not beginning with the drive; no matter whether the path actually exists or not.

Nevermind, if you like I can post my implementation, you can have a look at it, and just say what is good and what not... that could be of great help for me ;-)

Cheers, A.

[jimparis]

[Alberto]

[carl0sgs]

I don't see why can't you use getcwd.

[Alberto]

[carl0sgs]

[Alberto]

Hi there,