From mboxrd@z Thu Jan 1 00:00:00 1970 From: Earnie Boyd To: sarnold@earthling.net, gnu-win32@cygnus.com Subject: Re: mount type, compiler barf, and sym links Date: Mon, 19 Oct 1998 10:34:00 -0000 Message-id: <19981019121004.10517.rocketmail@send102.yahoomail.com> X-SW-Source: 1998-10/msg00551.html 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 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".