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: mount type, compiler barf, and sym links


Hi Stephen,

You haven't read my "Personal Reflections" on this yet, have you?  The
binary mount switch has been over emphasised as _THE_ way to do
things.  It makes the porter lazy in dealing with the issue.

The real problem lies in the way that UNIX vs WIN32 create files.  To
UNIX a file is a file and what the file contains is what ever the
program/programmer/user told it to put into it.  To WIN32 a file is
also a file and what the file contains depends not only on the
program/programmer/user but also the file processing mode.  

If processing in text mode then certain values of data are treated
specially.  A \n (new line) written to the file will prepend a \r
(carriage return) so that if you `printf("Hello\n") you infact get
"Hello\r\n".  Upon reading this combination, the \r is removed and the
number of bytes returned by the read is 1 less than was actually read
which confuses programs dependant on ftell() and fseek().  A Ctrl-Z
encountered while reading a file sets the End Of File flags even
though it truly isn't the end of file.

These problems have been avoided globally by setting the default
processing mode to binary.  But that creates a different problem.  In
binary mode the program will receive all of the data in the file
including a \r.  The programs will then not deal with these properly
so you have to remove the \r from the text files, especially scripts
and startup resource files.  This is a porter "cop out" forcing the
user to deal with the \r for the porter.

It is rather easy for the porter to fix with supplying the appropriate
file processing mode switches to the open/fopen functions.  Treat all
text files as text and treat all binary files as binary.  The switches
are existant on UNIX open/fopen functions and will just ignore the
switch as it has no meaning to UNIX but has been defined by ANSI.

I hope this answers that question.  In a previous post I pleaded with
the porters not to depend on the binary mode mount setting in hopes of
getting the ported programs usable with out futzing with the registry.

Now for the symbollic links:  IMHO, it is always best to be specific. 
The files vim.exe and vim can coexist in the directory.  So if vim
without the extension was ever created your link would then point to
that file.  Since your using the Win32 version of vim then I find it
easiest to just edit the link file and add the .exe to the reference. 
However, it is not necessary, as you already know to do this.  Just be
aware that if it stops working look at the directory containing the
physical file.

---Stephen L Arnold <sarnold@coyote.rain.org> wrote:
>
> Howdy:
> 
> I can't keep up with the volume (and much of what I do read is 
> pretty obtuse to me anyway); sorry if this seems like a stupid 
> question.
> 
> I've had the B19/coolview/egcs setup working for a few weeks (at 
> least for compiling my stupid homework problems - all console mode 
> stuff).  I guess I always had my root partition mounted text mode.  
> After reading some of the posts lately on the subject, I got the 
> impression I should use binary mounts, so when I created some new 
> mount points for /tmp, /var, my ntemacs directory (for symbolic 
> links), etc, I used the -b switch.  I also changed my root mount 
> point in the registry to the binary type.  Suddenly my homework 
> wouldn't compile; I got some weird error message about undefined 
> symbols in stdio.h & stddef.h (all my source files are LF only).
> 
> I changed the mount type back and everything compiles fine again.  
> What was the problem?  Something to do with CR/LF translation?  
> Would somebody care to explain it in terms a self-taught guy (with 
> a geophysics background) can understand?  Which types of mounts do 
> I want for what types of scenarios and why?
> 
> I also created some sym links in /bin that point to win32 versions 
> of vim and emacs (as well as linking /bin/sh to bash).  Do I need 
> to explicitly link to prog1.exe or just prog1 (the links in /bin 
> seem to work fine as sh, gvim, and emacs)?  Are there any hidden 
> implications to using/not using the DOS .exe file extension under 
> bash?
> 
> Thanks in advance for any answers, Steve
> 
> 
> *************************************************************
> Steve Arnold                            sarnold@earthling.net
> http://www.rain.org/~sarnold
> 
> Fatal error:  MS Windows detected, deleting DOS partition...
> -
> For help on using this list (especially unsubscribing), send a
message to
> "gnu-win32-request@cygnus.com" with one line of text: "help".
> 

==
-                \\||//
-----------o0O0--Earnie--0O0o------------
--        earnie_boyd@yahoo.com        --
-- http://freeyellow.com/members5/gw32 --
--------------ooo0O--O0ooo---------------

PS: Newbie's, you should visit my page.
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" 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]