From: rkim1 AT san DOT rr DOT com (Richard Y. Kim)
Subject: RE: echo is wrong...
10 Apr 1998 19:40:36 -0700
Message-ID: <199804090723.AAA17632.cygnus.gnu-win32@proxyb1.san.rr.com>
References: <01BD62C4 DOT F53168D0 AT sos>
Reply-To: rkim AT ElectronicDNA DOT com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: gnu-win32 AT cygnus DOT com
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


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".