Subject: Re: More on getting coolview-bash to work with emacs
From: [email-masked] (Ernest Clayton Cordell, Jr.)

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" <[email-masked]>,
        "Guy Gascoigne - Piggford" <[email-masked]>

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 <dipe>; the processing elements themselves <pet>; and
the environment used for execution of processing elements <eufeope>.  These
can be vectored as "native" <N> or "foreign," <F> but the order of business
is always <dipe>--><pet>--><eufeope>.
    With <N><dipe>--><N><pet>--><N><eufeope> (cygwin32/"unix"): no problem,
right?  Both modes accomodated.
    With <N><dipe>--><N><pet>--><F><eufeope>: unix/binary seems accomodated,
not win/dos.
    With <N><dipe>--><F><pet>--><N><eufeope>: "outside" programs have own
behavior; no standard possible.
    With <N><dipe>--><F><pet>--><F><eufeope>: "outside" programs only port
to "pre-configured" environments.
    With <F><dipe>--><N><pet>--><N><eufeope>: _filters_ required to process
foreign data in native environment.
    With <F><dipe>--><N><pet>--><F><eufeope>: policy must be established for
cygwin32 target environments.
    With <F><dipe>--><F><pet>--><N><eufeope>: can make accomodations but no
guarantees for "imported subsystems."
    With <F><dipe>--><F><pet>--><F><eufeope>: 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 <dipe> because they are input
that is read by cygwin32 utilities: While the shell could be modified to
accept either <cr><lf> or <lf>-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 <EOLN>
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
[email-masked]
Web pages at
http://www.netcom.com/~erniec/
http://www.geocities.com/SouthBeach/Lagoon/7778
-----Original Message-----
From: Guy Gascoigne - Piggford <[email-masked]>
To: GNU-Win32 <[email-masked]>
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
>"[email-masked]" 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:[email-masked]
EMAIL;INTERNET:[email-masked]
EMAIL;INTERNET:[email-masked]
EMAIL;INTERNET:[email-masked]
END:VCARD

------=_NextPart_000_0019_01BD0612.A7D9F8E0--

-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".