#!/bin/sh
cat EOF
[8bit text which contains 0x82 character]
EOF
And, if I use 'EOF' instead of EOF, it works fine. Do you have any
idea about this behavior?
And I want to quote that we Japanese often meet 0x82 because it
is contained in Shift_JIS encoding. :-(
h.h.
To Unsubscribe:
On Fri, 28 Jul 2000 12:09:51 +0900
Jun Kuriyama [EMAIL PROTECTED] said:
kuriyama Shell script which contains here-document of 8bit text sometimes dumps
kuriyama core. For example, please test this script in 4.1 or -current.
I'm using this for workaround on IMASY's main server. 3.5-RELEASE
In [EMAIL PROTECTED], Jun Kuriyama wrote:
#!/bin/sh
cat EOF
[8bit text which contains 0x82 character]
EOF
I'm very short of time these days, but here are thoughts and a
backtrace:
0x82 == \202 == CTLVAR in the parser. For real variable expansion,
the parser inserts \202 into the input
In [EMAIL PROTECTED], Hajimu UMEMOTO wrote:
On Fri, 28 Jul 2000 12:09:51 +0900
Jun Kuriyama [EMAIL PROTECTED] said:
kuriyama Shell script which contains here-document of 8bit text sometimes dumps
kuriyama core. For example, please test this script in 4.1 or -current.
I'm using this
On Fri, Jul 28, 2000 at 09:47:08AM +0200, Martin Cracauer wrote:
! if (c = CTLESC c = CTLQUOTEMARK) {
synentry = CWORD;
! fprintf(stderr,
! "Warning: internal control character in "
In [EMAIL PROTECTED], Andrey A. Chernov wrote:
On Fri, Jul 28, 2000 at 09:47:08AM +0200, Martin Cracauer wrote:
! if (c = CTLESC c = CTLQUOTEMARK) {
synentry = CWORD;
! fprintf(stderr,
!
On Fri, Jul 28, 2000 at 09:03:49AM +0200, Martin Cracauer wrote:
1) It seems that you can work around the coredump by looking at the
next char after \202. For real expansions of variables in
here-documents that is \201. Once can probably determine all
possible legal combinations
On Fri, Jul 28, 2000 at 03:20:19PM +0200, Martin Cracauer wrote:
Please refer to my previous mail. I think it's better to extend the
internal character handling to int* instead of obfuscating it even
more with escape sequences (remember that they are processed multiple
times and such things
I don't know you are the right person to ask, but I found you
committed some of 8bit cleaning in src/bin/sh.
Shell script which contains here-document of 8bit text sometimes dumps
core. For example, please test this script in 4.1 or -current.
#!/bin/sh
cat EOF
[8bit text which contains 0x82