r11 has still problems handling xfs listen port. the check_config() in xfs.start is happy if XFS_PORT is not zero-length-string but even if "-1" is a valid 2char string(so good for check_config()) it is not valid as xfs -port parameter value. xfs will ignore -port if "no-listen = tcp" is specified but it will issue an error if that config flag is not set. btw i don't think that it's a good idea to duplicate the "port" config option in conf.d because, i think, it doesn't help in any way and adds another config file to the overcrowded X11 config file list. what if we wont to change the UID of xfs server? should we add another variable in conf.d? the less config file we have the better it is :) last note about xfs.start: with large passwd files the [ "`grep xfs /etc/passwd`" ] could be wrong quite easily. for example if someone is called...don't know..."axfsee" or lives in "exfs" street (not so usual:), so maybe [ "`grep \"^xfs:\" /etc/passwd`" ] will be more safe. my 2c stefano p.s. is there a way to reopen a bug without creating a new one? :)
This XFS port thing is starting to get old. What exactly is the problem with "-port -1" as arguments to xfs ? It is the same thing as the "no-listen = tcp" option in /etc/X11/fs/config. It has been working here since XFree86 4.0 came out and I was still using redhat/mandrake ... it still works here now. I still dont know why it was changed in the first place, but just wanted to get some sanity to it in -r11. Secondly, the comment in /etc/conf.d/xfs is there to remind the user that he should comment "no-listen = tcp". If he do not take heed, it is not the fault of the script that "-port" will be ignored. Thirdly, check_config() is not supposed to do sanity checking. It is just a loose check to see if $XFS_PORT is set or not, not if it contains the correct port. It is up to the user to use his brains and set it to something valid. Lastly, good call about the user "xfs" check in /etc/passwd, that will get changed.
