Mail Archives: cygwin/2001/03/07/07:09:31
>At 05:11 AM 3/6/2001, robert DOT jan DOT schutten AT philips DOT com wrote:
>>The problem:
>>------------
>>
>>Using bash to read from stdin works as expected:
>>
>>schutten AT 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 AT 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
- Raw text -