From: dmccunney <den...@gm...> - 2012-08-27 22:13:26
|
I'm not sure whether I'm encountering a bug or just getting bitten by lack of knowledge. I have an ancient Fujitsu p2110 notebook, given to me by a friend when she upgraded to a faster box. It's decidedly low end, with a Transmeta 867mhz CPU, an IDE 4 HD, and a whopping 256MB of RAM, of which 16MB are taken off the top by the CPU for "code morphing". It came to me with WinXP SP2 installed, and was frozen snail slow. I swapped the original 30GB HD for a 40GB from my SO's dead laptop, reformatted, partitioned, and installed Win2K Pro SP4, two flavors of Linux, and FreeDOS. Properly tuned and configured, Win2K takes about 80MB of RAM when loaded, and is actually usable. (Most of what I might need to run under Windows works in 2K. The stuff that doesn't I can live without.) I installed the MYS tools because I wanted a set of Win32 ports of the common *nix utilities, and a working Win32 version of bash. I did not install the MinGW compiler and associated tools - the machine is way too underpowered to do development on it. NTFS5 supports hard links for files and junctions for directories. I use Hermann Schinagl's Link Shell Extension (http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html) which provides context menu entries to create and manipulate such things. Under Win2K/WinXP it does hard links out of the box. Under Vista/Win7 it supports proper symbolic links, too.* I wanted a *nix like file system, so I used LSE to create a junction, and have Msys/1.0/bin appear as /bin. That works fine. I subsequently decided I'd prefer it to appear as /usr/bin, deleted the old junction, and created a new one. That did *not* work fine. The junction was created, /usr/bin shows in the file system and I can list the files in it, but attempting to actually execute any of them fails. I can type the command at the prompt and I simply return to the prompt with the command not actually running. If I create the junction as /bin, things work. It appears Msys tools only work correctly through junctions created off of root, and fail if the junction is created off a sub-directory. This seems to be Msys specific, as I have other sets on Win32 ports of *nix utilities, like the Gnuwin32 collection, that do work as expected. Right now, I have Msys mapped via a junction as /bin, and can live with it. But I'm curious: *should* creating the junction as /usr/bin have worked, or am I running into an inherent limit in how Msys works, or have I found a bug? * And too my surprise, a recent update to LSE pointed to an open source driver written by a Japanese developer that enables true symlinks in 2K and XP. NTFS5 has the underlying infrastructure to support symlinks, but it's not exposed by the 2k/XP kernel. The driver amends that oversite. ______ Dennis https://plus.google.com/u/0/105128793974319004519 |
From: Earnie B. <ea...@us...> - 2012-08-28 12:13:00
|
On Mon, Aug 27, 2012 at 6:12 PM, dmccunney wrote: > I'm not sure whether I'm encountering a bug or just getting bitten by > lack of knowledge. > The latter is what I'm thinking. BTW, support for MSYS happens on mingw-user, the documentation needs changed. > > NTFS5 supports hard links for files and junctions for directories. I > use Hermann Schinagl's Link Shell Extension > (http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html) > which provides context menu entries to create and manipulate such > things. Under Win2K/WinXP it does hard links out of the box. Under > Vista/Win7 it supports proper symbolic links, too.* > > I wanted a *nix like file system, so I used LSE to create a junction, > and have Msys/1.0/bin appear as /bin. That works fine. I > subsequently decided I'd prefer it to appear as /usr/bin, deleted the > old junction, and created a new one. That did *not* work fine. The > junction was created, /usr/bin shows in the file system and I can list > the files in it, but attempting to actually execute any of them fails. > I can type the command at the prompt and I simply return to the > prompt with the command not actually running. If I create the > junction as /bin, things work. It appears Msys tools only work > correctly through junctions created off of root, and fail if the > junction is created off a sub-directory. This seems to be Msys > specific, as I have other sets on Win32 ports of *nix utilities, like > the Gnuwin32 collection, that do work as expected. > > Right now, I have Msys mapped via a junction as /bin, and can live > with it. But I'm curious: *should* creating the junction as /usr/bin > have worked, or am I running into an inherent limit in how Msys works, > or have I found a bug? > Why? When you start the MSYS shell it maps itself already to / and /usr. What are you trying to accomplish? > * And too my surprise, a recent update to LSE pointed to an open > source driver written by a Japanese developer that enables true > symlinks in 2K and XP. NTFS5 has the underlying infrastructure to > support symlinks, but it's not exposed by the 2k/XP kernel. The > driver amends that oversite. MSYS when I forked Cygwin to develop it did not have a Windows junction or a Windows symlink to rely on and the way Cygwin had emulated it did not work for a native application. Therefore it was removed and the functions return ENOSYS error. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: dmccunney <den...@gm...> - 2012-08-28 15:50:05
|
On Tue, Aug 28, 2012 at 8:12 AM, Earnie Boyd <ea...@us...> wrote: > On Mon, Aug 27, 2012 at 6:12 PM, dmccunney wrote: >> I'm not sure whether I'm encountering a bug or just getting bitten by >> lack of knowledge. > > The latter is what I'm thinking. BTW, support for MSYS happens on > mingw-user, the documentation needs changed. So noted. Thanks. >> Right now, I have Msys mapped via a junction as /bin, and can live >> with it. But I'm curious: *should* creating the junction as /usr/bin >> have worked, or am I running into an inherent limit in how Msys works, >> or have I found a bug? > > Why? When you start the MSYS shell it maps itself already to / and > /usr. What are you trying to accomplish? Like I said, a Unix style file system arrangement. *Msys* may map itself to / and /usr, but I'm not always *in* the Msys shell when I''m in a console. Aside from Msys bash, I have versions of tcsh, zsh, and ksh, as well as Windows cmd.exe. They don't see the Msys mapping. (I use Console2 to get a tabbed console window, and may have more than one shell active at a time.) >> * And too my surprise, a recent update to LSE pointed to an open >> source driver written by a Japanese developer that enables true >> symlinks in 2K and XP. NTFS5 has the underlying infrastructure to >> support symlinks, but it's not exposed by the 2k/XP kernel. The >> driver amends that oversite. > > MSYS when I forked Cygwin to develop it did not have a Windows > junction or a Windows symlink to rely on and the way Cygwin had > emulated it did not work for a native application. Therefore it was > removed and the functions return ENOSYS error. I assumed something like that. Native support now exists (for Vista/Win7, at least.) Any plans to add it to Msys? > Earnie > -- https://sites.google.com/site/earnieboyd ______ Dennis https://plus.google.com/u/0/105128793974319004519 |
From: Earnie B. <ea...@us...> - 2012-08-28 17:09:26
|
On Tue, Aug 28, 2012 at 11:49 AM, dmccunney wrote: >>> Right now, I have Msys mapped via a junction as /bin, and can live >>> with it. But I'm curious: *should* creating the junction as /usr/bin >>> have worked, or am I running into an inherent limit in how Msys works, >>> or have I found a bug? >> >> Why? When you start the MSYS shell it maps itself already to / and >> /usr. What are you trying to accomplish? > > Like I said, a Unix style file system arrangement. *Msys* may map > itself to / and /usr, but I'm not always *in* the Msys shell when I''m > in a console. Aside from Msys bash, I have versions of tcsh, zsh, and > ksh, as well as Windows cmd.exe. They don't see the Msys mapping. (I > use Console2 to get a tabbed console window, and may have more than > one shell active at a time.) So the issue becomes this, for MSYS it maps / and /usr to the parent of the directory containing the msys-1.0.dll and the directory containing msys-1.0.dll becomes /bin and /usr/bin. When you create the junction c:/usr/bin to the msys/1.0/bin and execute from c:/usr/bin then root / is then mapped to c:/usr and MSYS is all confused. The tcsh, etc shells, are the Cygwin related or something else? -- Earnie -- https://sites.google.com/site/earnieboyd |
From: dmccunney <den...@gm...> - 2012-08-28 17:38:39
|
On Tue, Aug 28, 2012 at 1:09 PM, Earnie Boyd <ea...@us...> wrote: > On Tue, Aug 28, 2012 at 11:49 AM, dmccunney wrote: >>>> Right now, I have Msys mapped via a junction as /bin, and can live >>>> with it. But I'm curious: *should* creating the junction as /usr/bin >>>> have worked, or am I running into an inherent limit in how Msys works, >>>> or have I found a bug? >>> >>> Why? When you start the MSYS shell it maps itself already to / and >>> /usr. What are you trying to accomplish? >> >> Like I said, a Unix style file system arrangement. *Msys* may map >> itself to / and /usr, but I'm not always *in* the Msys shell when I''m >> in a console. Aside from Msys bash, I have versions of tcsh, zsh, and >> ksh, as well as Windows cmd.exe. They don't see the Msys mapping. (I >> use Console2 to get a tabbed console window, and may have more than >> one shell active at a time.) > > So the issue becomes this, for MSYS it maps / and /usr to the parent > of the directory containing the msys-1.0.dll and the directory > containing msys-1.0.dll becomes /bin and /usr/bin. When you create > the junction c:/usr/bin to the msys/1.0/bin and execute from > c:/usr/bin then root / is then mapped to c:/usr and MSYS is all > confused. And that confusion accounts for the fact that the various mys tools simply silently fail when executed from /usr/bin. (I assume they set a non-zero exit status of some kind.) Okay. That explains what's going on. I have Cygwin as well (though not currently used on the notebook,) but I'd prefer to avoid the quirks involved in trying to use such tools from outside their native environment. I want to have such tools in my Windows PATH, execute them from CMD.EXE as well as whatever their native shell might be, and expect reasonable results. Like I said, I'm not trying to do development on the box, so GCC and the like are irrelevant. I just want to do things like type ls -l at a prompt, get a long form ls listing, and not care about just which prompt I'm doing it from. > The tcsh, etc shells, are they Cygwin related or something else? Something else. There are lots of third-party ports of Unix tools to Win32, like the Gnuwin32 offerings and Karl Syring's UnxUtils (http://unxutils.sourceforge.net/UnxUtils.html) Zsh is Syring's port, though there are a couple of others, Just poking around on Sourceforge, I've seen a POSIX compatibility layer implemented as a device by a Russian developer, and installed by Add/Remove Hardware, and an offering called PW32 that looks like it's trying to do something similar to Msys. (That one hasn't been updated in a while, and appears moribund.) Everyone seems to implement a different set of the tools, and a background effort here is to get the fullest possible set, which means mix and match, with preference given to the most recent version ported, > Earnie > -- https://sites.google.com/site/earnieboyd ______ Dennis https://plus.google.com/u/0/105128793974319004519 |
From: Earnie B. <ea...@us...> - 2012-08-28 18:53:57
|
On Tue, Aug 28, 2012 at 1:38 PM, dmccunney wrote: > >> The tcsh, etc shells, are they Cygwin related or something else? > > Something else. Ok, good. There could be issue with mixing these environments. > There are lots of third-party ports of Unix tools to > Win32, like the Gnuwin32 offerings and Karl Syring's UnxUtils > (http://unxutils.sourceforge.net/UnxUtils.html) Zsh is Syring's port, > though there are a couple of others, Just poking around on > Sourceforge, I've seen a POSIX compatibility layer implemented as a > device by a Russian developer, and installed by Add/Remove Hardware, > and an offering called PW32 that looks like it's trying to do > something similar to Msys. (That one hasn't been updated in a while, > and appears moribund.) > I'll caution you with some of these. IIRC, Zsh contains a fork implementation based on Cygwin's fork and from what I remember isn't being updated recently. The last update of unxutils was in 2007; pretty old but if it works, so be it. PW32 is pretty much dead. The developer used to communicate with the MinGW team. > Everyone seems to implement a different set of the tools, and a > background effort here is to get the fullest possible set, which means > mix and match, with preference given to the most recent version > ported, And everyone tends to have varying goals. MSYS was started to provide a means for MinGW to execute a typical configure and make process for building native tools. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: dmccunney <den...@gm...> - 2012-08-28 19:31:10
|
On Tue, Aug 28, 2012 at 2:53 PM, Earnie Boyd <ea...@us...> wrote: > On Tue, Aug 28, 2012 at 1:38 PM, dmccunney wrote: >> >>> The tcsh, etc shells, are they Cygwin related or something else? >> >> Something else. > > Ok, good. There could be issue with mixing these environments. Which is why I want to be aware of issues. Mysy mounts are one such: it looks like I ought not to mix Msys tools with others. The Gnuwin32 toolset looks like a reasonably good set of the standard command line tools. The fun part is a *nix like shell. I started using Unix with SysVR2 and am an old Korn shell guy, but if it uses the Bourne script language and has decent interactive features like command line editing, aliases, and functions, I can deal. This means bash, mksh, and zsh are usable, but lets out tcsh for anything save occasional use. Back in the MS-DOS days, I used the MKS Toolkit, largely because they *had* a good Korn shell port. >> There are lots of third-party ports of Unix tools to >> Win32, like the Gnuwin32 offerings and Karl Syring's UnxUtils >> (http://unxutils.sourceforge.net/UnxUtils.html) Zsh is Syring's port, >> though there are a couple of others, Just poking around on >> Sourceforge, I've seen a POSIX compatibility layer implemented as a >> device by a Russian developer, and installed by Add/Remove Hardware, >> and an offering called PW32 that looks like it's trying to do >> something similar to Msys. (That one hasn't been updated in a while, >> and appears moribund.) > > I'll caution you with some of these. IIRC, Zsh contains a fork > implementation based on Cygwin's fork and from what I remember isn't > being updated recently. The last update of unxutils was in 2007; > pretty old but if it works, so be it. The UnxUtils tools seem to work well enough. I have a couple of different versions of zsh, of which one is Syring's. But they are based on older versions of zsh, that don't support things like --version, so it isn't terribly clear what zsh code they were based on. (I know, Look at the source...) > PW32 is pretty much dead. The developer used to communicate with the > MinGW team. Since it hasn't been updated in some time, that was my assumption. I was fascinated it existed, but unsurprised it was moribund. I've lost count of the number of promising open source offerings I've seen that withered because the devs lost interest/didn't have time/whatever, and they never achieved enough traction to induce someone else to pick them up. >> Everyone seems to implement a different set of the tools, and a >> background effort here is to get the fullest possible set, which means >> mix and match, with preference given to the most recent version >> ported, > > And everyone tends to have varying goals. MSYS was started to provide > a means for MinGW to execute a typical configure and make process for > building native tools. Yep, and it apparently does it well . I just don't happen to be doing that. All I need is a decent set of the standard command line tools used outside of the development process, and access to a *nix like shell on occasion. > Earnie > -- https://sites.google.com/site/earnieboyd ______ Dennis https://plus.google.com/u/0/105128793974319004519 |
From: Earnie B. <ea...@us...> - 2012-08-28 20:07:50
|
On Tue, Aug 28, 2012 at 3:30 PM, dmccunney wrote: > > Which is why I want to be aware of issues. Mysy mounts are one such: > it looks like I ought not to mix Msys tools with others. The Gnuwin32 > toolset looks like a reasonably good set of the standard command line > tools. The fun part is a *nix like shell. I started using Unix with > SysVR2 and am an old Korn shell guy, but if it uses the Bourne script > language and has decent interactive features like command line > editing, aliases, and functions, I can deal. This means bash, mksh, > and zsh are usable, but lets out tcsh for anything save occasional > use. Back in the MS-DOS days, I used the MKS Toolkit, largely because > they *had* a good Korn shell port. > Bash has decent emulation for standard Bourne shell syntax when named sh and has some ksh features. http://web.mit.edu/gnu/doc/html/features_3.html -- Earnie -- https://sites.google.com/site/earnieboyd |
From: dmccunney <den...@gm...> - 2012-08-28 20:49:50
|
On Tue, Aug 28, 2012 at 4:07 PM, Earnie Boyd <ea...@us...> wrote: > On Tue, Aug 28, 2012 at 3:30 PM, dmccunney wrote: >> >> Which is why I want to be aware of issues. Mysy mounts are one such: >> it looks like I ought not to mix Msys tools with others. The Gnuwin32 >> toolset looks like a reasonably good set of the standard command line >> tools. The fun part is a *nix like shell. I started using Unix with >> SysVR2 and am an old Korn shell guy, but if it uses the Bourne script >> language and has decent interactive features like command line >> editing, aliases, and functions, I can deal. This means bash, mksh, >> and zsh are usable, but lets out tcsh for anything save occasional >> use. Back in the MS-DOS days, I used the MKS Toolkit, largely because >> they *had* a good Korn shell port. > > Bash has decent emulation for standard Bourne shell syntax when named > sh and has some ksh features. > http://web.mit.edu/gnu/doc/html/features_3.html Yep. I use bash under Linux (and I'm up under Ubuntu 12.04 LTS at the moment.) The bash developers appeared to be trying to include everything *including* the kitchen sink, and produced what you might get if you merged sh, ksh, and csh in one shell. In the process, it got big and resource intensive enough that we got ash, with the shell language but without the interactive stuff, specifically to run things like install scripts with less overhead. (I found one ancient win-bash port based on bash 1.x, and the FAQ answer to "Why not a more recent version" is "It runs the scripts we wanted to be able to run.") AT&T made the real ksh open source, but their license isn't compatible with things like the GPL, so Cygwin can't include it, and I haven't seen a Windows version other than AT&T's UWin environment. (Incompatible licenses are probably the biggest open source stumbling block I can think of.) > Earnie > -- https://sites.google.com/site/earnieboyd ______ Dennis https://plus.google.com/u/0/105128793974319004519 |