Has CR/LF and cat problem with textutils-2.0 been solved?

Has CR/LF and cat problem with textutils-2.0 been solved?

[Erik Nolte]

Excuse me if this is a known problem, I can't find Cygnus's bug tracking
database to know if this has been solved.

I'm experiencing the problems with "cat" that were described on this mailing
list in July and August.  Specifically, cat is not filtering out CRs on
textmode filesystems and it's causing commands like "javac `cat
generatedlist`" to fail.  If I substitute the B20.1 cat for the 1.1.4
version everything works.  The -B option to cat doesn't seem applicable and
doesn't solve the problem.

To reproduce the problem, try this (in a directory on a textmode
filesystem):

    ls / > x
    echo `cat x`

I get the following:

    varup.log.full

If I do "echo `cat x` | od -c" I see that everything's present, but the CRs
are messing things up:
    0000000   b   i   n  \r       c  \r       c   y   g   w   i   n   .   b
    0000020   a   t  \r       c   y   g   w   i   n   .   i   c   o  \r
    0000040   d  \r       e   t   c  \r       f  \r       h   o   m   e  \r
    0000060       l   i   b  \r       s   e   t   u   p   .   l   o   g  \r
    0000100       s   e   t   u   p   .   l   o   g   .   f   u   l   l  \r
    0000120       t   m   p  \r       u   s   r  \r       v   a   r  \r  \n
    0000140

B20.1 and UNIX systems produce the desired result:
    bin
    c
    cygwin.bat
    cygwin.ico
    d
    etc
    f
    home
    lib
    setup.log
    setup.log.full
    tmp
    usr
    var

Do I have the right versions of things?  Have I screwed the configuration
up?

My configuration is:

/f/cygwin/src 685> cygcheck -s -r -v

Cygnus Win95/NT Configuration Diagnostics
Current System Time: Tue Sep 26 00:14:36 2000

WinNT Ver 5.0 build 2195 Service Pack 1

Path:   /usr/local/bin
        /usr/bin
        /usr/bin
        /d/gsj31/bin
        /d/WINNT/system32
        /d/WINNT
        /d/WINNT/System32/Wbem
        /d/vim/vim57
        /w/bin
        /w/src/bin
        /w/3rd-party/NT
        /e/pipeline/build/bin
        .

SysDir: D:\WINNT\System32
WinDir: D:\WINNT

HOME = `/home/erik'
MAKE_MODE = `unix'
PWD = `/f/cygwin/src'
USER = `erik sean nolte'

!D: = `D:\cygwin\bin'
ALLUSERSPROFILE = `D:\Documents and Settings\All Users'
APPDATA = `D:\Documents and Settings\Erik Sean Nolte\Application Data'
BLASTER = `A220 I5 D1 T4 '
COMMONPROGRAMFILES = `D:\Program Files\Common Files'
COMPUTERNAME = `C1144585-A'
COMSPEC = `D:\WINNT\system32\cmd.exe'
CP_DOC_ROOT = `d:/Netscape/SuiteSpot/docs'
CP_ROOT = `w:/'
CP_WEB_ROOT = `d:/Netscape/SuiteSpot'
CVSROOT = `:pserver:anoncvs@anoncvs.cygnus.com:/cvs/src'
GEMSTONE = `D:\gsj31'
HOMEDRIVE = `D:'
HOMEPATH = `\'
HOST = `c1144585-a'
HOSTNAME = `C1144585-A'
HOSTTYPE = `i586'
LOGONSERVER = `\\C1144585-A'
MACHTYPE = `i586-pc-cygwin'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/f/cygwin/src/winsup'
OS2LIBPATH = `D:\WINNT\system32\os2\dll;'
OS = `Windows_NT'
OSTYPE = `cygwin'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 5 Stepping 2, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0502'
PROGRAMFILES = `D:\Program Files'
PROMPT = `$P$G'
PS1 = `$PWD \!> '
SHELL = `/bin/sh'
SHLVL = `1'
SUN_JVM = `d:/jdk1.2.2/bin/java'
SYSTEMDRIVE = `D:'
SYSTEMROOT = `D:\WINNT'
TEMP = `/d/DOCUME~1/ERIKSE~1/LOCALS~1/Temp'
TERM = `cygwin'
USERDOMAIN = `C1144585-A'
USERNAME = `Erik Sean Nolte'
USERPROFILE = `D:\Documents and Settings\Erik Sean Nolte'
VIM = `D:\vim\vim57'
WINDIR = `D:\WINNT'
_ = `/usr/bin/cygcheck'
TZ = `MST7MDT6,M4.1.0/2,M10.5.0/2'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x00000020
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `D:/cygwin'
  flags = 0x00000002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/c
  (default) = `c:'
  flags = 0x00000000
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/d
  (default) = `d:'
  flags = 0x00000000
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/f
  (default) = `f:'
  flags = 0x00000000
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `D:/cygwin/bin'
  flags = 0x00000002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `D:/cygwin/lib'
  flags = 0x00000002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/w
  (default) = `w:'
  flags = 0x00000000
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00
  (default) = `w:'
  unix = `/w'
  fbinary = 0x00000000
  fsilent = 0x00000000
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\01
  (default) = `D:'
  unix = `/'
  fbinary = 0x00000000
  fsilent = 0x00000000
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrd
er\S
tart Menu\Programs\Cygnus Solutions
  (default) = (unsupported type)
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\00
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\01
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\02
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\03
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\04
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\05
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\06
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\07
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\08
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\09
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\0A
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\0B
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\0C
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\0D
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\0E
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\0F
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\10
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\11
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\12
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\13
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\14
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\15
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\16
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\17
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\18
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\19
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\1A
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\1B
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\1C
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL
setup\b15.0\mounts\1D
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\GNUPro
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\GNUPro\i586-cygwin32

a:  fd           N/A    N/A
c:  hd  FAT32   6748Mb  11% CP    UN
d:  hd  NTFS    7051Mb  51% CP CS UN PA FC
e:  fd           N/A    N/A
f:  hd  FAT32   1000Mb  85% CP    UN           DATA
g:  cd           N/A    N/A
h:  cd           N/A    N/A
w:  hd  NTFS    7051Mb  51% CP CS UN PA FC

D:\cygwin\bin  /usr/bin  user    binmode
D:\cygwin\lib  /usr/lib  user    binmode
D:\cygwin  /        user    binmode
c:    /c       user    textmode
d:    /d       user    textmode
f:    /f       user    textmode
w:    /w       user    textmode

Found: D:\cygwin\bin\bash.exe
Found: D:\cygwin\bin\cat.exe
Found: w:\3rd-party\NT\cpp.exe
Found: D:\cygwin\bin\find.exe
Not Found: gcc
Not Found: gdb
Found: D:\cygwin\bin\ld.exe
Found: D:\cygwin\bin\ls.exe
Found: D:\cygwin\bin\make.exe
Found: D:\cygwin\bin\sh.exe

  586k 2000/08/04 D:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
                  "cygwin1.dll" v0.0 ts=2000/8/3 18:53
    Cygwin DLL version info:
        dll major: 1001
        dll minor: 4
        dll epoch: 19
        dll bad signal mask: 19005
        dll old termios: 5
        api major: 0
        api minor: 26
        shared data: 3
        dll identifier: cygwin1
        mount registry: 2
        cygnus registry name: Cygnus Solutions
        cygwin registry name: Cygwin
        program options name: Program Options
        cygwin mount registry name: mounts v2
        build date: Thu Aug 3 20:53:46 EDT 2000
        CVS tag: cygwin-1-1-4
        shared id: cygwin1S3

Use -h to see help about each section



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Has CR/LF and cat problem with textutils-2.0 been solved?

[Chris Faylor]

On Tue, Sep 26, 2000 at 12:16:21AM -0600, Erik Nolte wrote:
>Excuse me if this is a known problem, I can't find Cygnus's bug tracking
>database to know if this has been solved.

There is no bug tracking system for cygwin.

I've thought about implementing one but I quail at the thought of what would
show up there given our disappointing experience with the "todo" list.

>I'm experiencing the problems with "cat" that were described on this mailing
>list in July and August.  Specifically, cat is not filtering out CRs on
>textmode filesystems and it's causing commands like "javac `cat
>generatedlist`" to fail.  If I substitute the B20.1 cat for the 1.1.4
>version everything works.  The -B option to cat doesn't seem applicable and
>doesn't solve the problem.
>
>To reproduce the problem, try this (in a directory on a textmode
>filesystem):
>
>    ls / > x
>    echo `cat x`
>
>I get the following:
>
>    varup.log.full
>
>If I do "echo `cat x` | od -c" I see that everything's present, but the CRs
>are messing things up:
>    0000000   b   i   n  \r       c  \r       c   y   g   w   i   n   .   b
>    0000020   a   t  \r       c   y   g   w   i   n   .   i   c   o  \r
>    0000040   d  \r       e   t   c  \r       f  \r       h   o   m   e  \r
>    0000060       l   i   b  \r       s   e   t   u   p   .   l   o   g  \r
>    0000100       s   e   t   u   p   .   l   o   g   .   f   u   l   l  \r
>    0000120       t   m   p  \r       u   s   r  \r       v   a   r  \r  \n
>    0000140

I think it is arguable whether cat should strip CRs or not.  It is not arguable
whether bash's backtick handling should treat its input as text mode.

>B20.1 and UNIX systems produce the desired result:
>    bin
>    c
>    cygwin.bat
>    cygwin.ico
>    d
>    etc
>    f
>    home
>    lib
>    setup.log
>    setup.log.full
>    tmp
>    usr
>    var

Of course *UNIX* produces the desired result.

Anyway, I have Cc'ed the person who volunteered to be the maintainer for this
package.  Hopefully he will offer an opinion on this.

If he doesn't I'd like to survey this mailing list for the correct behavior.
If it is that cat should strip \r's then I'll drop back to the old version
unless someone wants to take the time to do more than post bug reports and
is interested in maintaining the textutils package.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Has CR/LF and cat problem with textutils-2.0 been solved?

[Matthew Smith]

I would be interested in comments from the mailing list.  If people want
\r's stripped, I will implement the changes.

cheers,
-Matt Smith


> I think it is arguable whether cat should strip CRs or not.  It is not
arguable
> whether bash's backtick handling should treat its input as text mode.
>
> >B20.1 and UNIX systems produce the desired result:
> >    bin
> >    c
> >    cygwin.bat
> >    cygwin.ico
> >    d
> >    etc
> >    f
> >    home
> >    lib
> >    setup.log
> >    setup.log.full
> >    tmp
> >    usr
> >    var
>
> Of course *UNIX* produces the desired result.
>
> Anyway, I have Cc'ed the person who volunteered to be the maintainer for
this
> package.  Hopefully he will offer an opinion on this.
>
> If he doesn't I'd like to survey this mailing list for the correct
behavior.
> If it is that cat should strip \r's then I'll drop back to the old version
> unless someone wants to take the time to do more than post bug reports and
> is interested in maintaining the textutils package.
>
> cgf
>


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Has CR/LF and cat problem with textutils-2.0 been solved?

[Bernard Dautrevaux]

> -----Original Message-----
> From: Chris Faylor [ mailto:cgf@cygnus.com ]
> Sent: Wednesday, September 27, 2000 7:00 PM
> To: cygwin@sources.redhat.com
> Cc: chet@nike.ins.cwru.edu
> Subject: Re: Has CR/LF and cat problem with textutils-2.0 been solved?
> 
> 
> On Wed, Sep 27, 2000 at 12:03:09PM -0400, Chet Ramey wrote:
> >> >However *all* shells (and not only bash) *must* read the standard
> >> >output of command expansion (backtick) in *text* mode, as 
> it *does*
> >> >expect text and is *not* willing to handle binary data there.
> >> 
> >> This was my point.  We fixed ash to do the right thing and 
> I've been waiting
> >> patiently for the bash maintainer to fix bash as well.
> >
> >How about a bug report?  Or maybe an email?  I don't read this list
> >very often, so, unless I get mail about it, `waiting patiently' is
> >probably not going to get the job done.
> 
> I wasn't referring to you.  We have a person who produces cygwin bash
> binaries for distribution.  It's his "job" to interface with you and
> make sure that patches are sent your way.  Unfortunately, he has
> disappeared from view so we're stuck with the usual grousing, 
> confusion,
> endless re-explanation, that people enjoy so much rather than having
> someone step forward to actually fix the problem and make a new binary
> release.
> 
> I know that you could easily fix the problem but I don't expect you to
> produce a new bash tar.gz file.
> 
> >Now, do you want all '\r's stripped, or \r\n translated to \n when
> >reading command substitution output?
> 
> \r\n -> \n.
> 
> Or maybe we should just have backticks delete all of the files on the
> machine that begin with "q" when a \r\n is detected.  People seem to
> like to discuss and theorize and agonize about this and this would
> certainly provide fuel for discussion.

That's a nice idea; how about setting a high-bandwith server to host the new
mailing list that such an important discussion surely deserve :-)

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Has CR/LF and cat problem with textutils-2.0 been solved?

[Bernard Dautrevaux]

> -----Original Message-----
> From: Chet Ramey [ mailto:chet@nike.ins.cwru.edu ]
> Sent: Wednesday, September 27, 2000 6:03 PM
> To: cygwin@sources.redhat.com
> Cc: chet@po.cwru.edu
> Subject: Re: Has CR/LF and cat problem with textutils-2.0 been solved?
> 
> 
> > >However *all* shells (and not only bash) *must* read the standard
> > >output of command expansion (backtick) in *text* mode, as it *does*
> > >expect text and is *not* willing to handle binary data there.
> > 
> > This was my point.  We fixed ash to do the right thing and 
> I've been waiting
> > patiently for the bash maintainer to fix bash as well.
> 
> How about a bug report?  Or maybe an email?  I don't read this list
> very often, so, unless I get mail about it, `waiting patiently' is
> probably not going to get the job done.
> 
> Now, do you want all '\r's stripped, or \r\n translated to \n when
> reading command substitution output?
> 

The latter for sure; stripping all '\r's would be a bad thing IMHO, as you
may want to *mean* 'carriage return' (for overstriking for example) and then
will output a single '\r'. 

As a matter of fact now (both in UNIX and Win32 worlds) if you want to
*mean* 'line feed' and not 'end of line', you have to emit '\r\n<spaces>'
and you have to know how many spaces to emit ;-< The only justification one
may put to the Win32 CR-LF sequence is to restore the real meaning of LF;
but as one already pointed out 99.9% (or more) of Win32 programs interpret a
lone LF the UNIX way :-)

Regards,

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Has CR/LF and cat problem with textutils-2.0 been solved?

[Bernard Dautrevaux]

> -----Original Message-----
> From: Fifer, Eric [ mailto:EFifer@sanwaint.com ]
> Sent: Wednesday, September 27, 2000 3:31 PM
> To: 'cygwin@sources.redhat.com'
> Subject: RE: Has CR/LF and cat problem with textutils-2.0 been solved?
> 
> 
	...
> >
> >This was my point.  We fixed ash to do the right thing and I've been
> waiting
> >patiently for the bash maintainer to fix bash as well.
> 
> Is it possible to get a better idea of what the "right thing" is?
> 
> + Perl has a similar backtick syntax, but is fine handling
>   binary data.  I think it would be wrong to cripple its
>   binary abilities by setting text mode on backtick input.
>   However, as cat works now, on a text mount this will fail:
> 
>     #!perl
>     $out = <<EOF;
>     hello
>     world
>     EOF
>     open(FH, ">foo");
>     print FH $out;
>     close(FH);
> 
>     $in = `cat foo`;
>     print "not ok\n" if($out ne $in);
> 

IMHO perl is wrong there: from a logical point of view (sorry I can't chek,
I don't have perl installed on Win32), $out should contain '\n' line endings
(after all PERL is a UNIX tool, so internally we can expect it to work the
UNIX style, or porting scripts will be a mess), then:

On a text mount FH will get '\r\n' file endings, that cat will preserve;
however the perl bactick *should* convert it to '\n' line endings (after all
we are handling TEXT in perl, isn't it?), so "$i eq $out"; so if PERL read
backtick output as text the program will work OK.

On a binary mount, everything is simpler: '\n' line endings everywhere :-)

The only problem I may see is that the script may be read from a binary
mount but contain '\r\n' line endings: in this case a 'quick' port of PERL
may get '\r\n' line endings from the here-document while still matching
'\r\n' to an end-of-line in the script proper (as this is probably two
different places to fix in the code); if this bug is present then th eabove
program should fail on a binary mount. 

So if the above program fails on WIN32 this *is* IMNSHO due to a bug (or
two) in perl.
 
> + On a text mount, this results in LF endings:
> 
> 	#!sh
> 	cat >foo <<EOF
> 	hello
> 	world
> 	EOF
> 
>   But, this has CR/LF endings:
> 
> 	echo hello >foo
> 	echo world >>foo
> 	

Yes but if backtick read in text mode, you get LF endings in `cat foo` and
that's the problem we are discussing here.

> + A text file on a text mount (CR/LF endings) and a text file
>   on a binary mount (LF endings) concatenated together.  The
>   current cat will result in a file with mixed CR/LF and LF
>   endings.
> 

Ditto

> + A binary file on a text mount copied into another file
>   (cat foo.exe >bar.exe).  This now works with the latest cat,
>   with the B20.1 cat it would have "translated" the file.
> 

That's why the proper behavior is the current cat, not the B20.1 one :-)
That's also why I think the backtick processing of bash should be checked
(and the one of PERL also IMO) to read in text mode whatever the mount or
the default is.

> Eric Fifer
> 

Regards,

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Has CR/LF and cat problem with textutils-2.0 been solved?

[Jason Tishler]

Chet,

On Wed, Sep 27, 2000 at 03:36:32PM -0400, Chet Ramey wrote:
> Well, geez, how hard can it be?  Here's the change I just made to
> subst.c:read_comsub().  Take a look -- I'm really dragging today and
> probably made an error.
> 
> *** subst.c~	Tue Sep 26 15:19:40 2000
> --- subst.c	Wed Sep 27 15:38:09 2000
> ***************
> *** 3361,3364 ****
> --- 3361,3372 ----
>   
>         istring[istring_index++] = c;
> + 
> + #if defined (__CYGWIN__)
> +       if (c == '\n' && istring_index > 1 && istring[istring_index - 2] == '\r')
> + 	{
> + 	  istring_index--;
> + 	  istring_index[-1] = '\n';
> + 	}
> + #endif
>       }

Shouldn't the following line:

    istring_index[-1] = '\n';

be changed to:

    istring[istring_index - 1] = '\n';

instead?

Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corporation         Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Has CR/LF and cat problem with textutils-2.0 been solved?

[Chet Ramey]

> On Wed, Sep 27, 2000 at 01:03:45PM -0400, Chet Ramey wrote:
> >> >Now, do you want all '\r's stripped, or \r\n translated to \n when
> >> >reading command substitution output?
> >> 
> >> \r\n -> \n.
> >
> >OK, bash-2.05 will do that.
> 
> Wow, that's responsive.

Well, geez, how hard can it be?  Here's the change I just made to
subst.c:read_comsub().  Take a look -- I'm really dragging today and
probably made an error.

*** subst.c~	Tue Sep 26 15:19:40 2000
--- subst.c	Wed Sep 27 15:38:09 2000
***************
*** 3361,3364 ****
--- 3361,3372 ----
  
        istring[istring_index++] = c;
+ 
+ #if defined (__CYGWIN__)
+       if (c == '\n' && istring_index > 1 && istring[istring_index - 2] == '\r')
+ 	{
+ 	  istring_index--;
+ 	  istring_index[-1] = '\n';
+ 	}
+ #endif
      }
  

> Are you sure you don't want to make a cygwin
> binary release?  Imagine the prestige, the acclaim!

It's hard to resist, but I have no means to make one.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet)

Chet Ramey, CWRU    chet@po.CWRU.Edu    http://cnswww.cns.cwru.edu/~chet/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Has CR/LF and cat problem with textutils-2.0 been solved?

[Chris Faylor]

On Wed, Sep 27, 2000 at 01:03:45PM -0400, Chet Ramey wrote:
>> >Now, do you want all '\r's stripped, or \r\n translated to \n when
>> >reading command substitution output?
>> 
>> \r\n -> \n.
>
>OK, bash-2.05 will do that.

Wow, that's responsive.  Are you sure you don't want to make a cygwin
binary release?  Imagine the prestige, the acclaim!

>> Or maybe we should just have backticks delete all of the files on the
>> machine that begin with "q" when a \r\n is detected.  People seem to
>> like to discuss and theorize and agonize about this and this would
>> certainly provide fuel for discussion.
>
>Why not just remove csh? ;-)

Fine with me.  Is there still time to get this into 2.05? :-)

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Has CR/LF and cat problem with textutils-2.0 been solved?

[Chet Ramey]

> >How about a bug report?  Or maybe an email?  I don't read this list
> >very often, so, unless I get mail about it, `waiting patiently' is
> >probably not going to get the job done.
> 
> I wasn't referring to you.  We have a person who produces cygwin bash
> binaries for distribution.  It's his "job" to interface with you and
> make sure that patches are sent your way.  Unfortunately, he has
> disappeared from view so we're stuck with the usual grousing, confusion,
> endless re-explanation, that people enjoy so much rather than having
> someone step forward to actually fix the problem and make a new binary
> release.

``Every day, the same old dizzy dance.''

> I know that you could easily fix the problem but I don't expect you to
> produce a new bash tar.gz file.
> 
> >Now, do you want all '\r's stripped, or \r\n translated to \n when
> >reading command substitution output?
> 
> \r\n -> \n.

OK, bash-2.05 will do that.

> Or maybe we should just have backticks delete all of the files on the
> machine that begin with "q" when a \r\n is detected.  People seem to
> like to discuss and theorize and agonize about this and this would
> certainly provide fuel for discussion.

Why not just remove csh? ;-)

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet)

Chet Ramey, CWRU    chet@po.CWRU.Edu    http://cnswww.cns.cwru.edu/~chet/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Has CR/LF and cat problem with textutils-2.0 been solved?

[Chris Faylor]

On Wed, Sep 27, 2000 at 02:30:31PM +0100, Fifer, Eric wrote:
>>This was my point.  We fixed ash to do the right thing and I've been
>>waiting patiently for the bash maintainer to fix bash as well.
>
>Is it possible to get a better idea of what the "right thing" is?

The "right thing" is for shells to read their input in text mode.  How
many times does this have to be repeated?

>+ Perl has a similar backtick syntax, but is fine handling
>  binary data.  I think it would be wrong to cripple its
>  binary abilities by setting text mode on backtick input.
>  However, as cat works now, on a text mount this will fail:

Perl is not a shell.  We have an immediate problem: bash.  bash needs to
have its back tick handling "fixed" (I hate to characterise accomodating
this CRLF nonsense as fixing anything).  I asked the *cygwin* bash
maintainer to do this months ago and he has not been responsive in doing
this.  So, I'm looking for another *cygwin* bash maintainer.

There is no reason to throw perl, python, awk, sed, or gnuplot into the
mix and theorize about a grand unified plan for what to do whenever
program 'foo' finds a backtick.  We just need someone who is willing to
make the changes to bash.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Has CR/LF and cat problem with textutils-2.0 been solved?

[Chris Faylor]

On Wed, Sep 27, 2000 at 12:03:09PM -0400, Chet Ramey wrote:
>> >However *all* shells (and not only bash) *must* read the standard
>> >output of command expansion (backtick) in *text* mode, as it *does*
>> >expect text and is *not* willing to handle binary data there.
>> 
>> This was my point.  We fixed ash to do the right thing and I've been waiting
>> patiently for the bash maintainer to fix bash as well.
>
>How about a bug report?  Or maybe an email?  I don't read this list
>very often, so, unless I get mail about it, `waiting patiently' is
>probably not going to get the job done.

I wasn't referring to you.  We have a person who produces cygwin bash
binaries for distribution.  It's his "job" to interface with you and
make sure that patches are sent your way.  Unfortunately, he has
disappeared from view so we're stuck with the usual grousing, confusion,
endless re-explanation, that people enjoy so much rather than having
someone step forward to actually fix the problem and make a new binary
release.

I know that you could easily fix the problem but I don't expect you to
produce a new bash tar.gz file.

>Now, do you want all '\r's stripped, or \r\n translated to \n when
>reading command substitution output?

\r\n -> \n.

Or maybe we should just have backticks delete all of the files on the
machine that begin with "q" when a \r\n is detected.  People seem to
like to discuss and theorize and agonize about this and this would
certainly provide fuel for discussion.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Has CR/LF and cat problem with textutils-2.0 been solved?

[Chet Ramey]

> >However *all* shells (and not only bash) *must* read the standard
> >output of command expansion (backtick) in *text* mode, as it *does*
> >expect text and is *not* willing to handle binary data there.
> 
> This was my point.  We fixed ash to do the right thing and I've been waiting
> patiently for the bash maintainer to fix bash as well.

How about a bug report?  Or maybe an email?  I don't read this list
very often, so, unless I get mail about it, `waiting patiently' is
probably not going to get the job done.

Now, do you want all '\r's stripped, or \r\n translated to \n when
reading command substitution output?

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet)

Chet Ramey, CWRU    chet@po.CWRU.Edu    http://cnswww.cns.cwru.edu/~chet/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Has CR/LF and cat problem with textutils-2.0 been solved?

[Fifer, Eric]

Chris Faylor wrote:
>On Tue, Sep 26, 2000 at 07:59:27PM +0200, Bernard Dautrevaux wrote:
>>> From: Matthew Smith
>>> 
>>> I would be interested in comments from the mailing list.  If 
>>> people want
>>> \r's stripped, I will implement the changes.
>>>
>>>>I think it is arguable whether cat should strip CRs or not.  It is not
>>>>arguable whether bash's backtick handling should treat its input as
>>>text mode.
>>
>>However *all* shells (and not only bash) *must* read the standard
>>output of command expansion (backtick) in *text* mode, as it *does*
>>expect text and is *not* willing to handle binary data there.
>
>This was my point.  We fixed ash to do the right thing and I've been
waiting
>patiently for the bash maintainer to fix bash as well.

Is it possible to get a better idea of what the "right thing" is?

+ Perl has a similar backtick syntax, but is fine handling
  binary data.  I think it would be wrong to cripple its
  binary abilities by setting text mode on backtick input.
  However, as cat works now, on a text mount this will fail:

    #!perl
    $out = <<EOF;
    hello
    world
    EOF
    open(FH, ">foo");
    print FH $out;
    close(FH);

    $in = `cat foo`;
    print "not ok\n" if($out ne $in);

+ On a text mount, this results in LF endings:

	#!sh
	cat >foo <<EOF
	hello
	world
	EOF

  But, this has CR/LF endings:

	echo hello >foo
	echo world >>foo
	
+ A text file on a text mount (CR/LF endings) and a text file
  on a binary mount (LF endings) concatenated together.  The
  current cat will result in a file with mixed CR/LF and LF
  endings.

+ A binary file on a text mount copied into another file
  (cat foo.exe >bar.exe).  This now works with the latest cat,
  with the B20.1 cat it would have "translated" the file.

Eric Fifer


__________________________________________________________________________________

IMPORTANT: This email is confidential and may also be legally privileged. If you have received this email in error, you are on notice of its status. If you are not the intended recipient, please notify us immediately by reply email or by telephoning Sanwa International plc's IT Helpdesk on +44 (20) 7330 0444. Then delete this email from your system. You should not copy it or use it for any purpose or disclose its contents to any other person.

Any views contained herein, express or implied, are those of the author and may not necessarily reflect those of Sanwa International plc. Sanwa International plc reserves the right to monitor all emails within its network. Email may be susceptible to virus infection, data corruption, interception and unauthorised amendment. Sanwa International plc does not accept liability for any such infection, corruption, interception or amendment or the consequences thereof.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Has CR/LF and cat problem with textutils-2.0 been solved?

[Earnie Boyd]

I don't know exactly where to begin, I'm having trouble formulating any
connected thoughts on this.  So let me try to summarize:

1) MSDOS/WIN32 has two file processing modes that produce two different line
   endings.
   A) Normal default is "Text Mode".
   B) Default can be changed just by adding an object that does nothing except
      sets the default value of the external variable _filemode.
   C) File processing mode can be explicit set.

2) Cygwin tries to emulate as much of UNIX as possible but must live within
   the given MSDOS/WIN32 environment.
   A) Gives the users a choice about what the default processing mode should be
      for a given "mount point".
   B) Provides objects to set the external _filemode variable.
   C) Provides defaults via the [no]binmode CYGWIN setting for the Non-Cygwin
      shells for piping and redirection.
   D) Provides the POSIX runtime to allow UNIX programs to be "ported" easily
      to the Win32 platform.

3) There are a wide variety of users.
   A) Strong in UNIX forced to use Win32
   B) Strong in Win32 and want to learn UNIX
   C) Just want to learn programming and don't have thousands of dollars to
      spend in software.
   D) The student who knows little about computing and just wants to get the
      assignment completed.

4) A wide variety of expectations for Cygwin.
   A) Behave exactly like UNIX.
   B) Behave exactly like MSDOS/WIN32.
   C) Take care of all of the idiosyncracies of the differences between UNIX
      and MSDOS/WIN32.
   D) Make the job easier without me doing any of the work.
   E) Someone else fix all of the bugs. ;)

5) UNIX and Unix programs don't handle the \r line ending.
   A) CR/LF problems exist in the UNIX environment.
   B) In UNIX one has to filter a file of \r\n to remove the \r before
      processing it.
   C) 99.9% of the Win32 programs understand files with the \n line endings.
      (NOTEPAD is the only program that I know that can't).

Given the above (and probably some items I've missed) what conclusions can we
come to about how Cygwin should treat the CR/LF line endings vs how the tools
should be ported to treat the CR/LF line endings?

I don't know that I can sanely draw a conclusion.  I myself use binary mounts
and translate any files that aren't UNIX compatible just as I would on UNIX. 
Should we modify the textutils family (this includes cat) to open the files
specifically in binary mode regardless of the mount point setting?  Well, IMO,
I don't think we should.  Should we add --text, --binary and --mixed switches
to the programs themselves?  IMO, yes we should.  Should the official release
of the GNU package contain these switches?  Well, they would be useful even on
UNIX if properly designed, so yes patches should be submitted to the package
maintainer.

So: 
Should we revert the change to cat?  Yes.

Should we add --text, --binary and --mixed switches to cat and any other
utility?  Yes.

Are there other changes with regard to CR/LF line endings?  Yes.

1) I would like for the mount command to default the file processing mode to
   whatever I have the root mount point set.  I.E. if / is text mode then
   set the new mount point unless specified to text mode and vice versa.

2) Change setup (and it may already do this) so that the /cygdrive prefix 
   default file processing mode is based on the chosen file processing mode.

3) Add a mixed file processing mode to the Cygwin mount table.
   (Mixed file processing would read in text mode and write in binary mode.)

Cheers,

=====
--- < http://earniesystems.safeshopper.com > ---
   Earnie Boyd: < mailto:earnie_boyd@yahoo.com >
            __Cygwin: POSIX on Windows__
Cygwin Newbies: < http://gw32.freeyellow.com/ >
           __Minimalist GNU for Windows__
    Mingw Home: < http://www.mingw.org/ >

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Has CR/LF and cat problem with textutils-2.0 been solved?

[Peter Ring]

I have observed a CR/LF problem with another textutil, sort. In this case
the problem seems to be internal to sort, but might be the result of changes
in the runtime library. I've described the problem here:
http://sources.redhat.com/ml/cygwin/2000-08/msg01199.html , and haven't had
the time to go into it until now.

While I personally feel that 'textmode' is a cul-de-sac better avoided in
the first place, it's a fact that some people rely on it. But we *must*
agree on how and where it should be implemented (so that I know how to avoid
it ;). In this conversation, some policy statements pop up, like:

 "cygwin *must* be UNIX compatible, so a cygwin-only option to cat would be
  unusable for all people sharing shell scripts or Makefiles between UNIX
and 
  cygwin"

 "However *all* shells (and not only bash) *must* read the standard output
of
  command expansion (backtick) in *text* mode, as it *does* expect text and
is
  *not* willing to handle binary data there."

I wonder if there's authoritative collection of these statements somewhere?
Most of the CR/LF (CR\LF CR\\LF 'CR\LF') problems that we see arise from
confusion or disagreement about what goes on where.

Kind regards,
Peter Ring


-----Original Message-----
From: Bernard Dautrevaux [ mailto:Dautrevaux@microprocess.com ]
Sent: 27. september 2000 09:27
To: 'Erik Nolte'; Bernard Dautrevaux; 'Matthew Smith'; Cygwin
Subject: RE: Has CR/LF and cat problem with textutils-2.0 been solved?


> -----Original Message-----
> From: Erik Nolte [ mailto:enolte@campuspipeline.com ]
> Sent: Tuesday, September 26, 2000 8:46 PM
> To: Bernard Dautrevaux; 'Matthew Smith'; Cygwin
> Subject: Re: Has CR/LF and cat problem with textutils-2.0 been solved?
> 
> 
> 
> It's interesting that cat was placed in the line-oriented 
> textutils package
> rather than something like fileutils or shellutils.  But then 
> again so was
> od and the checksum utilities like sum and md5sum.
> 
> What cat's -B option for?  Since it's not in the FSF documentation, I
> thought it was a cygwin addition that forced cat to *not* do 
> the LF to CR-LF
> output translation.  To me it implies that cat is reading and 
> writing in
> textmode, not binmode.
> 
> Since it will take a while to fix all the shells, should a 
> --text flag be
> added to cat?  I know it's ugly, but it saves people the 
> trouble of having
> to find a B20.1 version of cat.

I don't think so; the first reason is that you have the problem for all
commands you use in backticks, be it cat or ls or a series of echoes (or at
least you should have the problem; I had to reinstall B20.1 for another
reason -- user compatibility for support :-) --  so I can't check right now,
but th eproper behavior is that all these write in text and as such they may
output CR/LFs).

The second reason is that cygwin *must* be UNIX compatible, so a cygwin-only
option to cat would be unusable for all people sharing shell scripts or
Makefiles between UNIX and cygwin ;-(

The third reason is that (as Chris already answered) you can use ash instead
of bash: ash *was* fixed in this respect and correctly strip CRs from the
output of backticks.

The last reason is that you can look at the source and submit a patch :-)

Regards,

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Has CR/LF and cat problem with textutils-2.0 been solved?

[Bernard Dautrevaux]

> -----Original Message-----
> From: Erik Nolte [ mailto:enolte@campuspipeline.com ]
> Sent: Tuesday, September 26, 2000 8:46 PM
> To: Bernard Dautrevaux; 'Matthew Smith'; Cygwin
> Subject: Re: Has CR/LF and cat problem with textutils-2.0 been solved?
> 
> 
> 
> It's interesting that cat was placed in the line-oriented 
> textutils package
> rather than something like fileutils or shellutils.  But then 
> again so was
> od and the checksum utilities like sum and md5sum.
> 
> What cat's -B option for?  Since it's not in the FSF documentation, I
> thought it was a cygwin addition that forced cat to *not* do 
> the LF to CR-LF
> output translation.  To me it implies that cat is reading and 
> writing in
> textmode, not binmode.
> 
> Since it will take a while to fix all the shells, should a 
> --text flag be
> added to cat?  I know it's ugly, but it saves people the 
> trouble of having
> to find a B20.1 version of cat.

I don't think so; the first reason is that you have the problem for all
commands you use in backticks, be it cat or ls or a series of echoes (or at
least you should have the problem; I had to reinstall B20.1 for another
reason -- user compatibility for support :-) --  so I can't check right now,
but th eproper behavior is that all these write in text and as such they may
output CR/LFs).

The second reason is that cygwin *must* be UNIX compatible, so a cygwin-only
option to cat would be unusable for all people sharing shell scripts or
Makefiles between UNIX and cygwin ;-(

The third reason is that (as Chris already answered) you can use ash instead
of bash: ash *was* fixed in this respect and correctly strip CRs from the
output of backticks.

The last reason is that you can look at the source and submit a patch :-)

Regards,

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Has CR/LF and cat problem with textutils-2.0 been solved?

[Chris Faylor]

On Tue, Sep 26, 2000 at 07:59:27PM +0200, Bernard Dautrevaux wrote:
>> -----Original Message-----
>> From: Matthew Smith [ mailto:matts@bluesguitar.org ]
>> Sent: Tuesday, September 26, 2000 7:59 PM
>> To: Cygwin
>> Subject: Re: Has CR/LF and cat problem with textutils-2.0 been solved?
>> 
>> 
>> I would be interested in comments from the mailing list.  If 
>> people want
>> \r's stripped, I will implement the changes.
>
>	...
> 
>>>I think it is arguable whether cat should strip CRs or not.  It is not
>>>arguable whether bash's backtick handling should treat its input as
>>text mode.
>
>However *all* shells (and not only bash) *must* read the standard
>output of command expansion (backtick) in *text* mode, as it *does*
>expect text and is *not* willing to handle binary data there.

This was my point.  We fixed ash to do the right thing and I've been waiting
patiently for the bash maintainer to fix bash as well.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Has CR/LF and cat problem with textutils-2.0 been solved?

[Erik Nolte]

> I don't think cat should strip \r's on input; I quite often use cat to
> concatenate binary data :-)
>
> However *all* shells (and not only bash) *must* read the standard output
of
> command expansion (backtick) in *text* mode, as it *does* expect text and
is
> *not* willing to handle binary data there.
>
> The problem here is thus IMNSHO in cat but in the shell, so *please* don't
> feed the cat with a new bug :-)

I agree.  Bash should do the CR-LF conversion for both forms of command
output expansion: `cmd` and $(cmd).  Sh should do the conversion for the
backticks form.

It's interesting that cat was placed in the line-oriented textutils package
rather than something like fileutils or shellutils.  But then again so was
od and the checksum utilities like sum and md5sum.

What cat's -B option for?  Since it's not in the FSF documentation, I
thought it was a cygwin addition that forced cat to *not* do the LF to CR-LF
output translation.  To me it implies that cat is reading and writing in
textmode, not binmode.

Since it will take a while to fix all the shells, should a --text flag be
added to cat?  I know it's ugly, but it saves people the trouble of having
to find a B20.1 version of cat.

- Erik


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Has CR/LF and cat problem with textutils-2.0 been solved?

[Bernard Dautrevaux]

> -----Original Message-----
> From: Matthew Smith [ mailto:matts@bluesguitar.org ]
> Sent: Tuesday, September 26, 2000 7:59 PM
> To: Cygwin
> Subject: Re: Has CR/LF and cat problem with textutils-2.0 been solved?
> 
> 
> I would be interested in comments from the mailing list.  If 
> people want
> \r's stripped, I will implement the changes.

	...
 
> > I think it is arguable whether cat should strip CRs or not. 
>  It is not
> arguable
> > whether bash's backtick handling should treat its input as 
> text mode.
> >
	...
> >
> > cgf
> >

I don't think cat should strip \r's on input; I quite often use cat to
concatenate binary data :-)

However *all* shells (and not only bash) *must* read the standard output of
command expansion (backtick) in *text* mode, as it *does* expect text and is
*not* willing to handle binary data there.

The problem here is thus IMNSHO in cat but in the shell, so *please* don't
feed the cat with a new bug :-).

Regards,

		Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com