OSX Xboard 4.7.2 .app

[syzygy]

char * homedir = getenv( "HOME");

Oh, I did not know that trick. Is that reliable?

I used:

Code: Select all

getpwuid(getuid())->pw_dir

Which is not terribly complicated either.

According to "man getpwuid":

Code: Select all

The pw_dir field contains the name of the initial working directory  of
the user.  Login programs use the value of this field to initialize the
HOME environment variable for the login  shell.   An  application  that
wants  to  determine its user's home directory should inspect the value
of HOME (rather than the value getpwuid(getuid())->pw_dir)  since  this
allows the user to modify their notion of "the home directory" during a
login session.  To determine the (initial) home  directory  of  another
user, it is necessary to use getpwnam("username")->pw_dir or similar.

[hgm]

From that I would say I'd better use getpwuid for exactly the reason they give not to use it. The user could mess with HOME, and there is no guarantee that the next time he runs XBoard it would have the same value.

[syzygy]

From that I would say I'd better use getpwuid for exactly the reason they give not to use it. The user could mess with HOME, and there is no guarantee that the next time he runs XBoard it would have the same value.

The manual page suggests to respect the user's explicit intention. I see no good reason for XBoard or any other program to ignore this intention.

[hgm]

Seems to me it is very questionable if the user changing HOME expresses the intention to break XBoard...

XBoard needs a fixed place writable by the user to work as intended. I settled on the user's login directory as the obvious choice. OK, so the symbol I used to denote this place (~) might not completely coincide with the meaning attached to it by bash. Perhaps it would have been better to call it % or @@@, and let ~ simply lead to a "not found" error if there wasn't a sub-directory "~" in the user's current directory. But who cares? It is only intended for use in the master settings file, which we distribute ourselves, to redirect saving and loading of persistent settings to some user-dependent (but not user-mood-dependent!) place.

Of course it might be nice to have XBoard also recognize filenames that start with $, and use getenv("XXX") to replace any $XXX, just as WinBoard currently does with %XXX%. But I doubt there is much application for it, even for $HOME/filename.

[hgm]

Currently all patches are under control of #ifdef OSX, but Arun suggested there might be a standard symbol like __OS_X__ that an OSX compiler might define (just like MSVC would define MSC_VER). If that is the case, it would be easier to change to that.

Could it be that

Code: Select all

#ifdef __APPLE__

does the trick?

Can you test that?

[syzygy]

Seems to me it is very questionable if the user changing HOME expresses the intention to break XBoard...

XBoard needs a fixed place writable by the user to work as intended.

Why should the user not be allowed to change this fixed place for whatever reason, for example to simulate a two-user environment on a system where he cannot create two user accounts. This would not break XBoard in any way.

Other programs do respect the user's intention. I wonder what you think makes XBoard so special that it must deviate.

[JoshPettus]

hgm wrote:
Currently all patches are under control of #ifdef OSX, but Arun suggested there might be a standard symbol like __OS_X__ that an OSX compiler might define (just like MSVC would define MSC_VER). If that is the case, it would be easier to change to that.


Could it be that
Code:
#ifdef __APPLE__

does the trick?

Can you test that?

I'd love too, but right now my laptop charger finally kicked the bucket. I ordered another one a week ago but it will be a couple of days I had hoped id be able to get by with this one till then, but luck wasn't on my side.

[hgm]

Why should the user not be allowed to change this fixed place for whatever reason, for example to simulate a two-user environment on a system where he cannot create two user accounts. This would not break XBoard in any way.

Every upside has a downside. Any time he would want to change HOME for another reason than the one you give, he would completely lose his settings, including all installed engines, and revert to the compiled-in default settings, which by now often are completely different from the way we configure XBoard. That would in practice make it impossible for him to alter HOME for any other purpose.

Other programs do respect the user's intention. I wonder what you think makes XBoard so special that it must deviate.

Perhaps XBoard is more dependent on stored settings than the typical program? And there are easy ways to simulate an XBoard with independent settings file, like "xboard -ini mysettings".

[syzygy]

Other programs do respect the user's intention. I wonder what you think makes XBoard so special that it must deviate.

Perhaps XBoard is more dependent on stored settings than the typical program?

That seems extremely unlikely.

Even vim simply looks in $HOME for its settings.

If the user changes $HOME, it is because he WANTS his programs to look in that place. I find it quite astonishing that one could sincerely believe that the quoted advice from the manual page of getpwuid does not apply to one particular user program.

[hgm]

Well, perhaps vim isn't as crippled as XBoard when it cannot find its settings.

XBoard has manual pages too. I consider what these say more important than what some man page of a library function says. The manual promises persistence of settings. It does NOT promise that the settings are stored in any particular place, and does in no way suggest that it could be subject to sneaky tricks to subvert the persistence mechanism. As far as the user is concerned XBoard could very well have been a SUID program that stored the settings in /usr/share/games/xboard/settings/UID.ini. In which case redefining HOME would not be expected to have any effect.