That sounds like a great idea – I synchronize my xboard dotfiles and themes across several machines and distributions and so this was a bit of a pain point for me. This solution should allow scripts to solve this problem quite nicely.
Thanks, h.g. muller! Will this be in the next dev release? Cheers, Adrian On Sun, Jan 12, 2014 at 12:20 PM, <[email protected]> wrote: > I just thought of a nice XBoard feature: > > I defined a special string option -do "COMMAND", which is only recognized > as a first option, similar to --version and --help, which immediately quit > XBoard. What it does is expand a "%s" occurring in "COMMAND" to the path > name of the directory where it stores its data files (e.g. > /usr/local/share/games/xboard), and then offers it to the shell for > execution through system("EXPANDEDCOMMAND");. > > E.g. if you would write > > xboard -do "echo %s" > > it would print the path to its data directory. > > This can be used in install scripts of 'support packages' for XBoard, such > as theme packages with SVG pieces or board textures, to figure out where > they would have to copy the data files they contain. The make-install > could contain commands > > xboard -do "cp *.svg %s/themes/xiangqi" > xboard -do "cp xq.xop %s/themes/conf" > xboard -do "cp xqboard.png %s/themes/textures" > > and XBoard itself would be used to figure out where to copy the files to. > You would not have to worry whether the active XBoard would use > /usr/share/games/xboard or /usr/local/share/games/xboard, or whatever was > usual in the applicable Linux distro. Invoking xboard as a command would > always give you the active XBoard, and it would know. > > >
