Re: Bug in startXwin.bat
Larry Hall (Cygwin X) wrote: Linda Walsh wrote: Larry Hall (Cygwin X) wrote: Linda Walsh wrote: Larry Hall (Cygwin X) wrote: Linda Walsh wrote: The startxwin.sh script works, but startxwin.bat does not work if your Cygwin installation isn't in the default location. As Larry and others have pointed out, this is because cmd.exe batch files cannot know where Cygwin is installed. So startxwin.bat hardcodes the default installation location of Cygwin in it (SET CYGWIN_ROOT=\cygwin). Linda and http://sourceware.org/ml/cygwin-xfree/2009-01/msg00173.html http://sourceware.org/ml/cygwin-xfree/2009-02/msg00052.html they all belong to the case where 1. s/he installed Cygwin in a non-default location, 2. read Cygwin/X FAQ 3.3. I can't find startxwin.bat to start the X server, and 3. tried the Start Menu item Cygwin-X/XWin Server. Here are two possible solutions for this case, each with a patch. The first one sets CYGWIN_ROOT to the parent of /bin where this startxwin.bat is installed. It uses cmd.exe batch parameter syntax to get the path value. The documentation for this cryptic parameter syntax can be found in http://technet.microsoft.com/en-us/library/cc755880.aspx http://www.computerhope.com/sethlp.htm REMarks are just remarks and can be deleted if necessary. The second one avoids using startxwin.bat at all. It invokes /usr/bin/run.exe to run /bin/bash to run /usr/bin/startxwin.sh. Possibly, /usr/bin/startx can be used instead of startxwin.sh, but I picked startxwin.sh because it contains the code to delete /tmp/.X11-unix/X0. This solution is better than the first in that no cmd.exe batch file is used, but is worse in that two black cmd.exe windows flash and disappear before XWin starts up. These two are not the ideal solution, but at least they work for the above case. I hope these patches help and get thoughtfully considered. -- neomjp diff -us /usr/bin/startxwin.bat /usr/bin/startxwin.bat.new.bat --- /usr/bin/startxwin.bat 2009-01-19 15:43:42.00100 +0900 +++ /usr/bin/startxwin.bat.new.bat 2009-02-14 05:52:03.84375 +0900 @@ -3,21 +3,24 @@ 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/X, 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 +REM The following assignment to the CYGWIN_ROOT environment variable +REM assumes that this batch file is installed in /bin . (In +REM default Cygwin installation, this /bin is also mounted as +REM /usr/bin .) CYGWIN_ROOT is first set to the Windows format +REM drive letter (~d) and parent path (p) of this batch file (%0). +REM Then, the last four characters (\bin) are removed. +REM + +SET CYGWIN_ROOT=%~dp0 +SET CYGWIN_ROOT=%CYGWIN_ROOT:~0,-4% + +REM +REM If you move/copy this batch file to another place, you need to +REM set CYGWIN_ROOT explicitly to the Windows format path of the +REM directory where Cygwin is installed, as in an example below. +REM +REM SET CYGWIN_ROOT=C\:cygwin -SET CYGWIN_ROOT=\cygwin SET RUN=%CYGWIN_ROOT%\bin\run -p /usr/bin SET PATH=.;%CYGWIN_ROOT%\bin;%PATH% diff -u /etc/postinstall/xinit.sh /etc/postinstall/xinit.sh.new --- /etc/postinstall/xinit.sh 2009-01-19 15:43:42.00100 +0900 +++ /etc/postinstall/xinit.sh.new 2009-02-14 06:04:24.140625000 +0900 @@ -1,2 +1,2 @@ /usr/bin/mkdir -p $(/usr/bin/cygpath -AP)/Cygwin-X -/usr/bin/mkshortcut -AP -i /usr/bin/XWin.exe -n Cygwin-X/XWin Server -w -a /usr/bin/startxwin.bat /usr/bin/run.exe +/usr/bin/mkshortcut -AP -i /usr/bin/XWin.exe -n Cygwin-X/XWin Server -w /usr/bin -a /bin/bash -l -c /usr/bin/startxwin.sh /usr/bin/run.exe -- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Bug in startXwin.bat
Linda Walsh cyg...@tlinx.org writes: The startxwin.sh script works, but startxwin.bat does not work if your Cygwin installation isn't in the default location. My cygwin lives in D: and X starts from bat file. , | SET CYGWIN_ROOT=\home\installations\cygwin ` Or did I completely miss your point? -- Manish -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Bug in startXwin.bat
The startxwin.sh script works, but startxwin.bat does not work if your Cygwin installation isn't in the default location. You could use mount -p (presuming your cygwin\bin is in your windows path, as mine is). If not, need to look in the registry: \HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\cygdrive prefix -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Bug in startXwin.bat
Linda Walsh wrote: The startxwin.sh script works, but startxwin.bat does not work if your Cygwin installation isn't in the default location. You could use mount -p (presuming your cygwin\bin is in your windows path, as mine is). If not, need to look in the registry: \HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\cygdrive prefix No, you don't need to look in the registry. There's nothing there that 'mount' won't tell you. Forget about the registry. You'll be better off, especially when Cygwin 1.7 is released. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 429-6305 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Bug in startXwin.bat
Larry Hall (Cygwin X) wrote: Linda Walsh wrote: The startxwin.sh script works, but startxwin.bat does not work if your Cygwin installation isn't in the default location. You could use mount -p (presuming your cygwin\bin is in your windows path, as mine is). If not, need to look in the registry: \HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\cygdrive prefix No, you don't need to look in the registry. There's nothing there that 'mount' won't tell you. Forget about the registry. You'll be better off, especially when Cygwin 1.7 is released. - Um...you sure about that? how do you run 'mount' if you don't know what the cygdrive prefix is? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Bug in startXwin.bat
Linda Walsh wrote: Larry Hall (Cygwin X) wrote: Linda Walsh wrote: The startxwin.sh script works, but startxwin.bat does not work if your Cygwin installation isn't in the default location. You could use mount -p (presuming your cygwin\bin is in your windows path, as mine is). If not, need to look in the registry: \HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\cygdrive prefix No, you don't need to look in the registry. There's nothing there that 'mount' won't tell you. Forget about the registry. You'll be better off, especially when Cygwin 1.7 is released. - Um...you sure about that? how do you run 'mount' if you don't know what the cygdrive prefix is? Linda, please don't run the same thread on two different lists. If you want to talk about this here, kill the thread that you started on the main list. As for the answer to your question, I'm quite sure about my answer and have pointed out the flaw in your question in the thread on the main list. I expect that we're done with the threads on both lists now? -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 429-6305 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Bug in startXwin.bat
Larry Hall (Cygwin X) wrote: Linda Walsh wrote: Larry Hall (Cygwin X) wrote: Linda Walsh wrote: The startxwin.sh script works, but startxwin.bat does not work if your Cygwin installation isn't in the default location. You could use mount -p (presuming your cygwin\bin is in your windows path, as mine is). If not, need to look in the registry: \HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\cygdrive prefix No, you don't need to look in the registry. There's nothing there that 'mount' won't tell you. Forget about the registry. You'll be better off, especially when Cygwin 1.7 is released. - Um...you sure about that? how do you run 'mount' if you don't know what the cygdrive prefix is? Linda, please don't run the same thread on two different lists. If you want to talk about this here, kill the thread that you started on the main list. Larry -- The reason I changed forums was that the TOPIC/SUBJECT changed. It went from my finding a bug in the Cygwin Xserver's startxwin.bat script (something appropriate for the cygwin-xfree list) to a more general question of how one would solve the problem of finding the cygwin prefix in a windows batchfile. Just because you can't answer the question without circular logic is no reason to get upset. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Bug in startXwin.bat
Linda Walsh wrote: Larry Hall (Cygwin X) wrote: Linda Walsh wrote: Larry Hall (Cygwin X) wrote: Linda Walsh wrote: The startxwin.sh script works, but startxwin.bat does not work if your Cygwin installation isn't in the default location. You could use mount -p (presuming your cygwin\bin is in your windows path, as mine is). If not, need to look in the registry: \HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\cygdrive prefix No, you don't need to look in the registry. There's nothing there that 'mount' won't tell you. Forget about the registry. You'll be better off, especially when Cygwin 1.7 is released. - Um...you sure about that? how do you run 'mount' if you don't know what the cygdrive prefix is? Linda, please don't run the same thread on two different lists. If you want to talk about this here, kill the thread that you started on the main list. Larry -- The reason I changed forums was that the TOPIC/SUBJECT changed. This is perfectly reasonable, except you kept both threads running. It went from my finding a bug in the Cygwin Xserver's startxwin.bat script (something appropriate for the cygwin-xfree list) to a more general question of how one would solve the problem of finding the cygwin prefix in a windows batchfile. Actually, that's not the question you asked, though I'll concede that this is what you meant to ask. And I answered that on the main list. For completeness, I'll paraphrase it here - there's no good way. Just because you can't answer the question without circular logic is no reason to get upset. While other statements of yours have been understandable, even if they were in error, this one makes no sense so I won't respond to it. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 429-6305 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Bug in startXwin.bat
Larry Hall (Cygwin X) wrote: Linda Walsh wrote: Larry Hall (Cygwin X) wrote: Linda Walsh wrote: Larry Hall (Cygwin X) wrote: Linda Walsh wrote: The startxwin.sh script works, but startxwin.bat does not work if your Cygwin installation isn't in the default location. You could use mount -p (presuming your cygwin\bin is in your windows path, as mine is). If not, need to look in the registry: \HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\cygdrive prefix No, you don't need to look in the registry. There's nothing there that 'mount' won't tell you. Forget about the registry. You'll be better off, especially when Cygwin 1.7 is released. - Um...you sure about that? how do you run 'mount' if you don't know what the cygdrive prefix is? Linda, please don't run the same thread on two different lists. If you want to talk about this here, kill the thread that you started on the main list. Larry -- The reason I changed forums was that the TOPIC/SUBJECT changed. This is perfectly reasonable, except you kept both threads running. Not exactly. They were different posts -- I realized it was a more general topic after first responding to the xfree. It went from my finding a bug in the Cygwin Xserver's startxwin.bat script (something appropriate for the cygwin-xfree list) to a more general question of how one would solve the problem of finding the cygwin prefix in a windows batchfile. Actually, that's not the question you asked, though I'll concede that this is what you meant to ask. And I answered that on the main list. For completeness, I'll paraphrase it here - there's no good way. AH HAH! Thank-you. My original intent was simply to report a bug in the Cygwin-X startup script startxwin.bat that you told me (indirectly via the FAQ) to use. My first idea was to use mount -p as you suggest. However, I immediately realized that mount wouldn't be available if you were not already in the Cygwin environment. Just because you can't answer the question without circular logic is no reason to get upset. While other statements of yours have been understandable, even if they were in error, this one makes no sense so I won't respond to it. --- Probably somewhat a case of projection... ;^ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
RE: Bug in startxwin.bat after installing with setup.exe in win98SE
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
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
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 See the Cygwin/XFree86 FAQ for more information: 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 information: REM http://xfree86.cygwin.com/docs/faq/cygwin-xfree-faq.html#q-error-font-eof 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 1 -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
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
--- Jehan [EMAIL PROTECTED] wrote: 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 See the Cygwin/XFree86 FAQ for more information: 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 information: REM http://xfree86.cygwin.com/docs/faq/cygwin-xfree-faq.html#q-error-font-eof 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 1 -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
RE: Bug in startxwin.bat after installing with setup.exe in win98SE
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Harold L Hunt Sent: Saturday, 13 July 2002 6:38 AM To: [EMAIL PROTECTED] Subject: Re: Bug in startxwin.bat after installing with setup.exe in win98SE Jehan [EMAIL PROTECTED] said: Harold L Hunt wrote: 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? 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
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
Nicholas Wourms wrote: 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) 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. 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. 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 if ( $?PATH ) then setenv PATH ${PATH}:/usr/X11R6/bin else setenv PATH :/usr/X11R6/bin endif export PATH=${PATH}:/usr/X11R6/bin
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
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
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
Robert Collins wrote: - 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
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
Robert Collins wrote: 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
RE: Bug in startxwin.bat after installing with setup.exe in win98SE
-Original Message- From: Jehan [mailto:[EMAIL PROTECTED]] Sent: Sunday, 14 July 2002 8:18 AM To: Robert Collins Subject: Re: Bug in startxwin.bat after installing with setup.exe in win98SE Robert Collins wrote: 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
RE: Bug in startxwin.bat after installing with setup.exe in win98SE
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of 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? No. Use `mount -w /` in your postinstall shell script. Rob
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
Robert Collins wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of 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? No. Use `mount -w /` in your postinstall shell script. You mean `cygpath -w /` I guess. Mount doesn't have an option -w. Jehan
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
Robert Collins wrote: -Original Message- From: Jehan [mailto:[EMAIL PROTECTED]] Sent: Sunday, 14 July 2002 8:18 AM To: Robert Collins Subject: Re: Bug in startxwin.bat after installing with setup.exe in win98SE Robert Collins wrote: 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 #!/bin/bash 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 See the Cygwin/XFree86 FAQ for more information: 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 information: REM http://xfree86.cygwin.com/docs/faq/cygwin-xfree-faq.html#q-error-font-eof 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 1 -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 # Create Desktop and Start menu icons while /bin/true; do read -p Do you want to add an icon for Cygwin/Xfree on the Desktop? [y|n] ANSWER case $ANSWER
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
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
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
--- Jehan [EMAIL PROTECTED] wrote: 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
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
--- Charles Wilson [EMAIL PROTECTED] wrote: 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...) Nicholas Wourms wrote: --- Jehan [EMAIL PROTECTED] wrote: 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... 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
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
Nicholas Wourms wrote: 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. 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
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
Nicholas Wourms wrote: --- Jehan [EMAIL PROTECTED] wrote: If you search the archives, others have already made icons ready for you use :). Well, I had this one for quite a while already. 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
RE: Bug in startxwin.bat after installing with setup.exe in win98SE
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Nicholas Wourms 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
RE: Bug in startxwin.bat after installing with setup.exe in win98SE
-Original Message- From: Nicholas Wourms [mailto:[EMAIL PROTECTED]] 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
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
--- Jehan [EMAIL PROTECTED] wrote: Nicholas Wourms wrote: --- Jehan [EMAIL PROTECTED] wrote: If you search the archives, others have already made icons ready for you use :). Well, I had this one for quite a while already. 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. 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
RE: Bug in startxwin.bat after installing with setup.exe in win98SE
--- Robert Collins [EMAIL PROTECTED] wrote: -Original Message- From: Nicholas Wourms [mailto:[EMAIL PROTECTED]] Sent: Sunday, 14 July 2002 10:24 AM 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. 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 (*). 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
RE: Bug in startxwin.bat after installing with setup.exe in win98SE
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Nicholas Wourms 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
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
Nicholas Wourms wrote: --- Jehan [EMAIL PROTECTED] wrote: Nicholas Wourms wrote: --- Jehan [EMAIL PROTECTED] wrote: If you search the archives, others have already made icons ready for you use :). Well, I had this one for quite a while already. 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. 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
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
Nicholas Wourms wrote: 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 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. 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. 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
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
--- Jehan [EMAIL PROTECTED] wrote: Nicholas Wourms wrote: --- Jehan [EMAIL PROTECTED] wrote: Nicholas Wourms wrote: --- Jehan [EMAIL PROTECTED] wrote: If you search the archives, others have already made icons ready for you use :). Well, I had this one for quite a while already. 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. 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 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
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
Nicholas Wourms wrote: --- Robert Collins [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Nicholas Wourms 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... 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. 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. 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
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
On Sun, Jul 14, 2002 at 07:44:51AM +1000, Robert Collins wrote: 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)
RE: Bug in startxwin.bat after installing with setup.exe in win98SE
Bernard, 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. 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 Bernard A Badger [EMAIL PROTECTED] said: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Harold L Hunt Sent: Friday, July 12, 2002 10:27 AM To: willichnicht habichnet; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Bug in startxwin.bat after installing with setup.exe in win98SE First: Wrong mailing list. Send all Cygwin/XFree86 questions to [EMAIL PROTECTED] I have redirected this discussion to the correct mailing list, but be careful to remove [EMAIL PROTECTED] 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). 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 willichnicht habichnet [EMAIL PROTECTED] said: 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
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
Jehan [EMAIL PROTECTED] said: Harold L Hunt wrote: 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\binchdir 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. 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. 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. 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
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
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. From: Harold L Hunt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Bug in startxwin.bat after installing with setup.exe in win98SE Date: Fri, 12 Jul 2002 16:37:56 EDT Jehan [EMAIL PROTECTED] said: Harold L Hunt wrote: 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\binchdir 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. 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. 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. 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
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
Thomas Chadwick wrote: 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
Re: Bug in startxwin.bat after installing with setup.exe in win98SE
On Fri, Jul 12, 2002 at 05:17:47PM -0400, Harold L Hunt wrote: 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