This is the mail archive of the
mailing list for the Cygwin project.
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Christopher Faylor wrote:
On Thu, Apr 03, 2008 at 06:01:37PM -0500, Charles Wilson wrote:
Yep. A few things off the top of my head:
1) the shells need to install both in /bin and /usr/bin. This is up to the
individual maintainers when they build their -1.7 versions, but to take on
super-duper important shell:
Or "tough. you want to run /bin/bash, ensure /usr/bin is in your PATH"
Geez. This was the really-just-a-joke-WJM response. Doing this will
cause no END of trouble and lots of FAQs. It means I can't have a
shortcut whose target is
"C:/cygwin17/bin/bash -e somescript"
"cmd /k C:/cygwin17/bin/bash.exe -e somescript"
unless my environment settings (either system or personal) force
/usr/bin into my PATH (otherwise /bin/bash can't find cygintl-8.dll and
I also can't have
"C:/cygwin17/usr/bin/bash -e somescript"
"cmd /k C:/cygwin17/usr/bin/bash.exe -e somescript"
unless my environment settings (either system or personal) force /bin
into my PATH (otherwise /usr/bin/bash.exe can't find cygwin1.dll).
But I don't WANT cygwin stuff in either of those PATHs, because that
makes life more difficult when I'm using eclipse with mingw (because
eclipse defaults to cygwin if it is found in the PATH, grrr), or when
I'm in "mingw-on-msys" mode. So, I'm stuck with
C:/cygwin/bin/run.exe -p /usr/bin:/bin [/usr]/bin/bash.exe -c somescript
(assuming run.exe is one of the lucky few that live in /bin) or
where somebatchfile.bat sets the PATH then invokes the "real" script
OTOH, this is my existing XEmacs shortcut target:
C:\cygwin\bin\run.exe -p /usr/X11R6/bin:/usr/bin env.exe --unset=DISPLAY
uses run to set PATH (and hide the console), invokes env to make sure
DISPLAY is not set -- and env then invokes xemacs. This ensures that I
get the mswin GUI and not the X GUI (it's a relic of my company's
Rational ClearCase installation policies, which set DISPLAY in the
system environment where I don't have permissions to remove it).
I guess similar games can be played with other targets, using /bin/run
and /bin/env. (so, run.exe and env.exe ought to be in /bin)
And besides, WJM.
Making duplicate copies is asking for trouble.
But in the WJM option, you still have duplicate copies of bash.exe. It's
just that (a) they are both identical (b) they both require dlls of
which there are no duplicate copies, only /usr/bin versions.
I guess if (a) and (b) are big enough "plusses" to deal with the
inevitable FAQs and list chatter driven by the "minus" above...
and the "minus" alluded to upthread: the idea that /bin should be
populated by stuff that "just works" even if mounts are all screwed up
and /usr/bin can't be found. Under the WJM option, that goes out the
window. If /usr/bin can't be found, bang. you're dead.
No, please don't...I like my /desktop mount...
You don't need fstab to do mounts. It's always possible to add a mount
to your .bashrc or something. That's what you'd do on linux if you
wanted similar functionality.
I guess. But in the linux case you need root permission to do a 'mount
--bind' (which is as close to similar semantics as our "user mounts" as
I can see). But happily on cygwin we don't need admin privs to create