This is the mail archive of the
cygwin@sourceware.cygnus.com
mailing list for the Cygwin project.
RE: echo is wrong...
- To: gnu-win32 at cygnus dot com
- Subject: RE: echo is wrong...
- From: "Richard Y. Kim" <rkim1 at san dot rr dot com>
- Date: Thu, 9 Apr 1998 00:23:25 -0700 (PDT)
- CC: rkim at ElectronicDNA dot com, Sergey Okhapkin <sos at buggy dot prospect dot com dot ru>, marcus at bighorn dot dr dot lucent dot com
- References: <01BD62C4.F53168D0@sos>
- Reply-To: rkim at ElectronicDNA dot com
Sergey Okhapkin wrote:
> marcus@bighorn.dr.lucent.com wrote:
> > > In the Linux
> > >
> > > [nagyl@piheno nagyl]$ echo "aaa"|od -c
> > > 0000000 a a a \n
> > > 0000004
> > >
> > > In the windows NT bash
> > >
> > > bash-2.01$ echo aaa|od -c
> > > 0000000 a a a \r \n
> > > 0000005
> > >
> > >
> > > What the hell is the \r ?????
> >
> > In the DOS/Win32 world, text files have CR LF line endings, as opposed to
> > Unix's LF only. Since echo generates text, it is simply following the
> > convention of the operating system and outputting a proper text file.
> >
>
> You're wrong. B19 _bash_ forces pipes to be text mode. Try the same in ash and feel the difference.
I did try this. As Sergey said, ash.exe does not insert \r.
bash.exe-2.01$ /bin/ash -c "echo aaa | od -c"
0000000 a a a \n
0000004
However, if the output of the "echo" command is first piped to a file,
then no \r is added by bash as shown here.
bash.exe-2.01$ /bin/bash -c "echo aaa | od -c"
0000000 a a a \r \n
0000005
bash.exe-2.01$ /bin/bash -c "echo aaa > foo; od -c foo"
0000000 a a a \n
0000004
This is very strange to me. I get different results depending on
whether I go through an intermediate file! I also experimented to see
how binary files would be handled.
# f1 is a file with 7 characters.
bash.exe-2.01$ od -c f1
0000000 001 002 003 \n 001 002 003
0000007
# f2 is also a file with 7 characters.
bash.exe-2.01$ od -c f2
0000000 004 005 006 \n 004 005 006
0000007
bash.exe-2.01$ cat f1 f2 | od -c
0000000 001 002 003 \r \n 001 002 003 004 005 006 \r \n 004 005 006
0000020
bash.exe-2.01$ cat f1 f2 > foo; od -c foo
0000000 001 002 003 \n 001 002 003 004 005 006 \n 004 005 006
0000016
Note that \r is added if the intermediate result is not saved to a file!
The next example illustrates that even though \r is added,
control-Z is not interpreted as end-of-file.
# f3 is same as f1 except that control-z (octal 032) is in the
# middle instead of \n.
bash.exe-2.01$ od -c f3
0000000 001 002 003 032 001 002 003
0000007
bash.exe-2.01$ cat f1 f3 | od -c
0000000 001 002 003 \r \n 001 002 003 001 002 003 032 001 002 003
0000017
Note that the three characters following 032 (control-z) was not truncated.
Finally, here is an example why I think all this is confusing to me.
# No problem. Compression and decompression is an identity operation.
bash.exe-2.01$ gzip -c /bin/ash.exe | gunzip > ash.exe2
bash.exe-2.01$ cmp /bin/ash.exe ash.exe2
# No problem if we pipe the intermediate results to files.
bash.exe-2.01$ gzip -c /bin/ash.exe > foo; split -b 10000 foo; cat x?? > foo; gunzip < foo > ash.exe2
bash.exe-2.01$ cmp /bin/ash.exe ash.exe2
# We have problems if we pipe output of 'gzip' to 'split' without going
# through an intermediary file.
bash.exe-2.01$ gzip -c /bin/ash.exe | split -b 10000; cat x?? > foo; gunzip < foo > ash.exe2
gunzip: stdin: invalid compressed data--format violated
bash.exe-2.01$
My environment is as follows.
Cyrix 6x86 150Mz CPU with 32MB RAM
Windows NT 4.0 SP3 with IE4 (MSDN Jan 98 cd-rom)
Cygwin32 b19 with cygwinb19.dll dated 980327 (Sergey's coolview).
All my disks are mounted as binary with "mount -b" option.
CYGWIN32=binmode
All the programs used in the code above was from cygwin32
as shown here:
bash.exe-2.01$ type gzip gunzip cmp split
gzip is hashed (/mnt/e/Programs/CYGNUS/B19/H-i386-cygwin32/bin/gzip)
gunzip is hashed (/mnt/e/Programs/CYGNUS/B19/H-i386-cygwin32/bin/gunzip)
cmp is hashed (/mnt/e/Programs/CYGNUS/B19/H-i386-cygwin32/bin/cmp)
split is hashed (/mnt/e/Programs/CYGNUS/B19/H-i386-cygwin32/bin/split)
bash.exe-2.01$
I searched the faq.txt file for "pipe". There is no match to this word
except on line 1974 where it lists POSIX subroutine names.
Richard Y. Kim
rkim@ElectronicDNA.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".