Harold, Since /usr/X11R6 is apparently "an abomination", you'll have no qualms about moving run.exe into /usr/bin (alias /bin), right? ;-)
You can say yes now and skip to the last two paragraphs, it's mostly justification for the change. However, if you need more convincing... I've got a startxwin.bat that makes the same assumption about the location of /bin as cygwin.bat i.e. it (more or less) tries to do the following: C: chdir \cygwin\bin set CYGWIN="tty" bash -lc /usr/X11R6/bin/startxwin.sh This works. If I run this from a shortcut, I can make it start minimised so that the DOS box is hidden, but I'd prefer to get rid of it entirely once X has started. The problem is that, even though startxwin.sh runs xterm as a background process and then bash exits, the DOS box doesn't close until the last client (i.e. xterm) has died. One solution is: insist that ALL background processes be started using run.exe rather than just putting them in the background. I've rejected this because it is unreasonable to force shell script writers to be aware of the foibles of DOS - we want to leave behind all DOS baggage in the .bat file :-) Another solution: use run.exe to start bash. I don't think we can assume ANY of the cygwin directories are in %PATH%, so the bash line becomes: C:\cygwin\usr\X11R6\bin\run.exe bash -lc /usr/X11R6/bin/startxwin.sh This is useless for me, because /usr is on my D: drive and as one of the prime motivations for making the change is to make the scripts more universal, this too has to be rejected. If instead, we chdir to the (DOS) location of /usr/X11R6/bin, e.g. in my case D:\cygwin\usr\X11R6\bin, we can't guarantee that bash will start OK (it won't find cygwin1.dll for starters). Therefore, the cleanest solution would be to move run.exe to /usr/bin. Then, the startxwin.bat can just: run bash -lc /usr/X11R6/bin/startxwin.sh Any shortcut to run the .bat file just needs the target to be the batch file itself, there's no need to be careful about setting its starting directory. It could hardly be simpler. In case you're wondering, startxdmcp.bat is virtually the same except it sets REMOTE_HOST then runs bash as: run bash -lc /usr/X11R6/bin/startxwin.sh -xdmcp %REMOTE_HOST% The XDMCP specific bits in startxdmcp.bat have migrated into startxwin.sh. If you're OK with run.exe moving into /usr/bin, I should be able to get a patch out tomorrow. It might be worth pointing out that with run.exe in /bin, the batch files are pretty redundant. I've got a shortcut with a target of: C:\cygwin\bin\run.exe bash -lc /usr/X11R6/bin/startxwin.sh which runs fine so long as "Start in:" is "C:\cygwin\bin". Perhaps you could clarify: if run.exe moves to /usr/bin, should this be referred to (in the xxx.in files) as "/usr/bin", "/bin" or "@some_autoconf_macro@"? @prefix@ appears to be /usr/X11R6, and the other autoconf directories seem to be derived from this e.g. @exec_prefix@ and @bindir@, so none of them seem to be applicable. Longer term, wouldn't it make more sense to persuade Charles Wilson (the cygutils maintainer) to adopt run.exe as an addition to the cygutils family? There is nothing X about it after all, and it would also make it available to other folk that aren't interested in X (there must be some out there ;-). It may need a name change to cygrun, but that's not going to hurt. Phil ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **********************************************************************
