From: Keith M. <kei...@us...> - 2010-06-03 17:08:26
|
On Thursday 03 June 2010 00:51:18 Charles Wilson wrote: > >> MinGW/man/ contains > >> Technology Preview_ man-1.6/man-1.6-mingw-beta-1-src.tar.gz > >> > >> Since this isn't mingw-get installable (and I'm not sure how > >> current it is), I think it should be moved to that > >> ObsoleteMinGW or OldMinGW or MinGW/Old/ > > > > Your MSYS release probably obsoletes it, so we could just dump it > > in "OldFiles" and have done with it. > > Well, a mingw version of man could run in regular cmd.exe session. Up to a point, perhaps. It achieves its purpose by constructing a command pipeline, to process the manpage source through nroff, with appropriate pre-processing filters in the pipe, and directing its output through a designated pager, (e.g. less). The syntax of that command pipeline is very much intended for Bourne shell, so when man passes it as an argument to system(3), it ain't going to have much joy when cmd.exe tries to parse it. My port searches $PATH for any recognisable Bourne compatible shell -- it doesn't have to be our MSYS shell, but it has to have a recognisable "*sh.exe" name -- then spawns that, emulating system(3) to parse the command pipeline; see http://mingw.cvs.sf.net/viewvc/mingw/man/src/win32/wincmds.c?view=markup It *doesn't* make any attempt to convert that sequence of Bourne shell commands to an equivalent cmd.exe syntax, and it never grants cmd.exe any opportunity to even attempt to parse it. Why would it? It would be pointless; it is doomed to fail. > > Our CVS has some significant > > updates, not least of which is adding full i18n support, (does > > your MSYS release have that?), > > I don't know whether the *code* has "full" i18n support, but the > MSYS version is compiled with -DNONLS, because msys has no > catgets(). OTOH, without that flag, man-1.6f does try to use > catgets -- but I don't know if that is what you mean by "full" > support. Insofar as man's own message catalogue processing goes, yes. In addition, my port attempts to deduce an ISO-639 language code, from the Windows locale, and assign it to $LANG, (unless the user has already set that in his environment), so that the appropriate language specific manpage source files will be processed; see http://mingw.cvs.sf.net/viewvc/mingw/man/src/man.c?r1=1.8&r2=1.9 > Obviously this lack could be fixed with an msys port of your > catgets package, but I haven't done so. You weren't thrilled when > I ported man to msys in the first place, so I didn't push it. That was because I consider that a mingw32 implementation is a better fit for our "minimalist" policy. Of greater concern to me was your MSYS port of groff, lest it would conflict with my requirement for a fully functional, pdfroff capable implementation, (which is my own principal motivation for using MSYS at all, in my workplace -- all of the in-house documentation I produce is PDF, fully indexed with PDF bookmarks, and cross-references, in a manner which neither MS-Weird nor any other WYSIAYG package could aspire to achieve). > >> Ditto with MinGW/catgets/* > > > > Disagree. This is the i18n implementation for man, but it is a > > fully POSIX conformant, free-standing gencat/catgets > > implementation for Win32; it still merits a place, (not everybody > > wants to use gettext, and I plan to use this for mingw-get > > itself), perhaps repackaged to suit mingw-get's identification > > semantics. > > Actually, that's exactly what I meant: I think that the stuff under > MinGW/ and MSYS/ should all be *current*, and Well, the 1.0.1 version of catgets which is there *is* current -- we could drop the 1.0 version, leaving 1.0.1 as the only one. From that base, it is also maintained; I wrote it, and if it needs any further work, I will support it. > *mingw-get-compatible*. So, *temporarily*, this version of catgets > should get moved elsewhere IMO -- and when it is repackaged, then > we bring that repackaged version back over to MinGW/. Even packaged as it currently is, it is as mingw-get compatible as, say GCC-3.4.5; mingw-get has been able to deliver a fully functional installation of *that*, since alpha-1 hit the mirrors. While the package breakdown, and naming conventions may not fit our current standards, that need not preclude mingw-get compatibility; it needs an appropriate manifest, but the interim lack of that is hardly sufficient reason to hide/withdraw the current package. -- Regards, Keith. |