From: groepaz (groepaz_at_gmx.net)
Date: 2001-12-12 16:12:23
Hello Marko, MM> POSIX defines chdir(const char* path) and fchdir(int fd), but in Unix, MM> there's no system call or even a library call for determining the current MM> working directory. As far as I know, the pwd(3) program guesses the MM> current working directory by following the "../../.." chain and doing MM> something like opendir/readdir/stat to find out a matching subdirectory of MM> the ".." directory, and to find out when ".." is the same as "." (in the MM> root directory, it is). BTW, at least on Sun Solaris 7, the pwd(3) MM> program fails if one of the parent directories doesn't have read MM> permissions. sounds odd to me ;=D unix fails to do something right that ms-dos can do perfectly fine ??? => shame :o) >> - well except a "collapsepath" functionality would be needed for >> "OSes" like ms-dos... MM> Potentially, the maximum path name length can be a problem on any system MM> when you have very long directory hierarchies. well yeah... practically the only one where you really run into trouble would be ms-dos though ;=) unix-pathes should be long enough for most stuff ;=) MM> I guess you're referring MM> to removing "./" or "somedir/.." parts from the path names. no not exactly.... i was referring to a function that 'simplifies' complex path specs, eg convert lib/beta/1/../../../include/../bin/ (nonsence? *G*) to bin/ MM> Or writing "doctor files" (PhD thesis). :-) eeeks, i knew why i quit studying ,=) haha MM> To get back on the topic, I agree with Ullrich and would rather keep MM> platform-specific stuff out of the compiler. There are tools like GNU MM> autoconf and automake that allow the creation of "portable Makefiles". MM> Maybe you should have a look at them. Perhaps you don't want to use these MM> tools as such, but you could get some ideas. The source files (in a broad MM> sense; including C files and Makefiles) do not need to be exactly MM> identical on all platform; the main thing is that you can eliminate the MM> need for manually editing them. yeah, just autoconf and friends would be another tools to learn and fight with for some weeks until i get it right.... dont like that idea to be honest ;=P MM> Also, you could perhaps use a set of platform-specific Makefiles, like MM> Makefile.`uname` where `uname` is replaced by Linux, OSF1, SunOS, etc. MM> These files would include a common Makefile that'd contain the MM> platform-independent rules. I used this approach for a large C++ program MM> I've written. (GNU autoconf and automake ease the porting of C programs MM> to various compilers, but for C++ there are very few compilers that would MM> compile the code. I've only found two.) i use different makefiles for that matter already... well however :o) -- Best regards, groepaz mailto:groepaz_at_gmx.net ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:44 CET