Start script changes

["Phil Betts" <Phil dot Betts at heis dot co dot uk>]

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
**********************************************************************