From: erniec AT ix DOT netcom DOT com (Ernest Clayton Cordell, Jr.) Subject: Re: More on getting coolview-bash to work with emacs 11 Dec 1997 07:42:44 -0800 Message-ID: <01bd063c$90b000e0$4fb4dfcf.cygnus.gnu-win32@magic> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0019_01BD0612.A7D9F8E0" To: "GNU-Win32" , "Guy Gascoigne - Piggford" This is a multi-part message in MIME format. ------=_NextPart_000_0019_01BD0612.A7D9F8E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Folks, Sergey has done a lot of wonderful work: None of us have put that up for debate. It is my hope to add a thought that might clarify what I see being expressed frequently in the list. My motive for doing so is to help define a convention for (cygwin32-style) binary file mounts that will be acceptable to a broad audience. I wrote a larger, clearer message earlier but I deleted it in favor of the more succinct rubbish that follows. In the few months that I've occasionally played with the cygwin32-toolset (not "in anger"), I have accepted the processing schism of a "text mount" as a temporary challenge. There are three components to this problem: data introduced to processing elements ; the processing elements themselves ; and the environment used for execution of processing elements . These can be vectored as "native" or "foreign," but the order of business is always -->-->. With -->--> (cygwin32/"unix"): no problem, right? Both modes accomodated. With -->-->: unix/binary seems accomodated, not win/dos. With -->-->: "outside" programs have own behavior; no standard possible. With -->-->: "outside" programs only port to "pre-configured" environments. With -->-->: _filters_ required to process foreign data in native environment. With -->-->: policy must be established for cygwin32 target environments. With -->-->: can make accomodations but no guarantees for "imported subsystems." With -->-->: collision possible if cygwin32 and foreign environment don't coordinate. I have focused here on porting and execution because "use" and "compatibility" are vague terms where anything other than the "precise" behavior can be expected in both environments: Such considerations are too complex for an online analysis. In most of these cases everything possible has already been done: In the case of _filters_, it could be argued that if such filters exist, they should be part of the front-end processing of the cygwin32 toolset. In this scenario, shell scripts would be because they are input that is read by cygwin32 utilities: While the shell could be modified to accept either or -alone as possible line terminators, "foreign" programs that refuse to do so cannot be governed by the cygwin32 toolset, team or sponsors. In compilers and utilities, comments are stripped and spaces/blanks are also routinely skipped: Should a utility halt because it finds an intervening blank between the line-continuation marker and the marker? Then should it fail because of "printer-control" characters either? As far as operating cygwin32 tools outside of a cygwin32 environment (not relevant to this particular issue, but frequently mentioned), the goals of the development team must define the policy for "where" (in what environments) cygwin32 tools are designed to operate. I'm sorry that it took me so many words to relate this concept: I'm not gifted with abbreviated expression, Ernie ernie DOT cordell AT computer DOT org Web pages at http://www.netcom.com/~erniec/ http://www.geocities.com/SouthBeach/Lagoon/7778 -----Original Message----- From: Guy Gascoigne - Piggford To: GNU-Win32 Date: Wednesday, December 10, 1997 8:14 PM Subject: Re: More on getting coolview-bash to work with emacs >At 11:20 AM 12/10/97 +0100, you wrote: >>> To achieve my goal, I need to use text-mode mounts. >>> Thus for my purposes, if bash stops working on text-mode mounts, >>> then this is a big step backwards... >> >>Actually, Sergey's work is a big step *forwards*, but I would appreciate >>support for both kinds of line-endings very much. > >I have to agree here, I'm not completely convinced by the arguments of >'just use binary mounts', but aside from that, Sergy's work has added a lot >of improvements and added functionality. I'd much rather use it than not. > >Guy > >- >For help on using this list (especially unsubscribing), send a message to >"gnu-win32-request AT cygnus DOT com" with one line of text: "help". > ------=_NextPart_000_0019_01BD0612.A7D9F8E0 Content-Type: text/x-vcard; name="Ernest Clayton Cordell, Jr..vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Ernest Clayton Cordell, Jr..vcf" BEGIN:VCARD N:Cordell, Jr.;Ernest;Clayton FN:Ernest Clayton Cordell, Jr. ORG:Ernie's Place;Software Development TITLE:Technical Director TEL;WORK;VOICE:202/462-1525 TEL;HOME;VOICE:202/462-1525 TEL;PAGER;VOICE:net TEL;WORK;FAX:by operator TEL;HOME;FAX:by operator ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;Methodology;Boston House, = #111=3D0D=3D0A1711 Massachusetts AV, NW;Washington;Di=3D strict of Columbia;20036-2136;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Methodology=3D0D=3D0ABoston = House, #111=3D0D=3D0A1711 Massachusetts AV, NW=3D0D=3D0AWash=3D ington, District of Columbia 20036-2136=3D0D=3D0AUSA ADR;HOME;ENCODING=3DQUOTED-PRINTABLE:;;Ernie's Place=3D0D=3D0ABoston = House, #111=3D0D=3D0A1711 Massachusetts AV, NW;Washi=3D ngton;District of Columbia;20036-2136;United States LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:Ernie's Place=3D0D=3D0ABoston = House, #111=3D0D=3D0A1711 Massachusetts AV, NW=3D0D=3D0AWa=3D shington, District of Columbia 20036-2136=3D0D=3D0AUnited States URL:http://www.geocities.com/SouthBeach/7778 URL:http://www.netcom.com/~erniec/ EMAIL;PREF;INTERNET:ernie DOT cordell AT computer DOT org EMAIL;INTERNET:erniec AT ix DOT netcom DOT com EMAIL;INTERNET:ecordell AT yahoo DOT com EMAIL;INTERNET:ecordell AT goplay DOT com END:VCARD ------=_NextPart_000_0019_01BD0612.A7D9F8E0-- - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".