Re: Broken stdio using sh.exe?

Re: Broken stdio using sh.exe?

[robert.jan.schutten]

>At 05:11 AM 3/6/2001, robert.jan.schutten@philips.com wrote:
>>The problem:
>>------------
>>
>>Using bash to read from stdin works as expected:
>>
>>schutten@PC6868 ~/tmp
>>$ cat test.bin | ./readbin.bash
>>61 62 63 64 1a 61 62 63
>>
>>Using sh to read from stdin stops after the ^Z (hex: 1a) character:
>>
>>schutten@PC6868 ~/tmp
>>$ cat test.bin | ./readbin.sh
>>4 bytes read, 8 expected
>
>
>Actually, I thought bash had been changed to work like sh.  The "problem"
>is sh (or ash in this case) reads stuff in textmode.  This allows it to not
>trip over text mode input, which we see allot on Windows.  However, this 
>means that it interprets characters in text mode, with all the pitfalls.
>^Z is an EOF in text mode.  Sorry, I don't have a solution for this problem.
>NOTE - this response is not meant to open up the text vs binary mode debate
>again.  Follow-up comments on this thread should keep this in mind.

Actually I have a workaround, I renamed sh.exe, and did ln -s bash.exe sh.exe in /bin.

I understand that ^Z is the problem, since it is the EOF character in DOS.

I was under the impression that the reading of text or binary mode of pipes and 
non-file devices is controlled by setting CYGWIN to binmode ar nobinmode
(where the default is binmode), see the Cygwin User's Guide:
http://www.cygwin.com/cygwin-ug-net/using-textbinary.html#AEN669
rule c, which states:
" Pipes and non-file devices are opened in binary mode, except if the CYGWIN 
  environment variable contains nobinmode."

If there is the intention to change bash to work like sh works now, then I am in trouble....
Also this seems to contradict the rule mentions in the Cygwin User's Guide.

--
With kind regards,
     Robert Jan Schutten 
  - "Imagination is more important than knowledge" - Einstein -
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Broken stdio using sh.exe?

[Christopher Faylor]

On Wed, Mar 07, 2001 at 01:10:33PM +0100, robert.jan.schutten@philips.com wrote:
>I was under the impression that the reading of text or binary mode of pipes and 
>non-file devices is controlled by setting CYGWIN to binmode ar nobinmode
>(where the default is binmode), see the Cygwin User's Guide:
> http://www.cygwin.com/cygwin-ug-net/using-textbinary.html#AEN669
>rule c, which states:
>" Pipes and non-file devices are opened in binary mode, except if the CYGWIN 
>  environment variable contains nobinmode."
>
>If there is the intention to change bash to work like sh works now, then I am in trouble....
>Also this seems to contradict the rule mentions in the Cygwin User's Guide.

bash != cygwin
sh != cygwin

The default for the Cygwin DLL has nothing to do with the decisions that a
program like bash or ash may make for its defaults.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Broken stdio using sh.exe?

[Larry Hall (RFK Partners, Inc)]

At 05:11 AM 3/6/2001, robert.jan.schutten@philips.com wrote:
>The problem:
>------------
>
>Using bash to read from stdin works as expected:
>
>schutten@PC6868 ~/tmp
>$ cat test.bin | ./readbin.bash
>61 62 63 64 1a 61 62 63
>
>Using sh to read from stdin stops after the ^Z (hex: 1a) character:
>
>schutten@PC6868 ~/tmp
>$ cat test.bin | ./readbin.sh
>4 bytes read, 8 expected


Actually, I thought bash had been changed to work like sh.  The "problem"
is sh (or ash in this case) reads stuff in textmode.  This allows it to not
trip over text mode input, which we see allot on Windows.  However, this 
means that it interprets characters in text mode, with all the pitfalls.
^Z is an EOF in text mode.  Sorry, I don't have a solution for this problem.
NOTE - this response is not meant to open up the text vs binary mode debate
again.  Follow-up comments on this thread should keep this in mind.

Thanks!


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Broken stdio using sh.exe?

[robert.jan.schutten]

Short description:
------------------

stdio seems to be broken when communicating from bash.exe to sh.exe.

How to reproduce the problem:
-----------------------------

5 files are needed:

1) A small C file, called readbin.c.
   It reads 8 bytes from stdin and prints the hexadecimal 
   values of the characters that are read.

-- start of readbin.c --

#include <stdlib.h>
#include <stdio.h>

#define NUM_READ 8

int
main (int argc, char *argv[])
{
    FILE *file_ptr = stdin;
    unsigned char buffer[8];
    size_t num_read;
    int i;

    /* read NUM_READ bytes and print values */
    num_read = fread (buffer, sizeof(unsigned char), NUM_READ, file_ptr);
    if (num_read == NUM_READ) {
        for (i = 0; i < NUM_READ; i++) {
             printf ("%2x ", (int)buffer[i]);
        }
        printf ("\n");
    } else {
        fprintf (stderr, "%d bytes read, %d expected\n", num_read, NUM_READ);
    }

    return EXIT_SUCCESS;
}

-- end of readbin.c --

2) The excutable readbin.exe, built with:

schutten@PC6868 ~/tmp
$ gcc -o readbin readbin.c

3) I have a small binary file, called test.bin, 
   on which the od gives:

schutten@PC6868 ~/tmp
$ od -t x1 test.bin
0000000 61 62 63 64 1a 61 62 63 64 0a
0000012

4) There is one shell script that calls readbin.exe via bash:

schutten@PC6868 ~/tmp
$ cat readbin.bash
#!/bin/bash
./readbin

5) There is one shell script that calls readbin.exe via sh:

schutten@PC6868 ~/tmp
$ cat readbin.sh
#!/bin/sh
./readbin

The problem:
------------

Using bash to read from stdin works as expected:

schutten@PC6868 ~/tmp
$ cat test.bin | ./readbin.bash
61 62 63 64 1a 61 62 63

Using sh to read from stdin stops after the ^Z (hex: 1a) character:

schutten@PC6868 ~/tmp
$ cat test.bin | ./readbin.sh
4 bytes read, 8 expected

On other operating systems (linux) both shell scripts work as expected.
Since all our shell scripts use /bin/sh, this problem occurs a lot
in our system (we want to work truely multi-platform, we use
shell scripts for all our exectables that automagically start the
correct executable in a certain platform).

Workaround:
-----------

Rename sh.exe to whatever you like.
Make a link from sh.exe to bash.exe.
This makes that all our shell scripts work again...

My system:
----------

schutten@PC6868 ~/tmp
$ /bin/cygcheck -s

Cygnus Win95/NT Configuration Diagnostics
Current System Time: Tue Mar  6 11:08:41 2001

WinNT Ver 5.0 build 2195 Service Pack 1

Path:   /home/local/bin
        /usr/local/bin
        /usr/bin
        /bin
        //c/Progra~1/Networ~1/PGPNT
        //c/Progra~1/MiKTeX/texmf/miktex/bin

SysDir: C:\WINNT\System32
WinDir: C:\WINNT

PWD = `/home/local/tmp'
CYGWIN = `ntsec tty'
USER = `schutten'
MAKE_MODE = `unix'
HOME = `/home/local'

Use `-r' to scan registry

c:  hd  NTFS    5726Mb  72% CP CS UN PA FC
f:  fd           N/A    N/A
h:  net Samba  43308Mb  47% CP CS              schutten
i:  net Samba  33640Mb  89%          PA        schutten
q:  net NTFS   42154Mb  83% CP CS UN PA FC
s:  net Samba  16820Mb  50% CP CS              softtv

C:\cygwin\bin  /usr/bin  user    binmode
C:\cygwin\lib  /usr/lib  user    binmode
C:\cygwin  /        user    binmode

Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwin\bin\cpp.exe
Found: C:\cygwin\bin\find.exe
Found: \bin\find.exe
Found: C:\cygwin\bin\gcc.exe
Found: C:\cygwin\bin\gdb.exe
Found: C:\cygwin\bin\ld.exe
Found: C:\cygwin\bin\ls.exe
Found: C:\cygwin\bin\make.exe
Found: C:\cygwin\bin\sh.exe

   56k 2000/12/03 C:\cygwin\bin\cygbz21.0.dll
   82k 2001/01/21 C:\cygwin\bin\cygform5.dll
   18k 2000/10/23 C:\cygwin\bin\cyggdbm.dll
   17k 2001/01/07 C:\cygwin\bin\cyghistory4.dll
   14k 2000/10/23 C:\cygwin\bin\cygintl.dll
   81k 2000/12/05 C:\cygwin\bin\cygitcl30.dll
   35k 2000/12/05 C:\cygwin\bin\cygitk30.dll
   45k 2000/10/22 C:\cygwin\bin\cygjbig1.dll
  119k 2000/10/23 C:\cygwin\bin\cygjpeg6b.dll
   53k 2001/01/21 C:\cygwin\bin\cygmenu5.dll
  414k 2001/01/21 C:\cygwin\bin\cygncurses++5.dll
  299k 2001/01/21 C:\cygwin\bin\cygncurses5.dll
   34k 2001/01/21 C:\cygwin\bin\cygpanel5.dll
  163k 2001/02/03 C:\cygwin\bin\cygpng2.dll
  108k 2001/01/07 C:\cygwin\bin\cygreadline4.dll
  390k 2000/12/05 C:\cygwin\bin\cygtcl80.dll
    5k 2000/12/05 C:\cygwin\bin\cygtclpip80.dll
   10k 2000/12/05 C:\cygwin\bin\cygtclreg80.dll
  243k 2000/10/23 C:\cygwin\bin\cygtiff3.dll
  623k 2000/12/05 C:\cygwin\bin\cygtk80.dll
   41k 2000/11/20 C:\cygwin\bin\cygXpm-noX4.dll
   45k 2000/11/20 C:\cygwin\bin\cygXpm-X4.dll
   49k 2001/02/03 C:\cygwin\bin\cygz.dll
  615k 2001/01/31 C:\cygwin\bin\cygwin1.dll
    Cygwin DLL version info:
        dll major: 1001
        dll minor: 8
        dll epoch: 19
        dll bad signal mask: 19005
        dll old termios: 5
        dll malloc env: 28
        api major: 0
        api minor: 34
        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
        cygdrive flags: cygdrive flags
        cygdrive prefix: cygdrive prefix
        cygdrive default prefix:
        build date: Wed Jan 31 10:08:38 EST 2001
        shared id: cygwin1S3

Use -h to see help about each section

--
With kind regards,
     Robert Jan Schutten
  - "Imagination is more important than knowledge" - Einstein -
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple