Mail Archives: cygwin/1998/04/10/19:40:36
Sergey Okhapkin wrote:
> marcus AT bighorn DOT dr DOT lucent DOT com wrote:
> > > In the Linux
> > >
> > > [nagyl AT 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 AT ElectronicDNA DOT com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -