OSX Xboard 4.7.2 .app

[syzygy]

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.

Is that why the local settings are stored in a user-editable .xboardrc file stored in the home directory just like other .rc files, and which includes:

Code: Select all

; You can edit the values of options that are already set in this file,

Really, I don't care what you do with it, but arguing that the explanation in getpwuid's manual page is a reason not to follow the advice, is just silly. XBoard is not something special.

[hgm]

Editing settings files is neither necessary nor recommended anymore. The line you quote is not from the manual, but inside the file itself, and would never be displayed by XBoard. If people have managed to locate the file, and open it in an editor, so that they can see the line, the obviously will be able to edit it. So what the line says is not strictly false, despite the fact that you have taken it out of context, and the full text is mainly there to warn the user that adding any volatile options (i.e. not yet in the file) will be futile, as they would not survive.

I am not arguing out of stubbornness; I seriously think that the vast majority of users that would want to change HOME and use XBoard would be seriously unhappy with the result if I followed the getpwuid recommendation.

Digging up lines from somewhere in the settings file that are mainly there as legacy from Win(!)Board isn't really convincing. What would be much more compelling is if there was an official standard specifying that programs MUST store all their user-specific settings in HOME, or in some folder specified relative to HOME.

[syzygy]

If people have managed to locate the file, and open it in an editor, so that they can see the line, the obviously will be able to edit it.

It is trivial to locate the file, because xboard has always followed the UNIX convention to store its settings in ~/.xboardrc. This is the first place one would look for it. That xboard does not use $HOME but getpwuid() to locate the home directory is however not standard for typical UNIX user applications.

It seems xboard has been using getpwuid() since version 1.1 released in 1991, so I understand that you don't feel an urgent need to change it.

[hgm]

It seems xboard has been using getpwuid() since version 1.1 released in 1991, so I understand that you don't feel an urgent need to change it.

Did it, really?

I would have to check what it used it for, then! Until version 4.5.0 XBoard did not save any settings at all. Its options could be controlled through the .xresources file, however, but that bypassed its own code completely, and was all handled by the X-server. (And no saving of anything; it had to be edited.)

The ~ matter became an issue for me when I wanted to redirect saving of settings to a user-dependent place, so that each user would have his own settings file. So I specified -ini ~/.xboardrc in the master settings file /etc/xboard.conf, only to discover that the ~ was not understood at all as special, but was taken litterally, unless I added code to expand it.

[syzygy]

It seems xboard has been using getpwuid() since version 1.1 released in 1991, so I understand that you don't feel an urgent need to change it.

Did it, really?

Ah, it did, but for obtaining the user name, not the user's home directory:

Code: Select all

Version 1.1 -- Mon Jan  7 14:46:03 PST 1991
...
  * getlogin() does not work in all cases.
    It was replaced by getpwuid(getuid())->pw_name).

This is still being used. It should of course be replaced by getenv("USER")

[JoshPettus]

I believe the if def __apple__ does the trick. but when I tried to compile the new 4.7.3 branch I got:

Code: Select all

gtk/xboard.c: In function 'ManProc':
gtk/xboard.c:1789:5: error: too many arguments to function 'system'
     system("%s ./man.command", appData.sysOpen);
     ^
In file included from gtk/xboard.c:85:0:
/usr/include/stdlib.h:177:6: note: declared here
 int  system(const char *) __DARWIN_ALIAS_C(system);
      ^
make[2]: *** [gtk/xboard.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

also I'm a tad worried about how sysconf is defined
right now it just says

# define SYSCONFDIR "../etc"

if this were my app it would have to be ~~/../Resources/etc

unless this were a normal "make install", then it should be it should be in the system /usr/local/etc folder!
-------
Also in my package for man.command/info.command, we would have to do the same thing. It would have to be. ~~/../Resources/etc for both! But here is the thing. If we are going to include this code in the main source, then these files should be included in source as well. right now these files are located at that directory inside my app in-order to launch the info and man pages inside the app.
info.command:

Code: Select all

cd "${0%/*}"
info -d ../share/info -f xboard.info 

and man.command

Code: Select all

cd "${0%/*}"
man ../share/man/man6/xboard.6

to make them work in a normal "make install" situation, they would have to be put in the system /usr/local/etc folder.

[JoshPettus]

I say, for now with the make install, we go with the normal install, and i'll just use the app version in a patch. (until we can automate the app bundle making.) I dont want to break a normal build with this stuff!

--------

Another thing
The new ./configure stuff is wrong! If it's building on an actual 10.6 system, or earlier, then you don't want the -mmacosx-version-min and -isysroot stuff! the default is to compile against what is on the system it's compiling. That is only for targeting an earlier system with a later OS. in which case I had to build against the resources of that earlier system and not my current one.

The way it is written now is unnecessary and would break anyone compiling on 10.5 or something as there is no 10.6sdk.

[hgm]

I believe the if def __apple__ does the trick. but when I tried to compile the new 4.7.3 branch I got:

Code: Select all

gtk/xboard.c: In function 'ManProc':
gtk/xboard.c:1789:5: error: too many arguments to function 'system'
     system("%s ./man.command", appData.sysOpen);
     ^
In file included from gtk/xboard.c:85:0:
/usr/include/stdlib.h:177:6: note: declared here
 int  system(const char *) __DARWIN_ALIAS_C(system);
      ^
make[2]: *** [gtk/xboard.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

also I'm a tad worried about how sysconf is defined
right now it just says

# define SYSCONFDIR "../etc"

if this were my app it would have to be ~~/../Resources/etc

unless this were a normal "make install", then it should be it should be in the system /usr/local/etc folder!
-------
Also in my package for man.command/info.command, we would have to do the same thing. It would have to be. ~~/../Resources/etc for both! But here is the thing. If we are going to include this code in the main source, then these files should be included in source as well. right now these files are located at that directory inside my app in-order to launch the info and man pages inside the app.
info.command:

Code: Select all

cd "${0%/*}"
info -d ../share/info -f xboard.info 

and man.command

Code: Select all

cd "${0%/*}"
man ../share/man/man6/xboard.6

to make them work in a normal "make install" situation, they would have to be put in the system /usr/local/etc folder.

Oops, seemed I goofed. I added the appData.sysOpen argument assuming that this was an sprintf call, but it was system()...
The peoper procedure then becomes to use snprintf to print it in a buffer, and use the result in system():

Code: Select all

char buf[MSG_SIZ];
snprintf(buf, MSG_SIZ, "%s ./man.command", appData.sysOpen);
system(buf);

and it seems I simply forgot the "Resources" in the path.

In the Makefile.am it is possible to mention files from the source tree, and where they should be moved. (In symbolic form, because this could differ from distro to distro, but ./configure would take care of that by defining the symbols as needed.) Like is for instance done with all the SVG piece files.

So I will commit the launch scripts to git. The instructions to place them on make-install should be conditional, though, and only happen on OS X; I would need Arun to do that, as it exceeds my knowledge of the automake process.

[JoshPettus]

ok thanks!

[JoshPettus]

Darn shame I wasn't able to take a look at that sooner before Arun declared it stable..