From: Keith M. <kei...@to...> - 2005-10-03 13:46:05
|
> I just realized how to find MSYS when you do not know if it is installed > and where ;-) -- Since this could be a common problem when using MSYS > for different automatic purposes (like a part of an installation) and > maybe there are more people like me that are slow to find out how I give > the recipe here: > > Look in the Windows Registry at > > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ > > There should be a key named something like > > MSYS-1.0_is1 > > if MSYS is installed... I wouldn't rely on this hack. AFAIK, MSYS itself makes no use of the Windoze Registry whatsoever -- as Leif W. points out, those apparently MSYS related keys are created by whatever installer was used to install MSYS; this is liable to change at any time, and indeed, some users may install from tarballs, without using an installer at all. If you need to check for MSYS, and find its installation root from a package configurator running within an MSYS shell process:-- <script> MSYS_ROOT_AS_WIN32_PATH=`exec 2>/dev/null; cd / && pwd -W` [ echo "$MSYS_ROOT_AS_WIN32_PATH" | grep ':' >/dev/null 2>&1 ] \ && HAVE_MSYS_INSTALLED=YES \ || HAVE_MSYS_INSTALLED=NO </script> should provide a reliable method for determining this. HTH. Regards, Keith. |
From: Keith M. <kei...@to...> - 2005-10-03 14:37:05
|
Earlier, I wrote: > If you need to check for MSYS, and find its installation root from > a package configurator running within an MSYS shell process:-- > > <script> > MSYS_ROOT_AS_WIN32_PATH=`exec 2>/dev/null; cd / && pwd -W` > [ echo "$MSYS_ROOT_AS_WIN32_PATH" | grep ':' >/dev/null 2>&1 ] \ > && HAVE_MSYS_INSTALLED=YES \ > || HAVE_MSYS_INSTALLED=NO > </script> And, of course, that has an embedded `Deliberate Mistake'(TM); remove the pair of square brackets from the second line of the script, to make it work correctly. Regards, Keith. |
From: <jw...@bi...> - 2005-10-03 18:29:43
|
Sorry guys. That Strategy is called MAD: Mutually Assured Destruction. "Ignore history and you are doomed to relive it". It may not be illegal reverse engineering practice in the strictest sence. But it is still too close for comfort and bad practice. Microsoft software design engineers use Data flow and Process Flow and UML: Unified Modelling Language to create these "rat-runs". It actually involves the exhaustive searching of a maze of corridors to find an Exit. Human intelligence is not up to it. To get an idea of the effort involved download the free SqueakNOS (No Operating System) image onto a floppy. Then at the cursor enter say: 20 fatorial Then keep incrementing the value up or down. Just how mush time do you have? and then you still have no certainty. It is just not good logical thinking. Sorry, but not thinking at all, "merely a cartic of the common understanding". Now search on "what is carthic". If it is any comfort, I still do it myself. JW ---- Leif W <war...@us...> wrote: > > From: "Lennart Borgman" <len...@st...> > > Sent: 2005 October 03 Monday 08:24 > > > > >I just realized how to find MSYS when you do not know if it is > >installed > > [snip] > > > Look in the Windows Registry at > > > > > > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ > > > > There should be a key named something like > > > > MSYS-1.0_is1 > > > > if MSYS is installed. This in its turn has a string value with the > > name > > > > Inno Setup: App Path > > > > which tells where MSYS is installed. (Or you can look at > > UninstallString.) > > That may work fine for the current version of the installer, but the > keys and strings may change for different versions of MSYS, or different > installer tools (NSIS versus Inno Setup). Maybe there's a more generic > approach, or an installer convention that could be conceived? Need to > know if it's installed, perhaps status (e.g. ok, not configured, broken > or half installed), location (drive or unc and path), and for MinGW with > many optional components, perhaps the name of a file containing what's > installed, along with some of this other info I mention. > > Well, of course all of this assumes MSYS was installed with an > installer, when conceivably it could be custom built and copied, or > otherwise unarchived somewhere, in which case it's just guessing at > standard path names across all drives or uncs, which is anybody's guess. > > Anyways that's all speculative on my part. > > Leif > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Mingw-msys mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-msys |
From: Lennart B. <len...@st...> - 2005-10-03 18:50:43
|
Can you please be more specific? Do you mean that this kind of looking=20 at the uninstall information is a bad thing? Sure, it is! That is why I=20 started the thread... - I want another way, but this is the only way at=20 the momenent! But practically I need a way at the moment so I have to=20 use this... The preferred way is IMHO that MSYS tells to the App Paths registry key=20 where it is. This is the way recommended by MS if I understand it correct= ly. jw...@bi... wrote: >Sorry guys. >That Strategy is called MAD: Mutually Assured Destruction. >"Ignore history and you are doomed to relive it". >It may not be illegal reverse engineering practice in the strictest senc= e. >But it is still too close for comfort and bad practice. >Microsoft software design engineers use Data flow and Process Flow and U= ML: Unified Modelling Language to create these "rat-runs".=20 >It actually involves the exhaustive searching of a maze of corridors to = find an Exit. >Human intelligence is not up to it. >To get an idea of the effort involved download the free SqueakNOS (No Op= erating System) image onto a floppy. Then at the cursor enter say: > 20 fatorial >Then keep incrementing the value up or down. >Just how mush time do you have? and then you still have no certainty. >It is just not good logical thinking.=20 >Sorry, but not thinking at all, "merely a cartic of the common understa= nding". >Now search on "what is carthic". >If it is any comfort, I still do it myself. >JW > >---- Leif W <war...@us...> wrote:=20 > =20 > >>>From: "Lennart Borgman" <len...@st...> >>>Sent: 2005 October 03 Monday 08:24 >>> >>> =20 >>> >>>I just realized how to find MSYS when you do not know if it is=20 >>>installed >>> =20 >>> >>[snip] >> >> =20 >> >>>Look in the Windows Registry at >>> >>> >>>HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall= \ >>> >>>There should be a key named something like >>> >>> MSYS-1.0_is1 >>> >>>if MSYS is installed. This in its turn has a string value with the=20 >>>name >>> >>> Inno Setup: App Path >>> >>>which tells where MSYS is installed. (Or you can look at=20 >>>UninstallString.) >>> =20 >>> >>That may work fine for the current version of the installer, but the=20 >>keys and strings may change for different versions of MSYS, or differen= t=20 >>installer tools (NSIS versus Inno Setup). Maybe there's a more generic= =20 >>approach, or an installer convention that could be conceived? Need to=20 >>know if it's installed, perhaps status (e.g. ok, not configured, broken= =20 >>or half installed), location (drive or unc and path), and for MinGW wit= h=20 >>many optional components, perhaps the name of a file containing what's=20 >>installed, along with some of this other info I mention. >> >>Well, of course all of this assumes MSYS was installed with an=20 >>installer, when conceivably it could be custom built and copied, or=20 >>otherwise unarchived somewhere, in which case it's just guessing at=20 >>standard path names across all drives or uncs, which is anybody's guess= =2E >> >>Anyways that's all speculative on my part. >> >>Leif >> >> >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by: >>Power Architecture Resource Center: Free content, downloads, discussion= s, >>and more. http://solutions.newsforge.com/ibmarch.tmpl >>_______________________________________________ >>Mingw-msys mailing list >>Min...@li... >>https://lists.sourceforge.net/lists/listinfo/mingw-msys >> =20 >> > > >------------------------------------------------------- >This SF.Net email is sponsored by: >Power Architecture Resource Center: Free content, downloads, discussions= , >and more. http://solutions.newsforge.com/ibmarch.tmpl >_______________________________________________ >Mingw-msys mailing list >Min...@li... >https://lists.sourceforge.net/lists/listinfo/mingw-msys > =20 > --=20 Lennart fr=C3=A5n Lund len...@st... |
From: <jw...@bi...> - 2005-10-03 23:02:28
|
Sorry Lennart. I'll pull my head in, put it down to my paranoia. I don't understand enough of the MinGW or Msys strategy to feel safe. Microsoft is coming on pretty heavy lately, and I fear it. I do Systems reverse engineering these days it is far safer. It just occured to me to remove the MinGW download. That way I can't even be tempted to look at Windows code. Regards JW ---- Lennart Borgman <len...@st...> wrote:=20 > Can you please be more specific? Do you mean that this kind of looking=20 > at the uninstall information is a bad thing? Sure, it is! That is why I= =20 > started the thread... - I want another way, but this is the only way at= =20 > the momenent! But practically I need a way at the moment so I have to=20 > use this... >=20 > The preferred way is IMHO that MSYS tells to the App Paths registry key= =20 > where it is. This is the way recommended by MS if I understand it correct= ly. >=20 >=20 >=20 > jw...@bi... wrote: >=20 > >Sorry guys. > >That Strategy is called MAD: Mutually Assured Destruction. > >"Ignore history and you are doomed to relive it". > >It may not be illegal reverse engineering practice in the strictest senc= e. > >But it is still too close for comfort and bad practice. > >Microsoft software design engineers use Data flow and Process Flow and U= ML: Unified Modelling Language to create these "rat-runs".=20 > >It actually involves the exhaustive searching of a maze of corridors to = find an Exit. > >Human intelligence is not up to it. > >To get an idea of the effort involved download the free SqueakNOS (No Op= erating System) image onto a floppy. Then at the cursor enter say: > >=0920 fatorial > >Then keep incrementing the value up or down. > >Just how mush time do you have? and then you still have no certainty. > >It is just not good logical thinking.=20 > >Sorry, but not thinking at all, "merely a cartic of the common understa= nding". > >Now search on "what is carthic". > >If it is any comfort, I still do it myself. > >JW > > > >---- Leif W <war...@us...> wrote:=20 > > =20 > > > >>>From: "Lennart Borgman" <len...@st...> > >>>Sent: 2005 October 03 Monday 08:24 > >>> > >>> =20 > >>> > >>>I just realized how to find MSYS when you do not know if it is=20 > >>>installed > >>> =20 > >>> > >>[snip] > >> > >> =20 > >> > >>>Look in the Windows Registry at > >>> > >>> > >>>HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall= \ > >>> > >>>There should be a key named something like > >>> > >>> MSYS-1.0_is1 > >>> > >>>if MSYS is installed. This in its turn has a string value with the=20 > >>>name > >>> > >>> Inno Setup: App Path > >>> > >>>which tells where MSYS is installed. (Or you can look at=20 > >>>UninstallString.) > >>> =20 > >>> > >>That may work fine for the current version of the installer, but the=20 > >>keys and strings may change for different versions of MSYS, or differen= t=20 > >>installer tools (NSIS versus Inno Setup). Maybe there's a more generic= =20 > >>approach, or an installer convention that could be conceived? Need to= =20 > >>know if it's installed, perhaps status (e.g. ok, not configured, broken= =20 > >>or half installed), location (drive or unc and path), and for MinGW wit= h=20 > >>many optional components, perhaps the name of a file containing what's= =20 > >>installed, along with some of this other info I mention. > >> > >>Well, of course all of this assumes MSYS was installed with an=20 > >>installer, when conceivably it could be custom built and copied, or=20 > >>otherwise unarchived somewhere, in which case it's just guessing at=20 > >>standard path names across all drives or uncs, which is anybody's guess= . > >> > >>Anyways that's all speculative on my part. > >> > >>Leif > >> > >> > >> > >> > >>------------------------------------------------------- > >>This SF.Net email is sponsored by: > >>Power Architecture Resource Center: Free content, downloads, discussion= s, > >>and more. http://solutions.newsforge.com/ibmarch.tmpl > >>_______________________________________________ > >>Mingw-msys mailing list > >>Min...@li... > >>https://lists.sourceforge.net/lists/listinfo/mingw-msys > >> =20 > >> > > > > > >------------------------------------------------------- > >This SF.Net email is sponsored by: > >Power Architecture Resource Center: Free content, downloads, discussions= , > >and more. http://solutions.newsforge.com/ibmarch.tmpl > >_______________________________________________ > >Mingw-msys mailing list > >Min...@li... > >https://lists.sourceforge.net/lists/listinfo/mingw-msys > > =20 > > >=20 >=20 > --=20 > Lennart > fr=C3=A5n Lund > len...@st... >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Mingw-msys mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-msys |
From: Lennart B. <len...@st...> - 2005-10-03 23:15:06
|
Thanks, now it makes sense. The installer Inno Setup that has written into the registry is open source and free. jw...@bi... wrote: >Sorry Lennart. >I'll pull my head in, put it down to my paranoia. >I don't understand enough of the MinGW or Msys strategy to feel safe. >Microsoft is coming on pretty heavy lately, and I fear it. >I do Systems reverse engineering these days it is far safer. >It just occured to me to remove the MinGW download. >That way I can't even be tempted to look at Windows code. >Regards >JW > >---- Lennart Borgman <len...@st...> wrote: > > >>Can you please be more specific? Do you mean that this kind of looking >>at the uninstall information is a bad thing? Sure, it is! That is why I >>started the thread... - I want another way, but this is the only way at >>the momenent! But practically I need a way at the moment so I have to >>use this... >> >>The preferred way is IMHO that MSYS tells to the App Paths registry key >>where it is. This is the way recommended by MS if I understand it correctly. >> >> >> >>jw...@bi... wrote: >> >> >> >>>Sorry guys. >>>That Strategy is called MAD: Mutually Assured Destruction. >>>"Ignore history and you are doomed to relive it". >>>It may not be illegal reverse engineering practice in the strictest sence. >>>But it is still too close for comfort and bad practice. >>>Microsoft software design engineers use Data flow and Process Flow and UML: Unified Modelling Language to create these "rat-runs". >>>It actually involves the exhaustive searching of a maze of corridors to find an Exit. >>>Human intelligence is not up to it. >>>To get an idea of the effort involved download the free SqueakNOS (No Operating System) image onto a floppy. Then at the cursor enter say: >>> 20 fatorial >>>Then keep incrementing the value up or down. >>>Just how mush time do you have? and then you still have no certainty. >>>It is just not good logical thinking. >>>Sorry, but not thinking at all, "merely a cartic of the common understanding". >>>Now search on "what is carthic". >>>If it is any comfort, I still do it myself. >>>JW >>> >>>---- Leif W <war...@us...> wrote: >>> >>> >>> >>> >>>>>From: "Lennart Borgman" <len...@st...> >>>>>Sent: 2005 October 03 Monday 08:24 >>>>> >>>>> >>>>> >>>>>I just realized how to find MSYS when you do not know if it is >>>>>installed >>>>> >>>>> >>>>> >>>>> >>>>[snip] >>>> >>>> >>>> >>>> >>>> >>>>>Look in the Windows Registry at >>>>> >>>>> >>>>>HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ >>>>> >>>>>There should be a key named something like >>>>> >>>>> MSYS-1.0_is1 >>>>> >>>>>if MSYS is installed. This in its turn has a string value with the >>>>>name >>>>> >>>>> Inno Setup: App Path >>>>> >>>>>which tells where MSYS is installed. (Or you can look at >>>>>UninstallString.) >>>>> >>>>> >>>>> >>>>> >>>>That may work fine for the current version of the installer, but the >>>>keys and strings may change for different versions of MSYS, or different >>>>installer tools (NSIS versus Inno Setup). Maybe there's a more generic >>>>approach, or an installer convention that could be conceived? Need to >>>>know if it's installed, perhaps status (e.g. ok, not configured, broken >>>>or half installed), location (drive or unc and path), and for MinGW with >>>>many optional components, perhaps the name of a file containing what's >>>>installed, along with some of this other info I mention. >>>> >>>>Well, of course all of this assumes MSYS was installed with an >>>>installer, when conceivably it could be custom built and copied, or >>>>otherwise unarchived somewhere, in which case it's just guessing at >>>>standard path names across all drives or uncs, which is anybody's guess. >>>> >>>>Anyways that's all speculative on my part. >>>> >>>>Leif >>>> >>>> >>>> |
From: Keith M. <kei...@to...> - 2005-10-04 09:09:37
|
Greg Chicares wrote: [citing my example of a technique for locating the MSYS root] > On 2005-10-3 13:40 UTC, Keith MARSHALL wrote: > [quoting someone else] That someone else was Lennart Borgman. Apologies for forgetting to add an appropriate citation; (of course, if Lotus Notes was even 10% as capable as kmail, I wouldn't be required to remember such detail -- this has to be the most incapable and user hostile email client on the planet :-( > Doesn't this solve a different problem than the OP posed? His method > could be incorporated into a program that might be run from msw > 'explorer'; I'm guessing that's how it's meant to be used. It tries > to determine whether MSYS is installed, from outside the MSYS shell. I believe that is, in fact, the case. But, why would you need to do this? If you have MSYS installed, then presumably YOU know it; to run a package configurator which requires the sort of environment provided by MSYS, then you would run it from an MSYS shell. The configure script may need to identify this environment when it is running, but, IMHO, it is rightly incumbent on the USER to choose this environment, BEFORE starting the configure script; it should NOT be the responsibility of the script to go searching for some environment, other than that in which it is originally invoked, in which it might be able to run. > Your script above seems to decide whether the shell it's run in is > MSYS's bash. If I understand that correctly, then wouldn't it be more > straightforward and reliable to use 'uname -s' and grep for 'MINGW'? Yes, that would be an alternative approach, and may indeed be more reliable; it has the minor disadvantage of requiring an additional fork, from the shell, to run the uname command, but that is probably insignificant. More importantly, it too can be circumvented, simply by changing the setting of the `MSYSTEM' environment variable, even if it is unlikely that a normal user would do so. > If that succeeds, then you know 'pwd -W' will give you the installation > root; but isn't it possible, even if unlikely, that some other shell > would have a '-W' extension for 'pwd' that would return a string > containing a colon? AFAIK, `pwd -W' is a unique feature of MSYS, for reporting current directory path with Win32 semantics, but I suppose there may be some other shell implementation -- presumably also for Windoze, if it's adding colons into the root directory path -- which does likewise. Most `bash' and `ksh' implementations will choke on `pwd -W', and emit nothing on stdout. Some other Bourne shell implementations DO accept, but ignore, the `-W' flag, in which case `cd / && pwd -W' simply emits `/' on stdout. Identifying any single specific runtime environment is often an imprecise science. The test I proposed will identify a shell environment which is COMPATIBLE with MSYS, at least in respect of its path name reporting capabilities, even if it is not actually MSYS' bash. Adding a `uname -s' check may give an increased level of confidence in the identification, but still doesn't provide 100% confidence. Regards, Keith. |
From: Lennart B. <len...@st...> - 2005-10-04 09:35:27
|
Keith MARSHALL wrote: >>Doesn't this solve a different problem than the OP posed? His method >>could be incorporated into a program that might be run from msw >>'explorer'; I'm guessing that's how it's meant to be used. It tries >>to determine whether MSYS is installed, from outside the MSYS shell. >> >> > >I believe that is, in fact, the case. But, why would you need to do >this? If you have MSYS installed, then presumably YOU know it; > I do not want to do this, but I can at the moment find no other good solution. I have been writing a bit on an installation elisp script for Emacs elisp packages. (Elisp is Emacs internal lisp language.) This should be run from inside Emacs. Some of the current elisp packages should be installed using a sh script. At the moment there is no standalone sh.exe for MS Windows that is actually working. There are several "unix emulation packages" that includes one (MSYS, CygWin, UWIN, UFS), but none that can be run standalone. If one was available I would choose that one and tell the Emacs users on MS Windows to use that one. Do you wonder why I just do not suggest the users to use MSYS and let them handle the installation? The reason is that MSYS currently can not be used with Emacs because of troubles with path names and line endings that I have many times tried to bring up here. Therefore my suggestions to the users is that they use the GnuWin32 packages with Emacs on MS Windows for their daily use. When they want to install packages they must however use MSYS (or something similar). In the installation elisp script I do this switch automatically for them. This way - with the correct setup - they can work as they use to on GNU/Linux for example. The trouble of using double environments will therefore be much less. This means - as I often use to point out - that switching to GNU/Linux is more easy. That is what many of us wants, I believe. |
From: Tuomo L. <dj...@mb...> - 2005-10-04 17:34:17
|
Lennart Borgman wrote: > should be installed using a sh script. At the moment there is no > standalone sh.exe for MS Windows that is actually working. There are > several "unix emulation packages" that includes one (MSYS, CygWin, UWIN, > UFS), but none that can be run standalone. If one was available I would > choose that one and tell the Emacs users on MS Windows to use that one. If you only need plain vanilla sh functionality, I believe zsh might do the trick. (http://unxutils.sourceforge.net/) SFU apparently has ksh (http://www.microsoft.com/windows/sfu/). (http://www.neowin.net/comments.php?category=software&id=12971) UWIN's ksh didn't work? What exactly is wrong with it? Then there's DJGPP's bash, if DOS executable is ok. (ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bsh204b.zip) Or, if you just need a shell, there's tcsh. (http://www.tcsh.org/MostRecentRelease) -- Tuomo ... False hope is better than no hope at all -- Ways for Personal Growth http://www.ericbair.com/humor/PerGrowth.txt |
From: Lennart B. <len...@st...> - 2005-10-04 20:31:37
|
Tuomo Latto wrote: >Lennart Borgman wrote: > > >>should be installed using a sh script. At the moment there is no >>standalone sh.exe for MS Windows that is actually working. There are >>several "unix emulation packages" that includes one (MSYS, CygWin, UWIN, >>UFS), but none that can be run standalone. If one was available I would >>choose that one and tell the Emacs users on MS Windows to use that one. >> >> > >If you only need plain vanilla sh functionality, >I believe zsh might do the trick. (http://unxutils.sourceforge.net/) > > I believe zsh could do the trick, but I wonder about the port at UnxUtils. When I press control-D in this zsh I get a question: zsh: do you want to see all 878 possibilities? Is that expected? I get the same even when I rename it to ksh or sh (in which case the ksh documentation says it should mimic those shells). It also does not seem to inherit the PATH variable. It is simply set to some default as far as I can see. Command line editing does not work. Is this maybe a very early or not finished port? Or am I simply misunderstanding how it should work? >SFU apparently has ksh (http://www.microsoft.com/windows/sfu/). >(http://www.neowin.net/comments.php?category=software&id=12971) > > Maybe this is a good choice, I do not know. It would have to be examined. Would it be as good as MSYS do you think? >UWIN's ksh didn't work? What exactly is wrong with it? > > It can not be run as a subshell in Emacs for some reason. Otherwise it is fast and does some of the things I have asked for here: diff just compares the text and does not care about line endings style, .cmd files are executed as expected. However it does not inherit PATH. >Then there's DJGPP's bash, if DOS executable is ok. >(ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bsh204b.zip) > > I would not expect this to work with w32 Emacs, but I am not sure. I mean I would expect there will be some problems with piping etc. Does not feel like this is the thing to put effort in. >Or, if you just need a shell, there's tcsh. >(http://www.tcsh.org/MostRecentRelease) > > This is UWIN again actually. Thanks for all the suggestions, but unfortunately I do not feel quite comfortable with any of them. I mean I would like to have something that I really can suggest to Emacs users on MS Windows as "this is it, you do not have to search any more - good integration with MS Windows and a nice set of features". Of course I just do not want to wine here, I hope someone which share my view of this can take the ball and finish the port of the current zsh for example (or bash). Or maybe change those things in MSYS that I have suggested. I would like to, but I lack the knowledge to do this quickly. I have spent some time on Emacs instead though. |
From: Tuomo L. <dj...@mb...> - 2005-10-04 22:00:53
|
Lennart Borgman wrote: >>If you only need plain vanilla sh functionality, >>I believe zsh might do the trick. (http://unxutils.sourceforge.net/) > > I believe zsh could do the trick, but I wonder about the port at > UnxUtils. When I press control-D in this zsh I get a question: > > zsh: do you want to see all 878 possibilities? > > Is that expected? I get the same even when I rename it to ksh or sh (in > which case the ksh documentation says it should mimic those shells). It > also does not seem to inherit the PATH variable. It is simply set to > some default as far as I can see. Command line editing does not work. > > Is this maybe a very early or not finished port? Or am I simply > misunderstanding how it should work? I have no idea. Maybe you should contact them? Or try compiling it yourself? I wonder if you could do miracles with MSYS. >>SFU apparently has ksh (http://www.microsoft.com/windows/sfu/). >>(http://www.neowin.net/comments.php?category=software&id=12971) > > Maybe this is a good choice, I do not know. It would have to be > examined. Would it be as good as MSYS do you think? Never used it. Can't help thinking M$ has it in their interests not to offer any good unix tools. Or at least I would think it would be their attitude. But no, I've never really needed anything that specific, so I really don't know. I'd try it if I were you. Can't hurt. >>UWIN's ksh didn't work? What exactly is wrong with it? > > It can not be run as a subshell in Emacs for some reason. Otherwise it > is fast and does some of the things I have asked for here: diff just > compares the text and does not care about line endings style, .cmd files > are executed as expected. However it does not inherit PATH. > > >>Then there's DJGPP's bash, if DOS executable is ok. >>(ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bsh204b.zip) > > I would not expect this to work with w32 Emacs, but I am not sure. I > mean I would expect there will be some problems with piping etc. Does > not feel like this is the thing to put effort in. I know nothing about emacs. (Well, I've *used* it and that's about it.) I would think, though, that you might be able to configure the shell in .emacs (or whatever it was) or with an environment variable. If you think that requires effort, then maybe you should be on your knees thanking me for the enormous amount of work I did. (A couple of minutes with a search engine, in case you're interested.) More to the point, have you tried using something like "cmd /c <shell>"? Frankly, I don't see why DJGPP's bash wouldn't work. It uses DPMI so it acts more or less in a civilized manner. AFAIK all Windows up to (and including) 32-bit XP have at least an emulation of a part of the DOS subsystem. So, it too is worth at least a try. >>Or, if you just need a shell, there's tcsh. >>(http://www.tcsh.org/MostRecentRelease) > > This is UWIN again actually. Thanks for all the suggestions, but > unfortunately I do not feel quite comfortable with any of them. I mean I > would like to have something that I really can suggest to Emacs users on > MS Windows as "this is it, you do not have to search any more - good > integration with MS Windows and a nice set of features". Well, a fully working command line with a nice set of features would be cmd + a bunch of utilities. Not very unixy, though. (You can get a freaky M$ version of filename completion on NT by turning it on in the registry.) Come to think of it, I did use Zoom Shell years ago. (Well, more like tried it.) Looks like both the author and the homepage are gone, but there seems to be plenty of downloads out there. Of course, I'm not sure this can be used in the way you wish. Someone's going to have to do the legwork to get it done. It's not going to be me because I just don't care enough. You seem to care. I think you're just quitting too easily. It's not like you have even tried all the options. > Of course I just do not want to wine here, I hope someone which share my > view of this can take the ball and finish the port of the current zsh > for example (or bash). Or maybe change those things in MSYS that I have > suggested. I would like to, but I lack the knowledge to do this quickly. > I have spent some time on Emacs instead though. You don't need someone to do it quickly. You need someone to do it right. If you need it quickly, you should have started earlier... -- Tuomo ... From my brain, an organ with a mind of it's own |
From: Lennart B. <len...@st...> - 2005-10-04 22:30:46
|
Tuomo Latto wrote: >Lennart Borgman wrote: > > >>>If you only need plain vanilla sh functionality, >>>I believe zsh might do the trick. (http://unxutils.sourceforge.net/) >>> >>> >>... >>Is this maybe a very early or not finished port? Or am I simply >>misunderstanding how it should work? >> >> > >I have no idea. Maybe you should contact them? > > I always try to when I found problems and want to support their efforts. But there is no one maintaining zsh on MS Windows any more. Is it to complicated to have knowledge of both MS Windows and unix API:s? I have seen similar difficulties before when I have tried to compare different software. It seems to be few people who have knowledge outside a certain welldefined area. Maybe it is hard to get a reputation if you try to grasp more? The thing is however that such persons in research of efficiency of projects can be found to be very valuable. (But this kind of research is complicated I believe and not very common.) >Or try compiling it yourself? >I wonder if you could do miracles with MSYS. > > It would be a miracle. I have tried but get stuck. That made me think that all open source projects should have a fully automated build process. Otherwise the whole thing might get lost if those with the knowledge no more are able to work with the projects. >I know nothing about emacs. (Well, I've *used* it and that's about it.) >I would think, though, that you might be able to configure the shell >in .emacs (or whatever it was) or with an environment variable. >If you think that requires effort, then maybe you should be on your >knees thanking me for the enormous amount of work I did. >(A couple of minutes with a search engine, in case you're interested.) > >More to the point, have you tried using something like "cmd /c <shell>"? > > I tend to know more about Emacs than I actually wanted in the beginning ;-) Yes, the UWIN shell starts, but there is something wrong in the communication. It might be that it does not expect input from Emacs. I do not know how what it checks and there is no active support of UWIN any more so it feels like a dead end. It is a pitty because it seems to have had a very good start. >Frankly, I don't see why DJGPP's bash wouldn't work. It uses DPMI so >it acts more or less in a civilized manner. AFAIK all Windows up to >(and including) 32-bit XP have at least an emulation of a part of >the DOS subsystem. So, it too is worth at least a try. > > I would be glad for more comments on this! > > > >>>Or, if you just need a shell, there's tcsh. >>>(http://www.tcsh.org/MostRecentRelease) >>> >>> >>This is UWIN again actually. Thanks for all the suggestions, but >>unfortunately I do not feel quite comfortable with any of them. I mean I >>would like to have something that I really can suggest to Emacs users on >>MS Windows as "this is it, you do not have to search any more - good >>integration with MS Windows and a nice set of features". >> >> > >Well, a fully working command line with a nice set of features >would be cmd + a bunch of utilities. Not very unixy, though. >(You can get a freaky M$ version of filename completion on NT by >turning it on in the registry.) > > It can not run the Makefiles I want to run. It must be a shell that is POSIX compatible at least in the syntax and more common semantics. >Someone's going to have to do the legwork to get it done. >It's not going to be me because I just don't care enough. >You seem to care. I think you're just quitting too easily. It's not like >you have even tried all the options. > > I have tried rather hard and spend more time when I wished on this. Some of the time I have spent here trying to convince people to change some things (like the treating of line endings etc). For some reason this has not been heard. Or rather it has been bannished. As you can see this has not made me give up completely, but I am actively trying to find something outside of MSYS (even though I believe it could be good with some small changes). It is a bit like beating a dead horse I think sometimes. >You don't need someone to do it quickly. You need someone to do it right. >If you need it quickly, you should have started earlier... > > I need a knowledgeable and intelligent speaking partner. But maybe such a human would find my wishes just to stupid ;-) |
From: Tuomo L. <dj...@mb...> - 2005-10-05 16:38:42
|
Lennart Borgman wrote: > Yes, the UWIN shell starts, but there is something wrong in the > communication. It might be that it does not expect input from Emacs. I > do not know how what it checks and there is no active support of UWIN > any more so it feels like a dead end. It is a pitty because it seems to > have had a very good start. Could this have something to do with the fact that Windows doesn't have pseudo-terminals or whatever. (Please don't ask, I think I heard about this on this very list..) >>Frankly, I don't see why DJGPP's bash wouldn't work. It uses DPMI so >>it acts more or less in a civilized manner. AFAIK all Windows up to >>(and including) 32-bit XP have at least an emulation of a part of >>the DOS subsystem. So, it too is worth at least a try. > > I would be glad for more comments on this! Not from me, I hope. AFAICR there is some sort of emulation layer on XP (and on NT and 2K - 9x/ME do not need one) that allows them to run some games, I think. So DPMI shell by comparison isn't that big a deal really. I just tried it and it works. Maybe I should rather say it runs and that I can execute GnuWin's ls (and which) with it. Of course it is bound by DOS limitations, but you should try if it suits for your purposes. Note that DJGPP is a GCC for DOS, so it should work at least with some makefiles. > I need a knowledgeable and intelligent speaking partner. But maybe such > a human would find my wishes just to stupid ;-) Well, that pretty much rules me out on both accounts. I don't think such a person would find your wishes too stupid. (S)he might find the job worth getting paid for, though. Essentially the problem is that fully functional shell might not be possible to implement on Windows. (Easily at least.) How about hacking make instead? Instead of having it rely on shell to do the right thing, why not just frankenstein* yourself a working make by sticking small bits of bash onto make with large lumps of chewing gum? *) Yay, did I just invent a colourful yet descriptive verb? Or was I just channelling that stuff from somewhere? -- Tuomo ... If Murphy's Law can go wrong, it will |
From: Greg C. <chi...@co...> - 2005-10-04 22:33:53
|
On 2005-10-4 20:30 UTC, Lennart Borgman wrote: > Tuomo Latto wrote: > >> Lennart Borgman wrote: >> >>> should be installed using a sh script. At the moment there is no >>> standalone sh.exe for MS Windows that is actually working. There are >>> several "unix emulation packages" that includes one (MSYS, CygWin, >>> UWIN, UFS), but none that can be run standalone. If one was available >>> I would choose that one and tell the Emacs users on MS Windows to use >>> that one. >> >> If you only need plain vanilla sh functionality, >> I believe zsh might do the trick. (http://unxutils.sourceforge.net/) >> > I believe zsh could do the trick, but I wonder about the port at > UnxUtils. I've been using this one every day for several years: ftp://ftp.blarg.net/users/amol/zsh/ Both are zsh-3.0.5 as far as I can tell. The 'unxutils' version seems to be amol's with few modifications; I wasn't aware of it until now. > When I press control-D in this zsh I get a question: > > zsh: do you want to see all 878 possibilities? > > Is that expected? What did you expect instead? The zsh manual says that's list-choices List possible completions for the current word. Maybe you're in a directory with 878 matching files, and it's guessing that you might not really want to see them all. I've seen this before, and in context it generally seems reasonable. > I get the same even when I rename it to ksh or sh (in > which case the ksh documentation says it should mimic those shells). It I don't see that in the zsh documentation, though the manual is long and I might be missing something. If you find it in the zsh manual, please provide a reference to the exact section. For testing the portability of scripts and makefiles, I use an ash port--I think there's one on José Fonseca's site. IIRC, cygwin's 'sh' is actually ash, not a renamed bash. > also does not seem to inherit the PATH variable. It is simply set to > some default as far as I can see. Command line editing does not work. Maybe the 'unxutils' port changes those things. They definitely work with amol's port. Or maybe you need to specify them in the startup file. In '/etc/zshenv' I have: path=(/usr/bin $path) prompt=%d[%?]$ WindowsPath=$Path WindowsPATH=$PATH WindowsComSpec=$ComSpec ComSpec=$0 COMSPEC=$0 > Thanks for all the suggestions, but > unfortunately I do not feel quite comfortable with any of them. I mean I > would like to have something that I really can suggest to Emacs users on > MS Windows as "this is it, you do not have to search any more - good > integration with MS Windows and a nice set of features". And you had recently explained the goal in another message: On 2005-10-4 9:35 UTC, Lennart Borgman wrote: > > I do not want to do this, but I can at the moment find no other good > solution. I have been writing a bit on an installation elisp script for > Emacs elisp packages. (Elisp is Emacs internal lisp language.) This > should be run from inside Emacs. Some of the current elisp packages > should be installed using a sh script. At the moment there is no > standalone sh.exe for MS Windows that is actually working. There are > several "unix emulation packages" that includes one (MSYS, CygWin, UWIN, > UFS), but none that can be run standalone. If one was available I would > choose that one and tell the Emacs users on MS Windows to use that one. I'm in a similar situation. I distribute binaries as tarballs to people who don't know what tarballs are, so I give them a CD with copies of zsh, tar, and bzip2, with a 'batch' file that just does the right thing. For more sophisticated users who could understand tarballs but may not have all the tools and libraries they need, but want to build from source, I provide my source code along with tarballs of tools and libraries, with a makefile that installs everything and builds my code. For msw users, all I assume is that they have my CD and some way of running a 'batch' file, which does only what's necessary to install a shell that then bootstraps the whole process. I've used amol's zsh port for this purpose since windows 95 days, and it kept working through migration to 98, 2000, and 'xp'. It's small enough that I don't bother inspecting whether it's been installed or not--I just copy it into a working directory and start using it. It doesn't mangle paths; it doesn't require '/c/' or '/cygdrive/' at the beginning of a path; and, well, it's zsh, which is just nice. |
From: Lennart B. <len...@st...> - 2005-10-04 23:14:09
|
Greg Chicares wrote: >On 2005-10-4 20:30 UTC, Lennart Borgman wrote: > =20 > >>I believe zsh could do the trick, but I wonder about the port at >>UnxUtils. >> =20 >> > >I've been using this one every day for several years: > ftp://ftp.blarg.net/users/amol/zsh/ >Both are zsh-3.0.5 as far as I can tell. The 'unxutils' version seems >to be amol's with few modifications; I wasn't aware of it until now. > =20 > I have seen this but I thought something was wrong with it (I do not=20 know zsh). I will make another try then. >>When I press control-D in this zsh I get a question: >> >> zsh: do you want to see all 878 possibilities? >> >>Is that expected? >> =20 >> > >What did you expect instead? The zsh manual says that's > list-choices > List possible completions for the current word. >Maybe you're in a directory with 878 matching files, and it's guessing >that you might not really want to see them all. I've seen this before, >and in context it generally seems reasonable. > =20 > Thanks very much! I did expect the shell to quit but zsh obviously does=20 not quit on C-d. > =20 > >>I get the same even when I rename it to ksh or sh (in >>which case the ksh documentation says it should mimic those shells). It >> =20 >> > >I don't see that in the zsh documentation, though the manual is long >and I might be missing something. If you find it in the zsh manual, >please provide a reference to the exact section. > =20 > See http://zsh.sunsite.dk/Doc/Release/zsh_3.html, 3.2 Compatibility >For testing the portability of scripts and makefiles, I use an ash >port--I think there's one on Jos=E9 Fonseca's site. IIRC, cygwin's 'sh' >is actually ash, not a renamed bash. > > =20 > >>also does not seem to inherit the PATH variable. It is simply set to >>some default as far as I can see. Command line editing does not work. >> =20 >> > >Maybe the 'unxutils' port changes those things. They definitely work >with amol's port. Or maybe you need to specify them in the startup file. >In '/etc/zshenv' I have: > =20 > Yes, it seems different with amol's port. That is nice. >path=3D(/usr/bin $path) >prompt=3D%d[%?]$ >WindowsPath=3D$Path >WindowsPATH=3D$PATH >WindowsComSpec=3D$ComSpec >ComSpec=3D$0 >COMSPEC=3D$0 > =20 > Some of these I do not understand. Could you give some more info? >I'm in a similar situation. I distribute binaries as tarballs to people >who don't know what tarballs are, so I give them a CD with copies of zsh= , >tar, and bzip2, with a 'batch' file that just does the right thing. For >more sophisticated users who could understand tarballs but may not have >all the tools and libraries they need, but want to build from source, I >provide my source code along with tarballs of tools and libraries, with >a makefile that installs everything and builds my code. For msw users, >all I assume is that they have my CD and some way of running a 'batch' >file, which does only what's necessary to install a shell that then >bootstraps the whole process. > =20 > Yes, it is very similar. I am glad to hear that it works for you. Do you=20 expect POSIX syntax in the shell or is there some deviance in the zsh=20 syntax? This is the most useful answer so far for my purpose! Thanks. |
From: Greg C. <chi...@co...> - 2005-10-05 15:57:43
|
On 2005-10-4 23:13 UTC, Lennart Borgman wrote: > Greg Chicares wrote: > >> On 2005-10-4 20:30 UTC, Lennart Borgman wrote: >> >>> I get the same even when I rename it to ksh or sh (in >>> which case the ksh documentation says it should mimic those shells). It >> >> I don't see that in the zsh documentation, though the manual is long >> and I might be missing something. If you find it in the zsh manual, >> please provide a reference to the exact section. >> >> > See http://zsh.sunsite.dk/Doc/Release/zsh_3.html, 3.2 Compatibility Thanks. I guess amol's port fails to implement that. I routinely run a copy called 'sh.exe', and it seems to run the same way no matter what the name. >> In '/etc/zshenv' I have: [...] >> path=(/usr/bin $path) >> prompt=%d[%?]$ >> WindowsPath=$Path >> WindowsPATH=$PATH >> WindowsComSpec=$ComSpec >> ComSpec=$0 >> COMSPEC=$0 >> > Some of these I do not understand. Could you give some more info? They're personal choices, and you might want something else. First, the '$0' stuff: I don't ever want to use CMD.EXE (except to run a batch file that installs and starts zsh). Some programs look for the name of the shell in 'ComSpec' or 'COMSPEC' (I've encountered both ways of capitalizing it), so I set that to the name by which zsh was invoked: http://zsh.dotsrc.org/Guide/zshguide02.html#l14 | Now $0 outside a function means the name of the shell, or the name | of the script for a non-interactive shell, so if you type `print $0' | it will probably say `zsh'. >> path=(/usr/bin $path) That inherits the msw system settings for 'Path', but puts my /usr/bin/ (which is C:\usr\bin) first. >> prompt=%d[%?]$ Prompt is working directory, plus last return code in brackets. >> WindowsPath=$Path >> WindowsPATH=$PATH >> WindowsComSpec=$ComSpec These may be unnecessary. I think I had to use some programs that really needed to invoke CMD.EXE, and had to know the original msw 'Path'. >> I'm in a similar situation. I distribute binaries as tarballs to people >> who don't know what tarballs are, so I give them a CD with copies of zsh, >> tar, and bzip2, with a 'batch' file that just does the right thing. For >> more sophisticated users who could understand tarballs but may not have >> all the tools and libraries they need, but want to build from source, I >> provide my source code along with tarballs of tools and libraries, with >> a makefile that installs everything and builds my code. For msw users, >> all I assume is that they have my CD and some way of running a 'batch' >> file, which does only what's necessary to install a shell that then >> bootstraps the whole process. >> > Yes, it is very similar. I am glad to hear that it works for you. Do you > expect POSIX syntax in the shell or is there some deviance in the zsh > syntax? I'm not entirely sure what you mean. I'd avoid writing paths like 'C:\etc\zshenv', prefering '/etc/zshenv' (or 'c:/etc/zshenv' for msw when it's crucial to give a drive letter). For something like an installer that's intended to serve just one special purpose, it's not really harmful to rely on zsh extensions like '**/*' wildcards, so I'd use them where they're helpful. |
From: Lennart B. <len...@st...> - 2005-10-04 23:18:55
|
Greg Chicares wrote: >For testing the portability of scripts and makefiles, I use an ash >port--I think there's one on Jos=E9 Fonseca's site. IIRC, cygwin's 'sh' >is actually ash, not a renamed bash. > =20 > I would be glad for some pointers to test the sh, ksh and/or POSIX=20 compatibility of a shell. Where can test scripts for this be found? |
From: Greg C. <chi...@co...> - 2005-10-05 16:00:21
|
On 2005-10-4 23:18 UTC, Lennart Borgman wrote: > Greg Chicares wrote: > >> For testing the portability of scripts and makefiles, I use an ash >> port--I think there's one on José Fonseca's site. IIRC, cygwin's 'sh' >> is actually ash, not a renamed bash. >> >> > I would be glad for some pointers to test the sh, ksh and/or POSIX > compatibility of a shell. Where can test scripts for this be found? I don't know. I just try to make sure anything I want to be portable runs in ash. As long as I do that, it seems to work in bash and zsh, too. Maybe some shell source distributions include test suites. |
From: Keith M. <kei...@to...> - 2005-10-04 10:19:04
|
Lennart Borgman wrote, quoting me, quoting Greg Chicares: >>>Doesn't this solve a different problem than the OP posed? His method >>>could be incorporated into a program that might be run from msw >>>'explorer'; I'm guessing that's how it's meant to be used. It tries >>>to determine whether MSYS is installed, from outside the MSYS shell. >> >>I believe that is, in fact, the case. But, why would you need to do >>this? If you have MSYS installed, then presumably YOU know it; >> > I do not want to do this, but I can at the moment find no other good > solution. I have been writing a bit on an installation elisp script > for Emacs elisp packages. Right. But can't you just search the PATH for a working `sh.exe', or any of a selection of known suitable alternatives, and leave the user to define a PATH which includes one? This is what `groff' does, when it runs the pipeline of filters it uses to format any given document. It's the approach I'm adopting in the port of `man', on which I am currently working; use a `spawnlp' function call to attempt to launch your shell command, rather that a `system' call, and try alternatives in order of preference, until you either find one which works, or you give up, and report failure, (assuming that you can get to that level of system interaction, from within elisp). I understand your problems with MSYS mangling of path names, and it's inappropriate interaction with the `emacs' build process. Perhaps you would need to provide a `find_working_shell' function which would iteratively search the PATH for a working shell, but reject any which you can identify as MSYS, using any of the techniques suggested by myself or Greg, if you really can't work around the problem. Regards, Keith. |
From: Lennart B. <len...@st...> - 2005-10-04 10:34:49
|
Keith MARSHALL wrote: >Right. But can't you just search the PATH for a working `sh.exe', or >any of a selection of known suitable alternatives, and leave the user >to define a PATH which includes one? This is what `groff' does, when >it runs the pipeline of filters it uses to format any given document. >It's the approach I'm adopting in the port of `man', on which I am >currently working; use a `spawnlp' function call to attempt to launch >your shell command, rather that a `system' call, and try alternatives >in order of preference, until you either find one which works, or you >give up, and report failure, (assuming that you can get to that level >of system interaction, from within elisp). > > > I am not sure, but I believe this could lead to problems. I want to avoid problems inside Emacs because they could be tricky to find depending on the complexity when external programs like diff etc are used. Mixing of tools from GnuWin32 and MSYS seems to be a problem sometimes. It is not entirely clear what I can mix and what I can not mix (both in theory and in practice). If for example mv.exe from GnuWin32 is first in the path and make.exe (from MinGW) is executed from MSYS sh.exe and the Makefile calls mv will that be ok always? What about other programs run this way (diff.exe is one of the very important ones)? Therefore I suggest to the Emacs users on MS Windows to not have MSYS in their path when running Emacs. >I understand your problems with MSYS mangling of path names, and it's >inappropriate interaction with the `emacs' build process. Perhaps >you would need to provide a `find_working_shell' function which would >iteratively search the PATH for a working shell, but reject any which >you can identify as MSYS, using any of the techniques suggested by >myself or Greg, if you really can't work around the problem. > I already check if it is MSYS sh.exe I find ... ;-) |
From: Keith M. <kei...@to...> - 2005-10-04 13:48:51
|
Lennart Borgman wrote: > Mixing of tools from GnuWin32 and MSYS seems to be a problem > sometimes. I routinely use a MinGW build of groff, built and installed from source, using MSYS, to produce technical bulletins in PDF format. In addition to groff, that requires GhostScript, for which I use the `official' AFPL distribution for Win32, from ghostscript.com. I run the command line interface tool from that binary package, without problems, from an MSYS shell; groff also invokes it as required, from within its own MinGW built binaries. As part of the groff build process, some of the documentation is compiled in HTML format, using groff itself as an HTML generator. That process not only requires GhostScript -- it also requires several of the NetPBM utilities, the psselect utility, and supporting DLL's such as netpbm.dll, zlib.dll and libpng.dll. While the latter two are now available as mingwPORTs, they weren't when I first started using this setup, so I've sourced ALL of these additional prerequisites from GnuWin32; I've never had the slightest problem using any of them with MSYS, whether I invoke them directly, or indirectly from within groff itself. I also use a GnuWin32 build of GNU bison, with complete success in MSYS, because at the time when I first needed it, the MinGW offering was at a release which was specifically reported as unsuitable for building groff from CVS sources, (and indeed, didn't work). > It is not entirely clear what I can mix and what I can not > mix (both in theory and in practice). Best advice here would have to be `try it and see'. Regards, Keith. |
From: Keith M. <kei...@to...> - 2005-10-05 08:03:07
|
Lennart Borgman wrote, quoting Greg Chicares, replying to him: >>>When I press control-D in this zsh I get a question: >>> >>> zsh: do you want to see all 878 possibilities? >>> >>>Is that expected? >> >>What did you expect instead? The zsh manual says that's >> list-choices >> List possible completions for the current word. >>Maybe you're in a directory with 878 matching files, and it's >>guessing that you might not really want to see them all. I've seen >>this before, and in context it generally seems reasonable. > > Thanks very much! I did expect the shell to quit but zsh obviously > does not quit on C-d. Ctrl-D is end of file in UNIX/POSIX; shells quit when they get end of file on their input streams. Windoze isn't POSIX; Ctrl-D *isn't* end of file -- you need Ctrl-Z, or an explicit `exit' or `logout' command. Regards, Keith. |
From: LENNART B. <len...@st...> - 2005-10-05 09:51:08
|
From: Keith MARSHALL <kei...@to...> > > Thanks very much! I did expect the shell to quit but zsh obviously > > does not quit on C-d. > > Ctrl-D is end of file in UNIX/POSIX; shells quit when they get end of > file on their input streams. > > Windoze isn't POSIX; Ctrl-D *isn't* end of file -- you need Ctrl- > Z, or > an explicit `exit' or `logout' command. > > Regards, > Keith. Yes, but ctrl-D works in MSYS sh. |
From: Keith M. <kei...@to...> - 2005-10-05 10:53:18
|
Lennart Borgman wrote, quoting me: >> Windoze isn't POSIX; Ctrl-D *isn't* end of file -- you need Ctrl- >> Z, or >> an explicit `exit' or `logout' command. > > Yes, but ctrl-D works in MSYS sh. That's because MSYS provides a modicum of POSIX emulation via its msys-1.0.dll. This is a special feature of MSYS special programs, that is, those linked against this DLL; it isn't standard in Windoze, and you have no right to expect it. Regards, Keith. |
From: LENNART B. <len...@st...> - 2005-10-05 11:18:29
|
From: Keith MARSHALL <kei...@to...> > > Yes, but ctrl-D works in MSYS sh. > > That's because MSYS provides a modicum of POSIX emulation via its > msys-1.0.dll. This is a special feature of MSYS special programs, > that is, those linked against this DLL; it isn't standard in > Windoze, and you have no right to expect it. I have to stand up for my rights of course ;-) I really expect a good port to handle this. |