Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com Message-ID: <3B87E775.8080100@ece.gatech.edu> Date: Sat, 25 Aug 2001 13:59:17 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713 X-Accept-Language: en-us MIME-Version: 1.0 To: cygwin-apps AT cygwin DOT com Subject: Re: perl + automode.o References: <3B869484 DOT 6253 DOT 36FAB1 AT localhost> <20010825133819 DOT G21709 AT redhat DOT com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Christopher Faylor wrote: > On Fri, Aug 24, 2001 at 05:53:08PM +0200, Gerrit P. Haase wrote: > >>Hi, >> >>I compiled a version of miniperl with automode.o linked >>in. First tests shows that it adresses the CR/LF problem. >> > > I don't think that compiling a general purpose programing package like > perl with automode is a good solution. > > It just pushes the CRLF problem onto a different class of users. Let me chime in here...after thinking about this a little harder, I don't think "automode" is the right solution. But first, let's define the problem. (1) Using Unix-line-endings on Unix(binary) mounts: no problem (2) Using DOS-line-endings on DOS(text) mounts no problem? (3) Using Unix-line-endings on DOS(text) mounts no problems reading, but output files get extraneous ^M's on disk. That's okay though, because perl can still read them in (case #2 above) (4) Using DOS-line-endings on binary mounts main problem. Using automode will read the files in text(DOS) mode, and write them in binary(UNIX) mode. But what if the file is actual *binary* data, and not *text* at all? What if you read a file into memory, close the file, open for write, and the write the data back out. Through no intention or fault of your own, if perl is linked with automode you've just done a DOS to UNIX conversion. Maybe Chris' chomp() suggestion is the right thing. I thought Eric had tracked down and squashed these bugs back in the 5.005_62 days, but then it reappeared in the 5.6.1-TRIAL release. Eric, any ideas? --Chuck