Bug in startxwin.bat after installing with setup.exe in win98SE

[Harold L Hunt]

First: Wrong mailing list. Send all Cygwin/XFree86 questions to
cygwin-***@cygwin.com. I have redirected this discussion to the correct
mailing list, but be careful to remove ***@cygwin.com from the ``cc'' if
you reply to this message.

Second: Read the extensive comments in startxwin.bat that talk about
CYGWIN_ROOT. Not specifying a drive causes the path to reference \cygwin on
the current drive (such as c:\cygwin, or d:\cygwin). You have to run
startxwin.bat from the same drive that Cygwin is installed on, or it won't get
the correct drive letter.

startxwin.bat has been using this path setting system for over a year (I
think) and not a *single* person has reported a problem with it until today.
You must be doing something on your system that other users thought better of
(such as running startxwin.bat from the d drive, or from a network drive, when
Cygwin is installed on the c drive).

Harold

i installed cygwin/XFree86 with the recommended
setup.exe in win98SE.
starting X with startxwin.bat resulted in
errormessages like "cygwin1.dll not found" etc.
in startxwin.bat there was a line "SET
CYGWIN_ROOT=\cygwin" which seemed to be incorrect
because theres no drive given.
after editing it to "SET CYGWIN_ROOT=c:\cygwin"
(installation path) everything works fine.
i installed it on a win2000 too without these problems
but on an other win98-system same corrupted
startxwin.bat was there.
i have not tried an other installation directory or
drive.
this message is only for information; i need no other
solution.
Michael Heide
__________________________________________________________________
Gesendet von Yahoo! Mail - http://mail.yahoo.de
Yahoo! pr�sentiert als offizieller Sponsor das Fu�ball-Highlight des
Jahres: - http://www.FIFAworldcup.com
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

[Bernard A Badger]

-----Original Message-----
Of Harold L Hunt
Sent: Friday, July 12, 2002 10:27 AM
Subject: Re: Bug in startxwin.bat after installing with setup.exe in
win98SE
First: Wrong mailing list. Send all Cygwin/XFree86 questions to
you reply to this message.
Second: Read the extensive comments in startxwin.bat that talk about
CYGWIN_ROOT. Not specifying a drive causes the path to reference \cygwin on
the current drive (such as c:\cygwin, or d:\cygwin). You have to run
startxwin.bat from the same drive that Cygwin is installed on, or it won't get
the correct drive letter.
startxwin.bat has been using this path setting system for over a year (I
think) and not a *single* person has reported a problem with it until today.
You must be doing something on your system that other users thought better of
(such as running startxwin.bat from the d drive, or from a network drive, when
Cygwin is installed on the c drive).

I have to disagree. Absence of complaints does not imply absence of errors.
Many people become "used to" buggy software that only works if you don't deviate
from the well-trodden path. That's no excuse to fail to fix a known problem.

The comments you mention:
REM
REM The path in the CYGWIN_ROOT environment variable assignment assume
REM that Cygwin is installed in a directory called 'cygwin' in the root
REM directory of the current drive. You will only need to modify
REM CYGWIN_ROOT if you have installed Cygwin in another directory. For
REM example, if you installed Cygwin in \foo\bar\baz\cygwin, you will need
REM to change \cygwin to \foo\bar\baz\cygwin.
REM
REM This batch file will almost always be run from the same drive (and
REM directory) as the drive that contains Cygwin/XFree86, therefore you will
REM not need to add a drive letter to CYGWIN_ROOT. For example, you do
REM not need to change \cygwin to c:\cygwin if you are running this
REM batch file from the C drive.
REM
don't explain what is wrong with adding a drive lettter, only that
it "almost always" works because the drive letter already matches.

You need the drive letter to make an absolute path.
(By the way, "." is redundant in a Windows path anyway.)

Harold

i installed cygwin/XFree86 with the recommended
setup.exe in win98SE.
starting X with startxwin.bat resulted in
errormessages like "cygwin1.dll not found" etc.
in startxwin.bat there was a line "SET
CYGWIN_ROOT=\cygwin" which seemed to be incorrect
because theres no drive given.
after editing it to "SET CYGWIN_ROOT=c:\cygwin"
(installation path) everything works fine.
i installed it on a win2000 too without these problems
but on an other win98-system same corrupted
startxwin.bat was there.
i have not tried an other installation directory or
drive.
this message is only for information; i need no other
solution.
Michael Heide
__________________________________________________________________
Gesendet von Yahoo! Mail - http://mail.yahoo.de
Yahoo! pr�sentiert als offizieller Sponsor das Fu�ball-Highlight des
Jahres: - http://www.FIFAworldcup.com
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

[Harold L Hunt]

Bernard,

Post by Bernard A Badger
I have to disagree. Absence of complaints does not imply absence of errors.
Many people become "used to" buggy software that only works if you don't deviate
from the well-trodden path.

Okay, if you are so smart, explain to me how I can put a drive letter into a
batch file that is expected to work on computers where Cygwin could be
installed on ``c:\cygwin'' or ``d:\cygwin''? I certainly could not put ``c''
as the drive, nor could I put ``d'' as the drive. So, what do you suggest?

Okay, okay, so you are thinking, ``just use cygpath, duh''. However, if I
could use ``cygpath'', then that implies that I already know where the Cygwin
binaries are located since I just ran one of them. But, I don't know where
the Cygwin binaries are located, as that is why we are guessing what the path is.

Post by Bernard A Badger
That's no excuse to fail to fix a known problem.

Huh? There are things in life that are worth spending time on because they
will have a large effect, and there are things in life that are not worth
spending time on because they will have almost no effect whatsoever. Changing
the startxwin.bat file to allow people to run it from a location other than
where it is installed to (which has got to be obvious to most users as doing
something that was not intended), is one of those things that will have almost
no effect. You are going to have to do a lot better than that if you expect
me to keep my gleaming white ass in a dimly lit room programming when I could
be sitting outside by the pool, getting a tan, and drinking a beer.

Man, if you are going to try to one-up the maintainer in public, you had damn
well better be giving a complete solution, rather than trying to suggest that
the maintainer creates one himself. Because in the latter case you just open
yourself up to off-topic ranting like I just did. Yes, this makes me feel
better when I get to write funny things about how I don't like to program.
So, in a way, you have done me a good service. Thank you :)

Harold

Post by Bernard A Badger

-----Original Message-----
Of Harold L Hunt
Sent: Friday, July 12, 2002 10:27 AM
Subject: Re: Bug in startxwin.bat after installing with setup.exe in
win98SE
First: Wrong mailing list. Send all Cygwin/XFree86 questions to
you reply to this message.
Second: Read the extensive comments in startxwin.bat that talk about
CYGWIN_ROOT. Not specifying a drive causes the path to reference \cygwin on
the current drive (such as c:\cygwin, or d:\cygwin). You have to run
startxwin.bat from the same drive that Cygwin is installed on, or it won't get
the correct drive letter.
startxwin.bat has been using this path setting system for over a year (I
think) and not a *single* person has reported a problem with it until today.
You must be doing something on your system that other users thought better of
(such as running startxwin.bat from the d drive, or from a network drive, when
Cygwin is installed on the c drive).

I have to disagree. Absence of complaints does not imply absence of errors.
Many people become "used to" buggy software that only works if you don't deviate
from the well-trodden path. That's no excuse to fail to fix a known problem.
REM
REM The path in the CYGWIN_ROOT environment variable assignment assume
REM that Cygwin is installed in a directory called 'cygwin' in the root
REM directory of the current drive. You will only need to modify
REM CYGWIN_ROOT if you have installed Cygwin in another directory. For
REM example, if you installed Cygwin in \foo\bar\baz\cygwin, you will need
REM to change \cygwin to \foo\bar\baz\cygwin.
REM
REM This batch file will almost always be run from the same drive (and
REM directory) as the drive that contains Cygwin/XFree86, therefore you will
REM not need to add a drive letter to CYGWIN_ROOT. For example, you do
REM not need to change \cygwin to c:\cygwin if you are running this
REM batch file from the C drive.
REM
don't explain what is wrong with adding a drive lettter, only that
it "almost always" works because the drive letter already matches.
You need the drive letter to make an absolute path.
(By the way, "." is redundant in a Windows path anyway.)

Harold

i installed cygwin/XFree86 with the recommended
setup.exe in win98SE.
starting X with startxwin.bat resulted in
errormessages like "cygwin1.dll not found" etc.
in startxwin.bat there was a line "SET
CYGWIN_ROOT=\cygwin" which seemed to be incorrect
because theres no drive given.
after editing it to "SET CYGWIN_ROOT=c:\cygwin"
(installation path) everything works fine.
i installed it on a win2000 too without these problems
but on an other win98-system same corrupted
startxwin.bat was there.
i have not tried an other installation directory or
drive.
this message is only for information; i need no other
solution.
Michael Heide

[Jehan]

Post by Harold L Hunt
Okay, if you are so smart, explain to me how I can put a drive letter into a
batch file that is expected to work on computers where Cygwin could be
installed on ``c:\cygwin'' or ``d:\cygwin''? I certainly could not put ``c''
as the drive, nor could I put ``d'' as the drive. So, what do you suggest?

First, I'm not trying to bash you (how could I, we are fellow
Cgwin/XFree programmers *grin*) but I'm trying to understand your
motivation. So here is my question: in what sense is "\cygwin" better
"c:\cygwin"? I mean, I used to install cygwin in "c:\program
files\cygwin". So neither "\cygwin" nor "c:\cygwin" would work. But
then, when I see just "\cygwin", I think a unix path (I know, the "\"
isn't a "/", but I'm a little dumb sometimes :p). So at first, I
overlooked it. I'm pretty sure that if I had seend "c:\cygwin", I would
have thought of changing it.
The other thing too is that "\cygwin" is sort of a bastard. It's not a
full path because it doesn't have the drive letter. It's not a relative
path because it doesn't start from the current directory but from the
root of the current drive.
Last, with "\cygwin", the batch file works sometimes (the current drive
is where cygwin is) and sometimes it doesn't (wrong current drive). As a
programmer, I prefer things that always crash or never do.
So, in this light, as my personal opinion (which doesn't matter anymore
now that I have cygwin in "c:\cygwin" ;p ), would be to use an full
absolute path.

Post by Harold L Hunt
Okay, okay, so you are thinking, ``just use cygpath, duh''. However, if I
could use ``cygpath'', then that implies that I already know where the Cygwin
binaries are located since I just ran one of them. But, I don't know where
the Cygwin binaries are located, as that is why we are guessing what the path is.

Can the batch file be created via the installation script? Then you're
environment would be cygwin and not windows, wouldn't it? The thing I
don't know there would be the "cr/lf" vs "lf" thing.

Post by Harold L Hunt

Post by Bernard A Badger
That's no excuse to fail to fix a known problem.

Bernard,
And "not having a better solution", is it a good excuse? It's always
easy to critize but critizing doesn't make the world to go forward.

Post by Harold L Hunt
Huh? There are things in life that are worth spending time on because they
will have a large effect, and there are things in life that are not worth
spending time on because they will have almost no effect whatsoever. Changing
the startxwin.bat file to allow people to run it from a location other than
where it is installed to (which has got to be obvious to most users as doing
something that was not intended), is one of those things that will have almost
no effect. You are going to have to do a lot better than that if you expect
me to keep my gleaming white ass in a dimly lit room programming when I could
be sitting outside by the pool, getting a tan, and drinking a beer.
Man, if you are going to try to one-up the maintainer in public, you had damn
well better be giving a complete solution, rather than trying to suggest that
the maintainer creates one himself. Because in the latter case you just open
yourself up to off-topic ranting like I just did. Yes, this makes me feel
better when I get to write funny things about how I don't like to program.
So, in a way, you have done me a good service. Thank you :)

Go harold, go!! Kill him :). You know what is better than "sitting
outside by the pool, getting a tan, and drinking a beer"? It sitting
outside by the pool, getting a tan, drinking a beer and watching a fight
game! :)

Jehan

[Harold L Hunt]

Post by Jehan

Post by Harold L Hunt
Okay, if you are so smart, explain to me how I can put a drive letter into a
batch file that is expected to work on computers where Cygwin could be
installed on ``c:\cygwin'' or ``d:\cygwin''? I certainly could not put ``c''
as the drive, nor could I put ``d'' as the drive. So, what do you suggest?

First, I'm not trying to bash you (how could I, we are fellow
Cgwin/XFree programmers *grin*) but I'm trying to understand your
motivation. So here is my question: in what sense is "\cygwin" better
"c:\cygwin"? I mean, I used to install cygwin in "c:\program
files\cygwin". So neither "\cygwin" nor "c:\cygwin" would work. But
then, when I see just "\cygwin", I think a unix path (I know, the "\"
isn't a "/", but I'm a little dumb sometimes :p). So at first, I
overlooked it. I'm pretty sure that if I had seend "c:\cygwin", I would
have thought of changing it.
The other thing too is that "\cygwin" is sort of a bastard. It's not a
full path because it doesn't have the drive letter. It's not a relative
path because it doesn't start from the current directory but from the
root of the current drive.
Last, with "\cygwin", the batch file works sometimes (the current drive
is where cygwin is) and sometimes it doesn't (wrong current drive). As a
programmer, I prefer things that always crash or never do.
So, in this light, as my personal opinion (which doesn't matter anymore
now that I have cygwin in "c:\cygwin" ;p ), would be to use an full
absolute path.

Unfortunately you cannot use a relative path (e.g. ..\..\.., which gets \bin
appended on it to point to /bin) because that causes bash (or whatever shell
you launch in xterm) to have a relative path the Cygwin binaries. Thus you
can no longer run Cygwin binaries if you change out of the /usr/X11R6/bin
directory, because your relative path to the Cygwin binaries is now incorrect.

So, we have to use an absolute path, which is why why need something like
c:\cygwin. We go one further an change this to \cygwin because we used to get
weekly complaints like, ``yikes, cygwin1.dll could not be found, cause i am
l33t and i installed to d:\cygwin''. We do not get regular complaints
anymore, so \cygwin is an improvement over c:\cygwin.

Now, about not being able to see things that you are looking for in a file: I
wrote two paragraphs! of comments about setting the path correctly, and in
those comments there does appear a c:\cygwin. I cannot help someone if they
are skimming so fast as to completely miss all of that.

I will admit one current problem with startxwin.bat: the User's Guide is out
of date so we do not recommend that new users read it to install
Cygwin/XFree86. Unfortunately this means that people do not see, repeatedly,
my recommendations that they install Cygwin in c:\cygwin that are in the
User's Guide.

One idea is that we could try to parse the return from ``chdir'', which gives,
for example:
C:\cygwin\usr\X11R6\bin>chdir
C:\cygwin\usr\X11R6\bin


It would be pretty easy to construct a location for /bin or /usr/bin from the
output of chdir, but then we are back to the Catch-22 that we would need
Cygwin binaries in order to find the location of the Cygwin binaries.

Post by Jehan

Post by Harold L Hunt
Okay, okay, so you are thinking, ``just use cygpath, duh''. However, if I
could use ``cygpath'', then that implies that I already know where the Cygwin
binaries are located since I just ran one of them. But, I don't know where
the Cygwin binaries are located, as that is why we are guessing what the

path is.

Post by Jehan
Can the batch file be created via the installation script? Then you're
environment would be cygwin and not windows, wouldn't it? The thing I
don't know there would be the "cr/lf" vs "lf" thing.

Post by Harold L Hunt

Post by Bernard A Badger
That's no excuse to fail to fix a known problem.

Bernard,
And "not having a better solution", is it a good excuse? It's always
easy to critize but critizing doesn't make the world to go forward.

Post by Harold L Hunt
Huh? There are things in life that are worth spending time on because they
will have a large effect, and there are things in life that are not worth
spending time on because they will have almost no effect whatsoever. Changing
the startxwin.bat file to allow people to run it from a location other than
where it is installed to (which has got to be obvious to most users as doing
something that was not intended), is one of those things that will have almost
no effect. You are going to have to do a lot better than that if you expect
me to keep my gleaming white ass in a dimly lit room programming when I could
be sitting outside by the pool, getting a tan, and drinking a beer.
Man, if you are going to try to one-up the maintainer in public, you had damn
well better be giving a complete solution, rather than trying to suggest that
the maintainer creates one himself. Because in the latter case you just open
yourself up to off-topic ranting like I just did. Yes, this makes me feel
better when I get to write funny things about how I don't like to program.
So, in a way, you have done me a good service. Thank you :)

Go harold, go!! Kill him :). You know what is better than "sitting
outside by the pool, getting a tan, and drinking a beer"? It sitting
outside by the pool, getting a tan, drinking a beer and watching a fight
game! :)
Jehan

Heh heh... What is a ``fight game''? Are you referring to boxing?

Harold

[Jehan]

Post by Harold L Hunt
Unfortunately you cannot use a relative path (e.g. ..\..\.., which gets \bin
appended on it to point to /bin) because that causes bash (or whatever shell
you launch in xterm) to have a relative path the Cygwin binaries. Thus you
can no longer run Cygwin binaries if you change out of the /usr/X11R6/bin
directory, because your relative path to the Cygwin binaries is now incorrect.

I was not suggesting to use relative paths. They are even worse than the
current solution since the current solution only assumes that we are in
the good drive while relative path would assumes we also in the good
directory. It was just to justify why I think the current system is a
bastard path. Neither absolute nor relative.

Post by Harold L Hunt
So, we have to use an absolute path, which is why why need something like
c:\cygwin. We go one further an change this to \cygwin because we used to get
weekly complaints like, ``yikes, cygwin1.dll could not be found, cause i am
l33t and i installed to d:\cygwin''. We do not get regular complaints
anymore, so \cygwin is an improvement over c:\cygwin.

I'm too new to the mailing list, I wasn't their at that time. But I'm
suprise by this error message. Because this error means than XWin.exe
has been found (or whatever other cygwin executable). And if it has
been, then cygwin1.dll path is known since there is no way to install
individual package in individual directories (none that I know of at least).

Post by Harold L Hunt
Now, about not being able to see things that you are looking for in a file: I
wrote two paragraphs! of comments about setting the path correctly, and in
those comments there does appear a c:\cygwin. I cannot help someone if they
are skimming so fast as to completely miss all of that.

RTFM. :). I read it eventually, it just didn't come immediatly because I
was looking for an absolute path first.

Post by Harold L Hunt

Post by Jehan
Can the batch file be created via the installation script? Then you're
environment would be cygwin and not windows, wouldn't it? The thing I
don't know there would be the "cr/lf" vs "lf" thing.

You didn't comment on this potential solution. I'm not familiar with
setup.exe (at least less than you). Is there an obvious reason why this
wouldn't work? If not, and if I don't work too late today, I may look at
it. Ignoring potential newline issues, it seems as simple as:

cat << EOF > /usr/X11R6/bin/startxwin.bat
#blablabla beginning of the batch file
EOF
echo SET CYGWIN_ROOT=\"`cygpath -w /`\" >> /usr/X11R6/bin/startxwin.bat
cat << EOF >> /usr/X11R6/bin/startxwin.bat
#blablabla end of batch file
EOF

Post by Harold L Hunt

Post by Jehan
Go harold, go!! Kill him :). You know what is better than "sitting
outside by the pool, getting a tan, and drinking a beer"? It sitting
outside by the pool, getting a tan, drinking a beer and watching a fight
game! :)

Heh heh... What is a ``fight game''? Are you referring to boxing?

Anything with a little violence in it. Not the WWF thing, it feels too
fake to be relaxing. Playing to some quake like games is good too. :)

Jehan

[Robert Collins]

-----Original Message-----
Sent: Saturday, 13 July 2002 6:38 AM
Subject: Re: Bug in startxwin.bat after installing with
setup.exe in win98SE

Post by Harold L Hunt
Okay, if you are so smart, explain to me how I can put a

drive letter into a

Post by Harold L Hunt
batch file that is expected to work on computers where

Cygwin could be

Post by Harold L Hunt
installed on ``c:\cygwin'' or ``d:\cygwin''? I certainly

could not put ``c''

Post by Harold L Hunt
as the drive, nor could I put ``d'' as the drive. So,

what do you suggest?

I missed this the first time around.

What you need is a small sed script in your postinstall script. The sed
script can replace some symbol with the output from 'cygpath -w
/usr/X11/....'.

As for linefeed issues, AFAIK windows will process bat files with unix
format, but you could always use d2u in your script.

Additionally you need to make your package depend on the tools you use
in your script.

Rob

[Jehan]

Post by Robert Collins
I missed this the first time around.
What you need is a small sed script in your postinstall script. The sed
script can replace some symbol with the output from 'cygpath -w
/usr/X11/....'.
As for linefeed issues, AFAIK windows will process bat files with unix
format, but you could always use d2u in your script.
Additionally you need to make your package depend on the tools you use
in your script.

Too late ;)
http://cygwin.com/ml/cygwin-xfree/2002-07/msg00318.html

but thanks anyway
Jehan

[Christopher Faylor]

Post by Robert Collins
As for linefeed issues, AFAIK windows will process bat files with unix
format, but you could always use d2u in your script.

I don't think Windows 9x systems will understand bat files with unix
line endings.

cgf
(boy what a strange thread this has been)

[Robert Collins]

-----Original Message-----
Sent: Sunday, 14 July 2002 2:31 PM
Subject: Re: Bug in startxwin.bat after installing with
setup.exe in win98SE

Post by Robert Collins
As for linefeed issues, AFAIK windows will process bat files

with unix

Post by Robert Collins
format, but you could always use d2u in your script.

I don't think Windows 9x systems will understand bat files with unix
line endings.

Right, so d2u is essential.

cgf
(boy what a strange thread this has been)

Not half!

Rob

[Robert Collins]

-----Original Message-----
Sent: Sunday, 14 July 2002 4:33 PM
Subject: RE: Bug in startxwin.bat after installing with
setup.exe in win98SE

-----Original Message-----

Christopher Faylor

Sent: Sunday, 14 July 2002 2:31 PM
Subject: Re: Bug in startxwin.bat after installing with
setup.exe in win98SE

Post by Robert Collins
As for linefeed issues, AFAIK windows will process bat files

with unix

Post by Robert Collins
format, but you could always use d2u in your script.

I don't think Windows 9x systems will understand bat files with unix
line endings.

Right, so d2u is essential.

Erm, u2d. Yes, that's what I mean. Honestly.

Rob

[Harold Hunt]

Wow.

I sure am glad that I was out of town, throwing a party, and replacing the
power steering pump in my Jeep this weekend while you guys slugged this one
out.

The end result is that I have a couple of scripts to look at and evaluate.
Right now I am still trying to get that scrollbars patch release, so the
scripts will have to wait until 4.2.0-12 is released.

Once again, wow.

Harold

[Thomas Chadwick]

I hate to jump into the middle of a religious argument (which this is
turning out to be) but it seems to me that a plausible solution would be to
urge the maintainers of the cygwin setup program to define a CYGWIN_ROOT
environment variable for us. Cygwin setup is already putting stuff in the
registry, isn't it, so why not this?

You could then modify the startxwin.bat and startxwin.sh scripts such that
they don't attempt to assign CYGWIN_ROOT if it already has a value.

Subject: Re: Bug in startxwin.bat after installing with setup.exe in
win98SE
Date: Fri, 12 Jul 2002 16:37:56 EDT

Post by Jehan

Post by Harold L Hunt
Okay, if you are so smart, explain to me how I can put a drive letter

into a

Post by Jehan

Post by Harold L Hunt
batch file that is expected to work on computers where Cygwin could be
installed on ``c:\cygwin'' or ``d:\cygwin''? I certainly could not

put ``c''

Post by Jehan

Post by Harold L Hunt
as the drive, nor could I put ``d'' as the drive. So, what do you

suggest?

Post by Jehan
First, I'm not trying to bash you (how could I, we are fellow
Cgwin/XFree programmers *grin*) but I'm trying to understand your
motivation. So here is my question: in what sense is "\cygwin" better
"c:\cygwin"? I mean, I used to install cygwin in "c:\program
files\cygwin". So neither "\cygwin" nor "c:\cygwin" would work. But
then, when I see just "\cygwin", I think a unix path (I know, the "\"
isn't a "/", but I'm a little dumb sometimes :p). So at first, I
overlooked it. I'm pretty sure that if I had seend "c:\cygwin", I would
have thought of changing it.
The other thing too is that "\cygwin" is sort of a bastard. It's not a
full path because it doesn't have the drive letter. It's not a relative
path because it doesn't start from the current directory but from the
root of the current drive.
Last, with "\cygwin", the batch file works sometimes (the current drive
is where cygwin is) and sometimes it doesn't (wrong current drive). As a
programmer, I prefer things that always crash or never do.
So, in this light, as my personal opinion (which doesn't matter anymore
now that I have cygwin in "c:\cygwin" ;p ), would be to use an full
absolute path.

Unfortunately you cannot use a relative path (e.g. ..\..\.., which gets
\bin
appended on it to point to /bin) because that causes bash (or whatever
shell
you launch in xterm) to have a relative path the Cygwin binaries. Thus you
can no longer run Cygwin binaries if you change out of the /usr/X11R6/bin
directory, because your relative path to the Cygwin binaries is now
incorrect.
So, we have to use an absolute path, which is why why need something like
c:\cygwin. We go one further an change this to \cygwin because we used to
get
weekly complaints like, ``yikes, cygwin1.dll could not be found, cause i am
l33t and i installed to d:\cygwin''. We do not get regular complaints
anymore, so \cygwin is an improvement over c:\cygwin.
I
wrote two paragraphs! of comments about setting the path correctly, and in
those comments there does appear a c:\cygwin. I cannot help someone if
they
are skimming so fast as to completely miss all of that.
I will admit one current problem with startxwin.bat: the User's Guide is
out
of date so we do not recommend that new users read it to install
Cygwin/XFree86. Unfortunately this means that people do not see,
repeatedly,
my recommendations that they install Cygwin in c:\cygwin that are in the
User's Guide.
One idea is that we could try to parse the return from ``chdir'', which
gives,
C:\cygwin\usr\X11R6\bin>chdir
C:\cygwin\usr\X11R6\bin
It would be pretty easy to construct a location for /bin or /usr/bin from
the
output of chdir, but then we are back to the Catch-22 that we would need
Cygwin binaries in order to find the location of the Cygwin binaries.

Post by Jehan

Post by Harold L Hunt
Okay, okay, so you are thinking, ``just use cygpath, duh''. However,

if I

Post by Jehan

Post by Harold L Hunt
could use ``cygpath'', then that implies that I already know where the

Cygwin

Post by Jehan

Post by Harold L Hunt
binaries are located since I just ran one of them. But, I don't know

where

Post by Jehan

Post by Harold L Hunt
the Cygwin binaries are located, as that is why we are guessing what

the
path is.

Post by Jehan
Can the batch file be created via the installation script? Then you're
environment would be cygwin and not windows, wouldn't it? The thing I
don't know there would be the "cr/lf" vs "lf" thing.

Post by Harold L Hunt

Post by Bernard A Badger
That's no excuse to fail to fix a known problem.

Bernard,
And "not having a better solution", is it a good excuse? It's always
easy to critize but critizing doesn't make the world to go forward.

Post by Harold L Hunt
Huh? There are things in life that are worth spending time on because

they

Post by Jehan

Post by Harold L Hunt
will have a large effect, and there are things in life that are not

worth

Post by Jehan

Post by Harold L Hunt
spending time on because they will have almost no effect whatsoever.

Changing

Post by Jehan

Post by Harold L Hunt
the startxwin.bat file to allow people to run it from a location other

than

Post by Jehan

Post by Harold L Hunt
where it is installed to (which has got to be obvious to most users as

doing

Post by Jehan

Post by Harold L Hunt
something that was not intended), is one of those things that will

have almost

Post by Jehan

Post by Harold L Hunt
no effect. You are going to have to do a lot better than that if you

expect

Post by Jehan

Post by Harold L Hunt
me to keep my gleaming white ass in a dimly lit room programming when

I could

Post by Jehan

Post by Harold L Hunt
be sitting outside by the pool, getting a tan, and drinking a beer.
Man, if you are going to try to one-up the maintainer in public, you

had damn

Post by Jehan

Post by Harold L Hunt
well better be giving a complete solution, rather than trying to

suggest that

Post by Jehan

Post by Harold L Hunt
the maintainer creates one himself. Because in the latter case you

just open

Post by Jehan

Post by Harold L Hunt
yourself up to off-topic ranting like I just did. Yes, this makes me

feel

Post by Jehan

Post by Harold L Hunt
better when I get to write funny things about how I don't like to

program.

Post by Jehan

Post by Harold L Hunt
So, in a way, you have done me a good service. Thank you :)

Go harold, go!! Kill him :). You know what is better than "sitting
outside by the pool, getting a tan, and drinking a beer"? It sitting
outside by the pool, getting a tan, drinking a beer and watching a fight
game! :)
Jehan

Heh heh... What is a ``fight game''? Are you referring to boxing?
Harold

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

[Jehan]

Post by Thomas Chadwick
I hate to jump into the middle of a religious argument (which this is
turning out to be) but it seems to me that a plausible solution would be
to urge the maintainers of the cygwin setup program to define a
CYGWIN_ROOT environment variable for us. Cygwin setup is already
putting stuff in the registry, isn't it, so why not this?
You could then modify the startxwin.bat and startxwin.sh scripts such
that they don't attempt to assign CYGWIN_ROOT if it already has a value.

First, I'm not sure that making setup.exe aware of Xfree just because of
the registry is a good idea.
As for adding an environment variable, then we could just modify the
path to add the X11 path to it. Then we could get rid of the CYGWIN_ROOT
altogether.
Last, I still think that a postinstall script to create the batch file
is better (well that was my idea, I'm not going to give up on it easily :p)

Jehan

[Robert Collins]

-----Original Message-----
I hate to jump into the middle of a religious argument (which this is
turning out to be) but it seems to me that a plausible
solution would be to
urge the maintainers of the cygwin setup program to define a
CYGWIN_ROOT
environment variable for us. Cygwin setup is already putting
stuff in the
registry, isn't it, so why not this?

No. Use `mount -w /` in your postinstall shell script.

Rob

[Jehan]

Post by Robert Collins

-----Original Message-----
I hate to jump into the middle of a religious argument (which this is
turning out to be) but it seems to me that a plausible
solution would be to
urge the maintainers of the cygwin setup program to define a
CYGWIN_ROOT
environment variable for us. Cygwin setup is already putting
stuff in the
registry, isn't it, so why not this?

No. Use `mount -w /` in your postinstall shell script.

You mean `cygpath -w /` I guess. Mount doesn't have an option "-w".

Jehan

[Harold L Hunt]

Post by Thomas Chadwick
I hate to jump into the middle of a religious argument (which this is
turning out to be) but it seems to me that a plausible solution would be to
urge the maintainers of the cygwin setup program to define a CYGWIN_ROOT
environment variable for us. Cygwin setup is already putting stuff in the
registry, isn't it, so why not this?
You could then modify the startxwin.bat and startxwin.sh scripts such that
they don't attempt to assign CYGWIN_ROOT if it already has a value.

Oh great, you just took a religious war and told the heathens that they could
fight too. :)

I am inclined to let this issue work itself out without my involvement, other
than to release a patched startxwin.bat if necessay.

Harold

[Christopher Faylor]

Post by Harold L Hunt
Oh great, you just took a religious war and told the heathens that they
could fight too. :)
I am inclined to let this issue work itself out without my involvement,
other than to release a patched startxwin.bat if necessay.

Oh sure, just as I was strapping on my spandex tights, you go and take
all of the fun out of things...

cgf

[Jehan]

Post by Harold L Hunt
I am inclined to let this issue work itself out without my involvement, other
than to release a patched startxwin.bat if necessay.

Hi harold,

Here is a script that will generate the startxwin.bat file. You might
want to verify that the batch file is like the original. I had mine
modified but hopefully I reverted all of the changes.

So this script should run as a postintall to the XFree86-startup-scripts
package. It depends on u2d to convert the newlines so you'll have to add
cygutils to the package dependencies.

Also, I didn't want to do to much in this script yet but you may want to
remove the logic about NT vs 9x from the batch and move it into the
script itself. This would make a batch file easier to read/modify for
the newbies... right, they *are* the same now that you use "run" instead
of "start" (or is it one of my unreverted change?)

Jehan

[Jehan]

I forgot to check if the batch file already existed or not. Attached is
the corrected script.

Jehan

[Nicholas Wourms]

Post by Jehan
I forgot to check if the batch file already existed or not. Attached is
the corrected script.
Jehan

#!/bin/sh

BATCH_FILE=/usr/X11R6/bin/startxwin.bat
if [ ! -f ${BATCH_FILE} ]; then
################################
# First part of the batch file
cat << EOF > $BATCH_FILE
@echo off
SET DISPLAY=127.0.0.1:0.0
REM
REM The path in the CYGWIN_ROOT environment variable assignment assume
REM that Cygwin is installed in a directory called 'cygwin' in the root
REM directory of the current drive. You will only need to modify
REM CYGWIN_ROOT if you have installed Cygwin in another directory. For
REM example, if you installed Cygwin in \foo\bar\baz\cygwin, you will
need
REM to change \cygwin to \foo\bar\baz\cygwin.
REM
REM This batch file will almost always be run from the same drive (and
REM directory) as the drive that contains Cygwin/XFree86, therefore you
will
REM not need to add a drive letter to CYGWIN_ROOT. For example, you do
REM not need to change \cygwin to c:\cygwin if you are running this
REM batch file from the C drive.
REM
EOF
################################
# Get the DOS path to cygwin
echo SET CYGWIN_ROOT=`cygpath -w /` >> $BATCH_FILE
################################
# Second part of the batch file
cat << EOF >> $BATCH_FILE
SET PATH=.;%CYGWIN_ROOT%\bin;%CYGWIN_ROOT%\usr\X11R6\bin;%PATH%
REM
REM Cleanup after last run.
REM
if not exist %CYGWIN_ROOT%\tmp\.X11-unix\X0 goto CLEANUP-FINISH
attrib -s %CYGWIN_ROOT%\tmp\.X11-unix\X0
del %CYGWIN_ROOT%\tmp\.X11-unix\X0
:CLEANUP-FINISH
if exist %CYGWIN_ROOT%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\tmp\.X11-unix
REM
REM Startup the X Server, the twm window manager, and an xterm.
REM
REM Notice that the window manager and the xterm will wait for
REM the server to finish starting before trying to connect; the
REM error "Cannot Open Display: 127.0.0.1:0.0" is not due to the
REM clients attempting to connect before the server has started, rather
REM that error is due to a bug in some versions of cygwin1.dll. Upgrade
REM to the latest cygwin1.dll if you get the "Cannot Open Display"
error.
REM http://xfree86.cygwin.com/docs/faq/
REM
REM The error "Fatal server error: could not open default font 'fixed'"
is
REM caused by using a DOS mode mount for the mount that the
Cygwin/XFree86
REM fonts are accessed through. See the Cygwin/XFree86 FAQ for more
REM

http://xfree86.cygwin.com/docs/faq/cygwin-xfree-faq.html#q-error-font-eof

Post by Jehan
REM
REM
REM Use the /B switch only when we can positively confirm that the OS
REM is Windows NT/2000. Do not use the switch in any other case. This
REM should work fine, as it assumes we cannot use /B, except when a
certain
REM criterion is met. A previous version of this batch file assumed
that
REM we could use /B, except when some criterion was met; needless to
say,
REM that didn't work.
REM
if "%OS%" == "Windows_NT" goto USE-B-SWITCH
REM Windows 95/98/Me
echo startxwin.bat - Starting on Windows 95/98/Me
REM Startup the X Server.
start XWin
REM Startup an xterm, using bash as the shell.
run xterm -sl 1000 -sb -ms red -fg gray -bg black -e /usr/bin/bash
REM Startup the twm window manager.
run twm
goto END
REM
REM Use the /B switch. This starts the specified process in the
background;
REM in other words, it does not cause a new Command Prompt window to be
REM opened for each 'start' command.
REM
:USE-B-SWITCH
REM Windows NT/2000
echo startxwin.bat - Starting on Windows NT/2000
REM Startup the X Server.
start XWin
REM Startup an xterm, using bash as the shell.
run xterm -sl 10000 -sb -ms red -fg gray -bg black -e /usr/bin/bash
REM Startup the twm window manager.
run twm
:END
REM Set a background color to comply with FCC regulations :)
run xsetroot -solid aquamarine4
EOF
################################
# Convert the file to dos format
# and update the permission
u2d $BATCH_FILE
chmod 755 $BATCH_FILE
fi

Jehan,

You still have the chicken-and-the egg issue. How is a user going to
startxwin from a console window if /usr/X11R6/bin is not in their path?
Obviously, if the user installs these packages, they want to be able to
access them. The answer to this is to make 2 scripts that get installed
in the /etc/profile.d directory by the XFree86-base package. One is for
the tcsh/csh users and the other is for the bash/ash/zsh users. In these
two scripts we establish the following:

1)Add /usr/X11R6/bin to the $PATH
2)Resolve the new environmental CYGWIN_X_ROOT by using the method you
specified above.

Then have the various startxwin scripts employ CYGWIN_X_ROOT, but strip
the PATH setting from them. This way you avoid multiple instances of the
XFree directories in your path. So what about the .bat file you say?
Easy, just have it run bash - which then executes the xfree script in
/etc/profile.d, followed by the script startxwin.sh. So my recommendation
is to examine the openssl.csh and openssl.sh scripts in /etc/profile.d for
some examples. You can also look in /etc/profile.d on linux.

There are many reasons why I like this method, most all of them are state
above. I think the main one that isn't stated is that it is nice to have
all the configuration stuff under /etc.

I know we have a difference of opinion when it come to Rootless mode, but
I'm sure you can see the logic in my proposal. If you'd rather me write
up the scripts, then I will. However, since it is your idea, I don't want
to steal your show.

Cheers,
Nichola

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

[Jehan]

Post by Nicholas Wourms
You still have the chicken-and-the egg issue. How is a user going to
startxwin from a console window if /usr/X11R6/bin is not in their path?

Two things:
- For what I understood of the problem, Michael already found the batch
file but then, CYGWIN_ROOT was pointing to the wrong drive (or more
exactly didn't point to any drive at all) with the end result that
cygwin application couldn't find the dll.
My shell script, once run by the installation, create a batch file with
an absolute path to cygwin. So when someone runs it, the dll will be
found => Michael's problem fixed.
- Correct me if I'm wrong but the batch file is to be run from Explorer
or the like, not from a console. If you want to use the console, then
use startxwin.sh (assuming that your console is Bash, which, from the
rest of your message, seems to be the case)

Post by Nicholas Wourms
Obviously, if the user installs these packages, they want to be able to
access them. The answer to this is to make 2 scripts that get installed
in the /etc/profile.d directory by the XFree86-base package. One is for
the tcsh/csh users and the other is for the bash/ash/zsh users. In these
1)Add /usr/X11R6/bin to the $PATH
2)Resolve the new environmental CYGWIN_X_ROOT by using the method you
specified above.
Then have the various startxwin scripts employ CYGWIN_X_ROOT, but strip
the PATH setting from them. This way you avoid multiple instances of the
XFree directories in your path. So what about the .bat file you say?
Easy, just have it run bash - which then executes the xfree script in
/etc/profile.d, followed by the script startxwin.sh. So my recommendation
is to examine the openssl.csh and openssl.sh scripts in /etc/profile.d for
some examples. You can also look in /etc/profile.d on linux.

Ok, Harold, find attached the two scripts that will add the X path to
the PATH environment variable when one starts a shell. That way he/she
doesn't have to use the full path for startxwin.sh. The "export PATH" in
startxwin.sh can then be removed.

As to have the batch file running Bash which will execute startxwin.sh,
two things:
1) that doesn't fix your chicken-and-egg problem, you still have to find
the batch file.
2) once you have the batch file, it still have to find Bash!

My little install.sh script fixes 2).

For 1), I know of three solutions:
- what we have currently: have the guy search for the batch, and create
a shortcut if he wants to, in a more accesible place (desktop, start
menu, whatever). Not ideal, but works ok if documented.
- modify the windows path environment (I'm not found of that) and ask
the user to run a command prompt and then startxwin.bat. No better than
starting Bash and running startwin.sh (actually worse because we have to
globally change the Windows path).
- Create a shortcut to the batch file in the start menu. That would be
the best solution except that I don't know how to do it. Cygwin does
something like that for cygwin.bat but IIRC it has the cygwin path
hardcoded to "C:\cygwin" even if you installed cygwin in "t:\foo\bar".

Post by Nicholas Wourms
However, since it is your idea, I don't want to steal your show.

I like to defend my ideas, it satisfies my ego when their chosen over
someone else's. But that doesn't mean I don't like people helping me
out. Participating to a project/idea doesn't make it your own so have no
fear.

Jehan

[Robert Collins]

-----Original Message-----
Sent: Sunday, 14 July 2002 7:46 AM

...

- Create a shortcut to the batch file in the start menu. That
would be
the best solution except that I don't know how to do it. Cygwin does
something like that for cygwin.bat but IIRC it has the cygwin path
hardcoded to "C:\cygwin" even if you installed cygwin in "t:\foo\bar".

The cygwin bat file is created based on the output of mount, so it's
always correct.
Rob

[Jehan]

Post by Robert Collins

Post by Jehan
- Create a shortcut to the batch file in the start menu. That
would be
the best solution except that I don't know how to do it. Cygwin does
something like that for cygwin.bat but IIRC it has the cygwin path
hardcoded to "C:\cygwin" even if you installed cygwin in "t:\foo\bar".

The cygwin bat file is created based on the output of mount, so it's
always correct.

I'm not talking of the batch file, I have that figured out but about the
shortcut one gets in "Start | Cygwin". Doesn't this always point to
"c:\cygwin\cygwin.bat" even if cygwin.bat is actually in "t:\foo\bar"?

Jehan

[Robert Collins]

-----Original Message-----
Sent: Sunday, 14 July 2002 7:51 AM
To: Robert Collins
Subject: Re: Bug in startxwin.bat after installing with
setup.exe in win98SE

Post by Robert Collins

Post by Jehan
- Create a shortcut to the batch file in the start menu. That
would be
the best solution except that I don't know how to do it.

Cygwin does

Post by Robert Collins

Post by Jehan
something like that for cygwin.bat but IIRC it has the cygwin path
hardcoded to "C:\cygwin" even if you installed cygwin in

"t:\foo\bar".

Post by Robert Collins
The cygwin bat file is created based on the output of mount, so it's
always correct.

I'm not talking of the batch file, I have that figured out
but about the
shortcut one gets in "Start | Cygwin". Doesn't this always point to
"c:\cygwin\cygwin.bat" even if cygwin.bat is actually in "t:\foo\bar"?

Nope, it's also generated from mount information. Cygwin could be
z:\bar\foo\bar and it would still be correct.

Rob

[Jehan]

Post by Robert Collins
Nope, it's also generated from mount information. Cygwin could be
z:\bar\foo\bar and it would still be correct.

Is there a way then for a program to add (after asking the user) to
create a shortcut on the desktop/start menu? Is there also way to get
the information about the installing for "all users" or "just me"?

Jehan

[Robert Collins]

-----Original Message-----
Sent: Sunday, 14 July 2002 8:18 AM
To: Robert Collins
Subject: Re: Bug in startxwin.bat after installing with
setup.exe in win98SE

Post by Robert Collins
Nope, it's also generated from mount information. Cygwin could be
z:\bar\foo\bar and it would still be correct.

Is there a way then for a program to add (after asking the user) to
create a shortcut on the desktop/start menu? Is there also way to get
the information about the installing for "all users" or "just me"?
Jehan

Yes to the first, it's a tool in cygutils - Chuck answered the same
question here less than a week ago.
No to the second, that's not exported anywhere by setup. Perhaps it
should be.

Rob

[Jehan]

Post by Robert Collins

-----Original Message-----
Sent: Sunday, 14 July 2002 8:18 AM
To: Robert Collins
Subject: Re: Bug in startxwin.bat after installing with
setup.exe in win98SE

Post by Robert Collins
Nope, it's also generated from mount information. Cygwin could be
z:\bar\foo\bar and it would still be correct.

Is there a way then for a program to add (after asking the user) to
create a shortcut on the desktop/start menu? Is there also way to get
the information about the installing for "all users" or "just me"?
Jehan

Yes to the first, it's a tool in cygutils - Chuck answered the same
question here less than a week ago.

Kool, thanks! I missed that thread.

Harold, here is an updated install.sh that will ask the user if he wants
a shortcut on the desktop and in the Start menu. Again, this script
requires cygutils (for both u2d and mkshortcut now)

Jehan

[Jehan]

I forgot to attach the "X.ico" file. It's not the best in the world but
I guess it will do (it's the same I sent you with the systray patch a
while ago). It is to be installed in /usr/X11R6/bin (or you have to
modify the script)

Jehan

[Nicholas Wourms]

Post by Jehan
I forgot to attach the "X.ico" file. It's not the best in the world but
I guess it will do (it's the same I sent you with the systray patch a
while ago). It is to be installed in /usr/X11R6/bin (or you have to
modify the script)
Jehan
ATTACHMENT part 2 image/x-icon name=X.ico

Jehan,

If you search the archives, others have already made icons ready for you
use :). Meanwhile, I've been thinking about this and looking at the
setup.exe code. If no-one minds, I'm going to generate and submit a patch
that has setup.exe do all the shortcut stuff. Though your bat file is
still useful. I wonder why not just can all the dos stuff by having the
batch file call bash which then calls startxwin.sh? One file is *much*
easier to maintain then two. Anywho, let me know your thoughts on this..

Cheers,
Nicholas

P.S. - Robert that goes for you too...

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

[Robert Collins]

-----Original Message-----
Sent: Sunday, 14 July 2002 10:13 AM
Subject: Re: Bug in startxwin.bat after installing with
setup.exe in win98SE

Post by Jehan
I forgot to attach the "X.ico" file. It's not the best in

the world but

Post by Jehan
I guess it will do (it's the same I sent you with the

systray patch a

Post by Jehan
while ago). It is to be installed in /usr/X11R6/bin (or you have to
modify the script)
Jehan
ATTACHMENT part 2 image/x-icon name=X.ico

Jehan,
If you search the archives, others have already made icons
ready for you
use :). Meanwhile, I've been thinking about this and looking at the
setup.exe code. If no-one minds, I'm going to generate and
submit a patch
that has setup.exe do all the shortcut stuff. Though your bat file is
still useful. I wonder why not just can all the dos stuff by
having the
batch file call bash which then calls startxwin.sh? One file
is *much*
easier to maintain then two. Anywho, let me know your
thoughts on this..

I mind. Setup should become -more- data driven not less.

Rob

[Nicholas Wourms]

Post by Robert Collins

-----Original Message-----
Sent: Sunday, 14 July 2002 10:13 AM
Subject: Re: Bug in startxwin.bat after installing with
setup.exe in win98SE

Post by Jehan
I forgot to attach the "X.ico" file. It's not the best in

the world but

Post by Jehan
I guess it will do (it's the same I sent you with the

systray patch a

Post by Jehan
while ago). It is to be installed in /usr/X11R6/bin (or you have to
modify the script)
Jehan
ATTACHMENT part 2 image/x-icon name=X.ico

Jehan,
If you search the archives, others have already made icons
ready for you
use :). Meanwhile, I've been thinking about this and looking at the
setup.exe code. If no-one minds, I'm going to generate and
submit a patch
that has setup.exe do all the shortcut stuff. Though your bat file is
still useful. I wonder why not just can all the dos stuff by
having the
batch file call bash which then calls startxwin.sh? One file
is *much*
easier to maintain then two. Anywho, let me know your
thoughts on this..

I mind. Setup should become -more- data driven not less.

Excuse me? All I was suggesting is to reword the final setup screen to
something like the following:

-Create Icon on Desktop for Cygwin Command Prompt
-Create Icon on Desktop for Cygwin/XFree86
-Add Icon to Start Menu for Cygwin Command Prompt
-Add Icon to Start Menu for Cygwin/XFree86

Then have setup create the shortcuts in the same fasion it does already.
Eventually, I'd like to have it gray-out the check boxes for
Cygwin/XFree86 if it is not already installed. How is this not data
driven? Isn't this what the setup program is for? The last time I
checked, most Windows installers handled the shortcut creation.

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

[Jehan Bing]

Post by Nicholas Wourms
Excuse me? All I was suggesting is to reword the final setup screen to
-Create Icon on Desktop for Cygwin Command Prompt
-Create Icon on Desktop for Cygwin/XFree86
-Add Icon to Start Menu for Cygwin Command Prompt
-Add Icon to Start Menu for Cygwin/XFree86
Then have setup create the shortcuts in the same fasion it does already.
Eventually, I'd like to have it gray-out the check boxes for
Cygwin/XFree86 if it is not already installed. How is this not data
driven? Isn't this what the setup program is for? The last time I
checked, most Windows installers handled the shortcut creation.

Robert is right Nicholas (oh no not this guy again! :p). The question is
why add XFree to the list and not SSH and RSH, and Lynx, and, and, and....
And since we can create the shortcuts via the postinstall script, why do
you want to add this feature to setup.exe?
The script is not very cool looking, I give you that, but it's far more
flexible.

Jehan

[Nicholas Wourms]

Post by Nicholas Wourms

Post by Nicholas Wourms
Excuse me? All I was suggesting is to reword the final setup screen to
-Create Icon on Desktop for Cygwin Command Prompt
-Create Icon on Desktop for Cygwin/XFree86
-Add Icon to Start Menu for Cygwin Command Prompt
-Add Icon to Start Menu for Cygwin/XFree86
Then have setup create the shortcuts in the same fasion it does

already.

Post by Nicholas Wourms
Eventually, I'd like to have it gray-out the check boxes for
Cygwin/XFree86 if it is not already installed. How is this not data
driven? Isn't this what the setup program is for? The last time I
checked, most Windows installers handled the shortcut creation.

Robert is right Nicholas (oh no not this guy again! :p). The question is
why add XFree to the list and not SSH and RSH, and Lynx, and, and, and....
And since we can create the shortcuts via the postinstall script, why do
you want to add this feature to setup.exe?
The script is not very cool looking, I give you that, but it's far more
flexible.

No he isn't. There are two ways that someone will interface with Cygwin,
via Console or via X11. The other apps you mention are Console apps,
therefore you can't expect them to have shortcuts. However X is much more
than an Application, it is an interface. Therefore, one can argue that it
deserves setup.exe making it a shortcut just as much as setup.exe making
the console a shortcut. Lastly, something you will not disagree with,
ALOT of people want to use just X and not the console, especially for
doing XDMCP. This is even more reason why setup.exe should make the
shortcut.

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

[Robert Collins]

-----Original Message-----
Sent: Sunday, 14 July 2002 10:57 AM
To: Jehan Bing

...

No he isn't. There are two ways that someone will interface
with Cygwin,
via Console or via X11. The other apps you mention are Console apps,
therefore you can't expect them to have shortcuts. However X
is much more
than an Application, it is an interface. Therefore, one can
argue that it
deserves setup.exe making it a shortcut just as much as
setup.exe making
the console a shortcut. Lastly, something you will not disagree with,
ALOT of people want to use just X and not the console, especially for
doing XDMCP. This is even more reason why setup.exe should make the
shortcut.

The above is an argument for the creation of the shortcut, not for
setup.exe creating it.

Rob

[Nicholas Wourms]

Post by Robert Collins

-----Original Message-----
Sent: Sunday, 14 July 2002 10:57 AM
To: Jehan Bing

...

No he isn't. There are two ways that someone will interface
with Cygwin,
via Console or via X11. The other apps you mention are Console apps,
therefore you can't expect them to have shortcuts. However X
is much more
than an Application, it is an interface. Therefore, one can
argue that it
deserves setup.exe making it a shortcut just as much as
setup.exe making
the console a shortcut. Lastly, something you will not disagree with,
ALOT of people want to use just X and not the console, especially for
doing XDMCP. This is even more reason why setup.exe should make the
shortcut.

The above is an argument for the creation of the shortcut, not for
setup.exe creating it.

Why should setup be more generic? Why shouldn't it create the shortcuts?
Why not reuse the exisiting code and then remove it when something better
comes along? Why do you want to remove more stuff from setup.exe when you
haven't anything to replace it with? I've noticed that all these shell
scripts flying by at the end pushes the stability of windows. I've had a
few BSODs during their execution. I think all this talk of making
setup.exe smaller is rubbish, it is only ~200KB for the love of God.
Again the whole idea is to use the tools at hand, which in this case is
setup.exe. Why not leverage it for all it is worth? Why rely on shell
scripts when you have something more dependable?

Cheers,
Nichola

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

[Robert Collins]

-----Original Message-----
Sent: Sunday, 14 July 2002 11:19 AM
To: Robert Collins; 'Jehan Bing'

Post by Robert Collins
The above is an argument for the creation of the shortcut, not for
setup.exe creating it.

Why should setup be more generic?

For flexability to the maintainers, to make it easier to maintain, to
make it of more use to the community.

Why shouldn't it create
the shortcuts?

It could, via interpreting some data file, or in association with a post
install script. I even pointed the way towards this with my reference to
another data driven system, but got rewarded by being told that 'you'
won't have any 'debian' talk. You can close your mind to the lessons
learnt by the most flexible open source distribution in existence if you
choose... I choose to learn some of the lessons.

Why not reuse the exisiting code and then remove it when
something better
comes along?

Because
A) a solution has already been posted.
B) I've been trying to get the existing code removed for ages - because
better things already exist.
C) Special cases make code maintenance much much harder.

Why do you want to remove more stuff from
setup.exe when you
haven't anything to replace it with?

? I don't follow.

I've noticed that all
these shell
scripts flying by at the end pushes the stability of windows.
I've had a
few BSODs during their execution.

Then you have found YA bug in windows. BSOD's cannot get caused by user
programs except where MS or a driver coder have made mistakes.

I think all this talk of making
setup.exe smaller is rubbish, it is only ~200KB for the love of God.

That's the binary size, and it's fine.

Again the whole idea is to use the tools at hand, which in
this case is
setup.exe. Why not leverage it for all it is worth? Why
rely on shell
scripts when you have something more dependable?

Because shell scripts allow modular changes to be made without affecting
the rest of the distribution.

Rob

[Jehan]

Post by Nicholas Wourms
Why should setup be more generic?

Because it's more flexible. We don't limit ourself to predefined
behavior. Right now, only cygwin create a shortcut. Soon (hopefully)
XWin will to. Tomorrow, SSH will want to. And rxvt. And csh...
We *have* a way to make shortcuts already, why don't you want to use it!?!?!

Post by Nicholas Wourms
Why shouldn't it create the shortcuts?

You never answered my question: what's wrong with the script doing it?

Post by Nicholas Wourms
Why not reuse the exisiting code and then remove it when something better
comes along?

From experience, this thing rarely gets removed.

Post by Nicholas Wourms
Why do you want to remove more stuff from setup.exe when you
haven't anything to replace it with?

Are you listening? What is my script for?

Post by Nicholas Wourms
I've noticed that all these shell
scripts flying by at the end pushes the stability of windows. I've had a
few BSODs during their execution.

Really? Then there is bug that must be fixed. Working around it isn't a
clean solution.
Otherwise, I agree that all those console window showing up isn't
pretty. Maybe your fix could show only one window that would run all the
scripts instead?

Post by Nicholas Wourms
I think all this talk of making
setup.exe smaller is rubbish, it is only ~200KB for the love of God.
Again the whole idea is to use the tools at hand, which in this case is
setup.exe. Why not leverage it for all it is worth?

Postinstall script is a tool at hand

Post by Nicholas Wourms
Why rely on shell
scripts when you have something more dependable?

Then fix the bug in the script. They must work, we won't be able to
completly get rid of them. Creating another feature just because one
doesn't work isn't a solution. That's just give bloatware.

Jehan

[Robert Collins]

-----Original Message-----
Sent: Sunday, 14 July 2002 10:24 AM

Post by Robert Collins
I mind. Setup should become -more- data driven not less.

Excuse me? All I was suggesting is to reword the final setup
screen to
-Create Icon on Desktop for Cygwin Command Prompt
-Create Icon on Desktop for Cygwin/XFree86
-Add Icon to Start Menu for Cygwin Command Prompt
-Add Icon to Start Menu for Cygwin/XFree86
Then have setup create the shortcuts in the same fasion it
does already.
Eventually, I'd like to have it gray-out the check boxes for
Cygwin/XFree86 if it is not already installed. How is this not data
driven? Isn't this what the setup program is for? The last time I
checked, most Windows installers handled the shortcut creation.

If you need to recompile setup.exe to change it's behaviour, it is not
data driven. Most windows installers are driven by an data that drives
the dialogs.

The 'right' way to do it, is something like the menu's that dpkg uses,
they are pure data, and can be interpreted and shown as gui interfaces,
or as text menus, or set via the command line.

So, here are some options:
1) Implement an interpreter for dpkg's configure menus in setup.
2) Create something new along similar lines.
3) Use a slang interface or something like that in the postinstall
script (*).

Rob

(*) Is problematic - what happens when we start redirecting the
postinstall output to log it.

[Nicholas Wourms]

Post by Robert Collins

-----Original Message-----
Sent: Sunday, 14 July 2002 10:24 AM

Post by Robert Collins
I mind. Setup should become -more- data driven not less.

Excuse me? All I was suggesting is to reword the final setup
screen to
-Create Icon on Desktop for Cygwin Command Prompt
-Create Icon on Desktop for Cygwin/XFree86
-Add Icon to Start Menu for Cygwin Command Prompt
-Add Icon to Start Menu for Cygwin/XFree86
Then have setup create the shortcuts in the same fasion it
does already.
Eventually, I'd like to have it gray-out the check boxes for
Cygwin/XFree86 if it is not already installed. How is this not data
driven? Isn't this what the setup program is for? The last time I
checked, most Windows installers handled the shortcut creation.

If you need to recompile setup.exe to change it's behaviour, it is not
data driven. Most windows installers are driven by an data that drives
the dialogs.
The 'right' way to do it, is something like the menu's that dpkg uses,
they are pure data, and can be interpreted and shown as gui interfaces,
or as text menus, or set via the command line.
1) Implement an interpreter for dpkg's configure menus in setup.
2) Create something new along similar lines.
3) Use a slang interface or something like that in the postinstall
script (*).

Robert,

I'll have none of this debian talk. You know full well that I am working
very hard to get rpm-4.1 ready for inclusion into the distribution. At
that point, Chuck and I will start figuring out ways to interface it with
setup. Also, we will be figuring out how to best transition setup to use
rpms. The point of this is that all this talk is a long way off. I'm not
going to invent a new interface when others already exist. The fact of
the matter is, that for right now, setup is well suited to perform the
task at hand, which is to support all of the future X users. Like it or
not, there is enough of them to warrant a separate mailing list. Lets
temporarily let setup do this now and then we'll replace it when something
better comes along.

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

[Robert Collins]

-----Original Message-----
Sent: Sunday, 14 July 2002 11:09 AM
Robert,
I'll have none of this debian talk. You know full well that
I am working
very hard to get rpm-4.1 ready for inclusion into the
distribution. At
that point, Chuck and I will start figuring out ways to
interface it with
setup. Also, we will be figuring out how to best transition
setup to use
rpms. The point of this is that all this talk is a long way
off. I'm not
going to invent a new interface when others already exist.
The fact of
the matter is, that for right now, setup is well suited to perform the
task at hand, which is to support all of the future X users.
Like it or
not, there is enough of them to warrant a separate mailing list. Lets
temporarily let setup do this now and then we'll replace it
when something
better comes along.

Nicholas, no consensus has been reached for using the rpm database as
the backend. If rpm has a similar system to the one I referenced,
substitute rpm for dpkg in my previous comments. I *did not* suggest
that we use dpkg as a backend for this particular thing either - I
pointed out the best practice pattern to address the issue we are
facing. Lets stick to that topic, shall we?

For now, try listening, not taking the conversation off on tangents. I
happen to have put quite a bit of effort into the Cygwin Xfree86 project
in the past, and continue to make various contributions as and when it's
appropriate. I strongly resent your implying that I might dislike the
presence of the cygwin-xfree86 community - which I am a member of!

The simple fact is, I disagree with your proposal, and you have made no
convincing arguments to change my mind. What you are suggesting is not
what 'most' windows installers do, it is not flexible, it is a step
backwards in approach, and a proper solution is not that hard to do!

Rob

[Nicholas Wourms]

Post by Robert Collins

-----Original Message-----
Sent: Sunday, 14 July 2002 11:09 AM
Robert,
I'll have none of this debian talk. You know full well that
I am working
very hard to get rpm-4.1 ready for inclusion into the
distribution. At
that point, Chuck and I will start figuring out ways to
interface it with
setup. Also, we will be figuring out how to best transition
setup to use
rpms. The point of this is that all this talk is a long way
off. I'm not
going to invent a new interface when others already exist.
The fact of
the matter is, that for right now, setup is well suited to perform the
task at hand, which is to support all of the future X users.
Like it or
not, there is enough of them to warrant a separate mailing list. Lets
temporarily let setup do this now and then we'll replace it
when something
better comes along.

Nicholas, no consensus has been reached for using the rpm database as
the backend. If rpm has a similar system to the one I referenced,
substitute rpm for dpkg in my previous comments. I *did not* suggest
that we use dpkg as a backend for this particular thing either - I
pointed out the best practice pattern to address the issue we are
facing. Lets stick to that topic, shall we?

Hey, you were the one who brought up debian...

Post by Robert Collins
For now, try listening, not taking the conversation off on tangents. I
happen to have put quite a bit of effort into the Cygwin Xfree86 project
in the past, and continue to make various contributions as and when it's
appropriate. I strongly resent your implying that I might dislike the
presence of the cygwin-xfree86 community - which I am a member of!

I am listening... I don't know where you got this one from, but I respect
your membership in the Cygwin/XFree86 community.

Post by Robert Collins
The simple fact is, I disagree with your proposal, and you have made no
convincing arguments to change my mind. What you are suggesting is not
what 'most' windows installers do, it is not flexible, it is a step
backwards in approach, and a proper solution is not that hard to do!

What you are suggesting is akin to Windows installers run batch files in
the background? I don't think so, so why should we run shell scripts? I
heard your point regarding the backend data-driven support, but lets be
serious, that kind of functionality is months away. My proposal is a
short-term solution which provides the "easiest" way that people wanting
to install X can get going. There is little harm in implimenting this
solution now, considiering that we are both working towards trying to
provide a better solution in the future. Fine, how's this, I'll rip out
the specific references to cygwin.bat and instead have setup parse the ini
for what it should display in that last window and how many it should
display. This is how installishield and others do it. How's that for a
solution?

Cheers,
Nicholas

P.S. My damn keyboard is dying... Also, do I need a debug version of
setup.exe from you or will you be satisified with output from the
non-debug version?

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

[Jehan]

Post by Nicholas Wourms

Post by Robert Collins

-----Original Message-----
Sent: Sunday, 14 July 2002 11:09 AM
Robert,
I'll have none of this debian talk. You know full well that
I am working
very hard to get rpm-4.1 ready for inclusion into the
distribution. At
that point, Chuck and I will start figuring out ways to
interface it with
setup. Also, we will be figuring out how to best transition
setup to use
rpms. The point of this is that all this talk is a long way
off. I'm not
going to invent a new interface when others already exist.
The fact of
the matter is, that for right now, setup is well suited to perform the
task at hand, which is to support all of the future X users.
Like it or
not, there is enough of them to warrant a separate mailing list. Lets
temporarily let setup do this now and then we'll replace it
when something
better comes along.

Nicholas, no consensus has been reached for using the rpm database as
the backend. If rpm has a similar system to the one I referenced,
substitute rpm for dpkg in my previous comments. I *did not* suggest
that we use dpkg as a backend for this particular thing either - I
pointed out the best practice pattern to address the issue we are
facing. Lets stick to that topic, shall we?

Hey, you were the one who brought up debian...

Post by Robert Collins
For now, try listening, not taking the conversation off on tangents. I
happen to have put quite a bit of effort into the Cygwin Xfree86 project
in the past, and continue to make various contributions as and when it's
appropriate. I strongly resent your implying that I might dislike the
presence of the cygwin-xfree86 community - which I am a member of!

I am listening... I don't know where you got this one from, but I respect
your membership in the Cygwin/XFree86 community.

Post by Robert Collins
The simple fact is, I disagree with your proposal, and you have made no
convincing arguments to change my mind. What you are suggesting is not
what 'most' windows installers do, it is not flexible, it is a step
backwards in approach, and a proper solution is not that hard to do!

What you are suggesting is akin to Windows installers run batch files in
the background? I don't think so, so why should we run shell scripts?

Several points here:
1- You have one setup.exe per application in the Windows world. Cygwin
is actually several applications, all using the same setup.exe.
2- A couple years ago, I used Installshield. For what I remember, *there
is* a script. For standard stuff (like destination directory and the
like), this is just field to enter. For more complicated stuff (adding
key to the registry for instance), you can write a script. With
setup.exe, we have a same thing. The standard stuff are descriptions,
dependencies, version,... and non standard are through scripts.
Shortcuts isn't used enough to add a field in setup.ini but could be
used to often enough to just hardcode it in the binary.

Post by Nicholas Wourms
Fine, how's this, I'll rip out
the specific references to cygwin.bat and instead have setup parse the ini
for what it should display in that last window and how many it should
display.

That's a better solution that I could settle for even if I think that
too few application would use it to be worthwhile.

jehan

[Robert Collins]

-----Original Message-----
Sent: Sunday, 14 July 2002 11:45 AM
Hey, you were the one who brought up debian...

Actually, I brought up the technique dpkg uses to address the same
issue. But I can understand that being misinterpreted.

I am listening... I don't know where you got this one from,
but I respect
your membership in the Cygwin/XFree86 community.
From the "Like it or not" comment/

Post by Robert Collins
The simple fact is, I disagree with your proposal, and you

have made no

Post by Robert Collins
convincing arguments to change my mind. What you are

suggesting is not

Post by Robert Collins
what 'most' windows installers do, it is not flexible, it is a step
backwards in approach, and a proper solution is not that hard to do!

What you are suggesting is akin to Windows installers run
batch files in
the background?

No, I've not mentioned batch files or shell scripts, just data driven
and interpretation.

I
heard your point regarding the backend data-driven support,
but lets be
serious, that kind of functionality is months away.

I'm not talking backend at this point, just something contained in the
package that gets presented to the user in some fashion. It can be 100%
GUI without any complaints from me. After all - that is what the users
expect.

Fine, how's this,
I'll rip out
the specific references to cygwin.bat and instead have setup
parse the ini
for what it should display in that last window and how many it should
display. This is how installishield and others do it. How's
that for a
solution?

Much better. How about this tweak:
Packages extract a file - lets call it
'/var/setup/setup-shortcuts/packagename.icons

Parse that file for shortcut icons to offer to create. Each icon will
need:
* Name to give the shortcut
* Location to place it (i.e. %DESKTOP% | %STARTMENU%/subpath | / (to
place in cygwin root dir))
* Target to point to (i.e. /usr/X11R6/...

So a format like
===
"Name of shortcut1" "location of shortcut 1" "target or shortcut 1"
"Name of shortcut2" "location of shortcut 2" "target or shortcut 2"
===

Makes sense to me.

Cheers,
Nicholas
P.S. My damn keyboard is dying... Also, do I need a debug version of
setup.exe from you or will you be satisified with output from the
non-debug version?

Uhmm, I'm building a debug version for you at the moment.

Rob

[Nicholas Wourms]

Post by Robert Collins

-----Original Message-----
Sent: Sunday, 14 July 2002 11:45 AM
Hey, you were the one who brought up debian...

Actually, I brought up the technique dpkg uses to address the same
issue. But I can understand that being misinterpreted.

Gotcha...

Post by Robert Collins

I am listening... I don't know where you got this one from,
but I respect
your membership in the Cygwin/XFree86 community.

From the "Like it or not" comment/

Well I didn't mean to imply that you didn't care.

Post by Robert Collins

Post by Robert Collins
The simple fact is, I disagree with your proposal, and you

have made no

Post by Robert Collins
convincing arguments to change my mind. What you are

suggesting is not

Post by Robert Collins
what 'most' windows installers do, it is not flexible, it is a step
backwards in approach, and a proper solution is not that hard to do!

What you are suggesting is akin to Windows installers run
batch files in
the background?

No, I've not mentioned batch files or shell scripts, just data driven
and interpretation.

I
heard your point regarding the backend data-driven support,
but lets be
serious, that kind of functionality is months away.

I'm not talking backend at this point, just something contained in the
package that gets presented to the user in some fashion. It can be 100%
GUI without any complaints from me. After all - that is what the users
expect.

Fine, how's this,
I'll rip out
the specific references to cygwin.bat and instead have setup
parse the ini
for what it should display in that last window and how many it should
display. This is how installishield and others do it. How's
that for a
solution?

Packages extract a file - lets call it
'/var/setup/setup-shortcuts/packagename.icons
Parse that file for shortcut icons to offer to create. Each icon will
* Name to give the shortcut
* Location to place it (i.e. %DESKTOP% | %STARTMENU%/subpath | / (to
place in cygwin root dir))
* Target to point to (i.e. /usr/X11R6/...
So a format like
===
"Name of shortcut1" "location of shortcut 1" "target or shortcut 1"
"Name of shortcut2" "location of shortcut 2" "target or shortcut 2"
===
Makes sense to me.

Yup, now to read up on the setup code and figure out how best to do this.

Post by Robert Collins

P.S. My damn keyboard is dying... Also, do I need a debug version of
setup.exe from you or will you be satisified with output from the
non-debug version?

Uhmm, I'm building a debug version for you at the moment.

Thanks, just checking to make sure, as it is almost 10pm here (I'm sure it
is like 10am there) :-)

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

[Robert Collins]

-----Original Message-----
Sent: Sunday, 14 July 2002 12:15 PM

Post by Robert Collins
* Name to give the shortcut
* Location to place it (i.e. %DESKTOP% | %STARTMENU%/subpath | / (to
place in cygwin root dir))
* Target to point to (i.e. /usr/X11R6/...

I forgot to mention: doing it this way setup can take care for all users
vs this user.

Post by Robert Collins
So a format like
===
"Name of shortcut1" "location of shortcut 1" "target or shortcut 1"
"Name of shortcut2" "location of shortcut 2" "target or shortcut 2"
===
Makes sense to me.

Yup, now to read up on the setup code and figure out how best
to do this.

Look in desktop.cc. We simply need to
1) add a parser for the file. (bison + flex or custom, I'm open to
either)
2) build a list of icons to prompt.
3) for now - until bash/cygwin gets a data file in it - add the current
icons to the tail of the list if they are not present
4) iterate through the list to build the dialog contents.
5) process the results.

I'd suggest that the first step is to convert the existing code to a
list based approach, and then get that tested and committed to HEAD.
Following that we add the file parsing to create the list - divide and
conquer.

Rob

[Charles Wilson]

Better hold off on that patch, Nicholas -- it's opposite of the
direction Robert wants to go. Setup should be , itself, as generic as
possible, and all actions driven by external data.

(granted, I haven't been reading this thread, so I might've missed
something...like discussion of the mkshortcut tool in cygutils...)

--Chuck

Post by Nicholas Wourms

Post by Jehan
I forgot to attach the "X.ico" file. It's not the best in the world but
I guess it will do (it's the same I sent you with the systray patch a
while ago). It is to be installed in /usr/X11R6/bin (or you have to
modify the script)
Jehan
ATTACHMENT part 2 image/x-icon name=X.ico

Jehan,
If you search the archives, others have already made icons ready for you
use :). Meanwhile, I've been thinking about this and looking at the
setup.exe code. If no-one minds, I'm going to generate and submit a patch
that has setup.exe do all the shortcut stuff. Though your bat file is
still useful. I wonder why not just can all the dos stuff by having the
batch file call bash which then calls startxwin.sh? One file is *much*
easier to maintain then two. Anywho, let me know your thoughts on this..
Cheers,
Nicholas
P.S. - Robert that goes for you too...
__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

[Nicholas Wourms]

Post by Charles Wilson
Better hold off on that patch, Nicholas -- it's opposite of the
direction Robert wants to go. Setup should be , itself, as generic as
possible, and all actions driven by external data.
(granted, I haven't been reading this thread, so I might've missed
something...like discussion of the mkshortcut tool in cygutils...)

Post by Nicholas Wourms

Post by Jehan
I forgot to attach the "X.ico" file. It's not the best in the world

but

Post by Nicholas Wourms

Post by Jehan
I guess it will do (it's the same I sent you with the systray patch a
while ago). It is to be installed in /usr/X11R6/bin (or you have to
modify the script)
Jehan
ATTACHMENT part 2 image/x-icon name=X.ico

Jehan,
If you search the archives, others have already made icons ready for

you

Post by Nicholas Wourms
use :). Meanwhile, I've been thinking about this and looking at the
setup.exe code. If no-one minds, I'm going to generate and submit a

patch

Post by Nicholas Wourms
that has setup.exe do all the shortcut stuff. Though your bat file is
still useful. I wonder why not just can all the dos stuff by having

the

Post by Nicholas Wourms
batch file call bash which then calls startxwin.sh? One file is

*much*

Post by Nicholas Wourms
easier to maintain then two. Anywho, let me know your thoughts on

this..

Post by Nicholas Wourms
Cheers,
Nicholas
P.S. - Robert that goes for you too...

Chuck,

For crying out loud, 95% of the installers out there create shortcuts for
the user in the startmenu and on the desktop. Why is this such a bad
thing for setup.exe to do? What does external data have to do with the
price of potatos? Seriously, I'm proposing a "simple" solution which is
the norm for most installers. Where have I gone astray?

Cheers,
Nicholas


__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

[Robert Collins]

-----Original Message-----
Sent: Sunday, 14 July 2002 10:29 AM
Chuck,
For crying out loud, 95% of the installers out there create
shortcuts for
the user in the startmenu and on the desktop. Why is this such a bad
thing for setup.exe to do? What does external data have to
do with the
price of potatos? Seriously, I'm proposing a "simple"
solution which is
the norm for most installers. Where have I gone astray?

Because simple solutions often increase coupling, wheres a more thought
out solution decreases coupling.

Also, I know you are subscribed to cygwin-apps, and I just posted there
just a couple of days ago about wanting to remove the hardcoded stuff
from setup.exe.

Rob

[Jehan]

Post by Nicholas Wourms
If you search the archives, others have already made icons ready for you
use :).

Well, I had this one for quite a while already.

Post by Nicholas Wourms
I wonder why not just can all the dos stuff by having the
batch file call bash which then calls startxwin.sh? One file is *much*
easier to maintain then two. Anywho, let me know your thoughts on this..

That would be nice I agree. But for what I see on this mailing list,
lots of people have problems with startxwin.sh (.xinitrc and .Xautorithy
stuff) while very few people complain about startxwin.bat. So until we
can have startxwin.sh to work as is for most people, I think it's better
to stick with the batch file for now.

Jehan

[Nicholas Wourms]

Post by Jehan

Post by Nicholas Wourms
If you search the archives, others have already made icons ready for

you

Post by Nicholas Wourms
use :).

Well, I had this one for quite a while already.

Post by Nicholas Wourms
I wonder why not just can all the dos stuff by having the
batch file call bash which then calls startxwin.sh? One file is

*much*

Post by Nicholas Wourms
easier to maintain then two. Anywho, let me know your thoughts on

this..
That would be nice I agree. But for what I see on this mailing list,
lots of people have problems with startxwin.sh (.xinitrc and .Xautorithy
stuff) while very few people complain about startxwin.bat. So until we
can have startxwin.sh to work as is for most people, I think it's better
to stick with the batch file for now.

You are mistaking "startx" for "startxwin.sh". startxwin.sh is basically
the same thing as startxwin.bat, but without all the nasty path
conversions and soforth. Look again, it has nothing to do with .xinitrc
and .Xauthority.

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

[Jehan]

Post by Nicholas Wourms

Post by Jehan

Post by Nicholas Wourms
If you search the archives, others have already made icons ready for

you

Post by Nicholas Wourms
use :).

Well, I had this one for quite a while already.

Post by Nicholas Wourms
I wonder why not just can all the dos stuff by having the
batch file call bash which then calls startxwin.sh? One file is

*much*

Post by Nicholas Wourms
easier to maintain then two. Anywho, let me know your thoughts on

this..
That would be nice I agree. But for what I see on this mailing list,
lots of people have problems with startxwin.sh (.xinitrc and .Xautorithy
stuff) while very few people complain about startxwin.bat. So until we
can have startxwin.sh to work as is for most people, I think it's better
to stick with the batch file for now.

You are mistaking "startx" for "startxwin.sh". startxwin.sh is basically
the same thing as startxwin.bat, but without all the nasty path
conversions and soforth. Look again, it has nothing to do with .xinitrc
and .Xauthority.

One would think so but no. I have an old .Xauthority from a linux
account. If I use this one and run X with startxwin.sh, I get a bunch of

Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified
xsetroot: unable to open display ':0.0'

for each application I try to run.
If I use an empty .Xauthority, then everything works fine. Well, not
everything actually but at least I have xterm starting. I don't know
what differs between the shell and the batch version of startxwin, but
there is definitely something.

Jehan

[Nicholas Wourms]

Post by Jehan

Post by Nicholas Wourms

Post by Jehan

Post by Nicholas Wourms
If you search the archives, others have already made icons ready for

you

Post by Nicholas Wourms
use :).

Well, I had this one for quite a while already.

Post by Nicholas Wourms
I wonder why not just can all the dos stuff by having the
batch file call bash which then calls startxwin.sh? One file is

*much*

Post by Nicholas Wourms
easier to maintain then two. Anywho, let me know your thoughts on

this..
That would be nice I agree. But for what I see on this mailing list,
lots of people have problems with startxwin.sh (.xinitrc and

.Xautorithy

Post by Nicholas Wourms

Post by Jehan
stuff) while very few people complain about startxwin.bat. So until we
can have startxwin.sh to work as is for most people, I think it's

better

Post by Nicholas Wourms

Post by Jehan
to stick with the batch file for now.

You are mistaking "startx" for "startxwin.sh". startxwin.sh is

basically

Post by Nicholas Wourms
the same thing as startxwin.bat, but without all the nasty path
conversions and soforth. Look again, it has nothing to do with

.xinitrc

Post by Nicholas Wourms
and .Xauthority.

One would think so but no. I have an old .Xauthority from a linux
account. If I use this one and run X with startxwin.sh, I get a bunch of
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified
xsetroot: unable to open display ':0.0'
for each application I try to run.
If I use an empty .Xauthority, then everything works fine. Well, not
everything actually but at least I have xterm starting. I don't know
what differs between the shell and the batch version of startxwin, but
there is definitely something.
Jehan

Well this is obviously a bug in X and needs to be fixed. I dunno, maybe
I'm wrong, but it just seems a bit silly to have two identical scripts for
two different situations. I'm of the camp that loves reusable code...

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

[Jehan]

Post by Nicholas Wourms
I dunno, maybe
I'm wrong, but it just seems a bit silly to have two identical scripts for
two different situations.

I agree with that.

Post by Nicholas Wourms
I'm of the camp that loves reusable code...

Yeah right, like modifying setup.exe for the XWin shortcut? ;)

Jehan

[Nicholas Wourms]

Post by Jehan

Post by Nicholas Wourms
I dunno, maybe
I'm wrong, but it just seems a bit silly to have two identical scripts

for

Post by Nicholas Wourms
two different situations.

I agree with that.

Post by Nicholas Wourms
I'm of the camp that loves reusable code...

Yeah right, like modifying setup.exe for the XWin shortcut? ;)

Exactly, setup.exe already contained classes for doing all of that. So it
does fit the definition of using reusable code. This was not to say that
my code would be reusable in of itself.

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

[Nicholas Wourms]

Post by Nicholas Wourms

Post by Nicholas Wourms

Post by Nicholas Wourms

Post by Nicholas Wourms
Excuse me? All I was suggesting is to reword the final setup screen

to

Post by Nicholas Wourms

Post by Nicholas Wourms

Post by Nicholas Wourms
-Create Icon on Desktop for Cygwin Command Prompt
-Create Icon on Desktop for Cygwin/XFree86
-Add Icon to Start Menu for Cygwin Command Prompt
-Add Icon to Start Menu for Cygwin/XFree86
Then have setup create the shortcuts in the same fasion it does

already.

Post by Nicholas Wourms
Eventually, I'd like to have it gray-out the check boxes for
Cygwin/XFree86 if it is not already installed. How is this not data
driven? Isn't this what the setup program is for? The last time I
checked, most Windows installers handled the shortcut creation.

Robert is right Nicholas (oh no not this guy again! :p). The question

is

Post by Nicholas Wourms

Post by Nicholas Wourms
why add XFree to the list and not SSH and RSH, and Lynx, and, and,
and....
And since we can create the shortcuts via the postinstall script, why

do

Post by Nicholas Wourms

Post by Nicholas Wourms
you want to add this feature to setup.exe?
The script is not very cool looking, I give you that, but it's far

more

Post by Nicholas Wourms

Post by Nicholas Wourms
flexible.

No he isn't. There are two ways that someone will interface with

Cygwin,

Post by Nicholas Wourms
via Console or via X11. The other apps you mention are Console apps,
therefore you can't expect them to have shortcuts.

Then I give you rxvt. I give you csh (afterall, cygwin.bat only starts
bash)
And just for the sake of arguing (I love that if you didn't notice :)),
XWin can also be launch from the console.
Moreover some people install cygwin just to run ssh (see
http://www.networksimplicity.com/openssh/ which is a specific version of
cygwin/openssh). So they may want to have a shortcut that launches both
at the same time. Double-click on the shortcut and.. hop here is your
ssh shell.
While I agree that this is problably less common than launch XWin, I
still think that X should not be treates in a special way. Actually, I
think that even cygwin should no treated in a special way by setup.exe.
Afterall, cygwin doesn't seem to require anymore special attention than
X, SSH or lynx.

Post by Nicholas Wourms
However X is much more
than an Application, it is an interface. Therefore, one can argue

that it

Post by Nicholas Wourms
deserves setup.exe making it a shortcut just as much as setup.exe

making

Post by Nicholas Wourms
the console a shortcut.

I'll just repeat what I said above: I actually argue that cygwin
*doesn't* deserve setup.exe making it a shortcut (but it seems than
Robert is trying to change that). After all, cygwin.bat only runs bash.

Post by Nicholas Wourms
Lastly, something you will not disagree with,
ALOT of people want to use just X and not the console, especially for
doing XDMCP. This is even more reason why setup.exe should make the
shortcut.

Well, my new script does create a shortcut. So I'll reiterate what I
said in a previous post: what's wrong with the script? What is better
with having setup.exe creating the shortcut instead of the script?

Because scripts are unreliable. Because users are stupid. Because people
like to have a GUI checkbox over a text console prompting them for input.
You are admirable for defending your script, but the fact of the matter is
that people prefer the graphical setup. Why? Well look at the the
various linuxes out there, they are, for the most part, migrating to a
graphical install. They don't rely on crummy shell scripts any more. I
think you are missing the original point, Slashdot did an article on
Cygwin/XFree86, not Cygwin/OpenSSH, not Cygwin/RXVT. The point is that X
is a special interface that deserves a special shortcut that is made by
setup.exe. Until we have a data-driven database system which can interact
with setup.exe and respond to user input, this is probably the best bet.
But realize that I'm not trying to tell people what to do, I'm just
strongly voicing my opinion.

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

[Jehan]

Post by Nicholas Wourms
Because scripts are unreliable. Because users are stupid. Because people
like to have a GUI checkbox over a text console prompting them for input.
You are admirable for defending your script, but the fact of the matter is
that people prefer the graphical setup. Why? Well look at the the
various linuxes out there, they are, for the most part, migrating to a
graphical install. They don't rely on crummy shell scripts any more.

Hmm, I'm not sure about that. A lot of application uses GUI as a front
end to script and command line tools.

I

Post by Nicholas Wourms
think you are missing the original point, Slashdot did an article on
Cygwin/XFree86, not Cygwin/OpenSSH, not Cygwin/RXVT. The point is that X
is a special interface that deserves a special shortcut that is made by
setup.exe.

So before Slashdot, XWin didn't deserve the shortcut? And for what I saw
in the cygwin mailing list, some people want rxvt to be the default.
Currently, I have two shortcuts, one for rxvt and one for bash. If the
xlauncher comes, we will want a shortcut for it because people won't
have to configure X by hand, they will have a GUI.

Post by Nicholas Wourms
Until we have a data-driven database system which can interact
with setup.exe and respond to user input, this is probably the best bet.

I fear I disagree. We have a way to creat shortcuts already. It's not
pretty but it works. This way is also flexible because it doesn't
prevent other applications to do the same.
So instead of creating another way (even if it's simple) to create
shortcuts, that isn't even flexible, I would say the best bet is to
focus on a data-driven GUI.

Post by Nicholas Wourms
But realize that I'm not trying to tell people what to do, I'm just
strongly voicing my opinion.

Good because you can't! Sorry! *grin*.

Jehan