This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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"
^^^^ ^^^^^^^^

Yes.

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"
or even
"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 friends).


I also can't have
"C:/cygwin17/usr/bin/bash -e somescript"
or even
"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
somebatchfile.bat
where somebatchfile.bat sets the PATH then invokes the "real" script using C:\cygwin17\bin\bash.exe.


Ick.

OTOH, this is my existing XEmacs shortcut target:

C:\cygwin\bin\run.exe -p /usr/X11R6/bin:/usr/bin env.exe --unset=DISPLAY xemacs

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 (user) mounts.


--
Chuck


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]