Subject: RE: echo is wrong...
From: [email-masked] (Richard Y. Kim)

10 Apr 1998 19:40:36 -0700
Message-ID: <[email-masked]>
References: <01BD62C4.F53168D0@sos>
Reply-To: [email-masked]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [email-masked]
Cc: [email-masked], Sergey Okhapkin <[email-masked]>,
        [email-masked]

Sergey Okhapkin wrote:

> [email-masked] 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
[email-masked]

-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".