Sorry for the slow reply... Op Mon, 27 Jun 2005 00:17:01 -0400 schreef Charles Wilson in <[EMAIL PROTECTED]>: : Bas van Gompel wrote: [Re-adding attribution:] + > Charles Wilson: [...] : > : without using execvp(). [...] : > : Plus, alternatives itself needs to be smart : > : about when to use a wrap executable, and when to use "normal" symlinks. [...] : > Certainly. I'd think generally one should only wrap executables. : > (*and take real special care of dll's.*) : : Yes.
What I meant to say was: ``Special care should be taken *not* to wrap DLLs, although they appear as executables in the file-system.'' : > : So, (a) alternatives isn't set up, YET, to use any sort of wrap prog, : > : and (b) when it is, it probably shouldn't use your wrap, directly. [how ``alternatives'' works] : update-alternatives manages the symlinks in /usr/bin AND the symlinks in : /etc/alternatives/. Under a wrap scenario, update-alternatives would : need to know (sometimes) to make the item in /usr/bin be a wrap : executable, pointing to the appropriate /etc/alternatives/ "target" : symlink, which in turns points back to /usr/bin/... Yes. I have since seen that ``alternatives'' uses a pure ``C'' approach, so my shell-script installers might not be appropriate. It should not be hard for ``alternatives'' to copy the wrapper bin-file itself, however. : Your wrap program seems intended for a different audience: the end user : -- who might copy the "orginal" exe away to some other directory, and : put the wrap program in the original location -- thus leading to DLL : search issues, as you say. It's more intended for when a package uses a symlink to an executable, and you want to use the program from outside of cygwin. (e.g. unison.exe being replaced with a(n ``alternatives'') symlink, as multiple versions became supported or to have a ``rbash'', ``egrep'', ``fgrep'' etc. which can be invoked from windows, without having to resort to hardlinks/copying.) I never intended to say anything about DLL search issues. :] [...] : > I will look into creating a (new) executable to do what : > ``alternatives'' wants, as soon as I find out what format the : > links in /etc/alternatives take. : : I'm not sure it's worth your time to do so right now. I think the : /bin/ash vs. /bin/bash thing will be resolved some other way, and that's : the only pressing need for an MSWin-friendly symlink-wrap-thingy from : the perspective of update-alternatives. I did since however write a ``wrap-alternative'' executable, which uses execv... Not having to read a file makes it even simpler than the ``wrap'' executable. :) When I have resolved FHS-issues... (I'm going for "${libdir}/wrap/" to store the binaries, "${bindir}/" for the install-scripts, pointerfiles/links go in ${sysconfdir}/wrap and ${sysconfdir}/alternatives, respectively, for now. Preliminary binary package file-list: /usr/bin/wrap /usr/bin/wrap-alternative /usr/lib/wrap/wrap.bin /usr/lib/wrap/wrap-alternative.bin /usr/share/doc/wrap-1.0/AUTHORS /usr/share/doc/wrap-1.0/ChangeLog /usr/share/doc/wrap-1.0/COPYING /usr/share/doc/wrap-1.0/INSTALL /usr/share/doc/wrap-1.0/NEWS /usr/share/doc/wrap-1.0/README /usr/share/doc/Cygwin/wrap-1.0.README Any comments?) ...and have thought over info/man-pages, the ITP will follow, L8r, Buzz. [If this is too OT do feel free to TITTTL, I read there as well.] BTW: The ``alternatives'' man-page points to a ``Red Hat'' bugzilla, and mentions a copyright by them. Is that as should be? -- ) | | ---/ ---/ Yes, this | This message consists of true | I do not -- | | / / really is | and false bits entirely. | mail for ) | | / / a 72 by 4 +-------------------------------+ any1 but -- \--| /--- /--- .sigfile. | |perl -pe "s.u(z)\1.as." | me. 4^re