This is the mail archive of the 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: Bash as the interactive shell in Emacs 19.34.6 for NT not working

>raf, you wrote:
>> >raf, you wrote:
>> >> > Look, text=binary mode is a nice feature, but not everyone wants it.
>> >> 
>> >> What? You don't want 'cat' to work?-)
>> >I generally don't use `cat' with binary files, so there's no problem.
>> >I don't mind having to do something special when invoking programs
>> >such as cat on binary files.
>> not even "cat xaa xab xac > blerk.tar.gz" ? i'm amazed!
>> -- begin rant --
>> i mention this example because i was disgusted to find that it
>> didn't work (long before i knew about text=binary).
>> 'cat' is not 'type' and never was. cat is unix's identity process.
>> it's importance in this role cannot be overstated.
>> cat does not concatenate "text" files - it concatenates files.
>> i'm certain that it is an error for 'cat' to treat "text" files
>> differently to all other files, *even* on a "text" mount.

>OK, so fix cat then!
>(i.e. change the source code so that files, including stdout,
>are opened in binary mode).

not as easy as you might think. unix doesn't have the option of opening files
as text vs. binary. files are files. <sys/fcntl.h> makes no mention of such
modes for open() or fcntl() so it's not a matter of changing cat's source.
i think the "mode" used depends entirely on the "mount style" (but i could
easily be wrong). does fopen("file", "rb") mean anything to cygwin?

>> unix software will always assume "binary mounts" (their only option).
>> you may not like them but all of the unix software ever written does.
>> it may be an assumption that can't easily be invalidated if the goal
>> is to make porting unix source code trivial.

>Yes, I agree with this, but THAT IS NOT, I repeat, *NOT* THE ONLY AIM!

hence my use of the word: "if"
(and there's no need to repeat - my memory is fine - i read it the first time)

>If you want to maximize ease of porting Unix source code, even at cost
>of decreasing ease of use of the resulting apps, then go ahead and use
>binary mounts.  But don't try to force everyone to do the same, because
>not everyone has exactly the same aim.

i can hardly see how i'm trying to force anyone to do anything.
just because i don't share your problem, and am not highly motivated
to solve your problem, doesn't mean that i'm forcing you not to solve
your problem.

i'm just trying to point out that it is a fundamental assumption and that
removing it will require much work on the part of those for whom it is a

it has already been suggested in this thread that both binary and text mounts
be in place at the same time so that the user can choose, at a moment's
notice, which to use. this sounds, to me, to be a very good suggestion.

if it isn't, explain why so that progress can be made.

i guess the real problem is that all unix programs assume "binary mounts"
and that's why they don't work on "text mounts". so the solution is simple:
just fix it :) this means either:

    1) changing the source of every unix program you want to run so they
       can handle "text mounts"

    2) changing all of the input routines in cygwin so that they analyze
       their input, if it's text (of any description), convert it, in memory,
       into unix-style text input (so that the programs will work); and
       changing all of the output routines so that they analyse their output,
       if it's text (unix style) then convert it into local-style text.
       and since line endings can change style throughout a file without
       warning, this analysis is a constant requirement.

    3) make heavy, clever use of both "mount styles". e.g. when compiling, the
       source files should be referred to by their "text mount" path but the
       output file should be referred to by it's "binary mount" path.

solution 1 is fine if portability isn't a concern (but a neverending task).
solution 2 is slow and complex but would always work and preserves portability.
solution 3 requires changing all makefiles (and similar) or writing front-ends
           to gcc (and similar) that know what your local multiple mounts are
           called and uses them appropriately.

don't "text mounts" blindly treat *every* file as text? if so, they *can't* be
the only "mount style" in use. a combination is necessary.

but this doesn't make sense - what does gcc do when writing it's output to a
"text mount"? stop at the first ^Z byte? i wouldn't think so. anyone?


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

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