This is the mail archive of the cygwin@sourceware.cygnus.com 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]

Re: More on getting coolview-bash to work with emacs


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
ernie.cordell@computer.org
Web pages at
http://www.netcom.com/~erniec/
http://www.geocities.com/SouthBeach/Lagoon/7778
-----Original Message-----
From: Guy Gascoigne - Piggford <ggp@informix.com>
To: GNU-Win32 <gnu-win32@cygnus.com>
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@cygnus.com" with one line of text: "help".
>
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=QUOTED-PRINTABLE:;Methodology;Boston House, #111=0D=0A1711 Massachusetts AV, NW;Washington;Di=
strict of Columbia;20036-2136;USA
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Methodology=0D=0ABoston House, #111=0D=0A1711 Massachusetts AV, NW=0D=0AWash=
ington, District of Columbia 20036-2136=0D=0AUSA
ADR;HOME;ENCODING=QUOTED-PRINTABLE:;;Ernie's Place=0D=0ABoston House, #111=0D=0A1711 Massachusetts AV, NW;Washi=
ngton;District of Columbia;20036-2136;United States
LABEL;HOME;ENCODING=QUOTED-PRINTABLE:Ernie's Place=0D=0ABoston House, #111=0D=0A1711 Massachusetts AV, NW=0D=0AWa=
shington, District of Columbia 20036-2136=0D=0AUnited States
URL:http://www.geocities.com/SouthBeach/7778
URL:http://www.netcom.com/~erniec/
EMAIL;PREF;INTERNET:ernie.cordell@computer.org
EMAIL;INTERNET:erniec@ix.netcom.com
EMAIL;INTERNET:ecordell@yahoo.com
EMAIL;INTERNET:ecordell@goplay.com
END:VCARD

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