btwomey@cbnewsj.att.com (william.tw0mey) (11/28/90)
I'm running System V, R3.2.3 and ksh88d. While in vi editing foo.c, with shell=/bin/ksh, if I try :! cc % I get a message to the effect that cc can't access foo.c. Now the interesting part is if I try :!echo % | od -c I get 0000000 f o o . c \n 346 357 357 256 343 012 0000006 which is the characters for "foo.c" but with the high order bits set. Is vi/ex compiled incorrectly? What flags have to be redefined for vi to pass the filename to the shell with the high order bits unset? Thanks, Bill Twomey, cbnewsj!btwomey attmail!btwomey journey!btwomey
btwomey@cbnewsj.att.com (william.tw0mey) (11/28/90)
Re: Message-ID: <1990Nov27.210425.25747@cbnewsj.att.com> For those of you that have replied to me, thanks. Let me clarify my post, I am editing an existing file. From within vi the following can happen :!echo % | od -c 0000000 f o o . c \n 346 357 357 256 343 012 Does ksh NOT have a convention that vi and other shells use? Thanks, Bill Twomey, cbnewsj!btwomey attmail!btwomey journey!btwomey
ndjc@hobbit.UUCP (Nick Crossley) (11/29/90)
In article <1990Nov27.210425.25747@cbnewsj.att.com> btwomey@cbnewsj.att.com (william.tw0mey) writes: >I'm running System V, R3.2.3 and ksh88d. While in vi editing >foo.c, with shell=/bin/ksh, if I try >:! cc % >I get a message to the effect that cc can't access foo.c. >Now the interesting part is if I try >:!echo % | od -c >I get >0000000 f o o . c \n > 346 357 357 256 343 012 >0000006 >which is the characters for "foo.c" but with the high order bits set. >What flags have to be redefined for vi to pass the filename to >the shell with the high order bits unset? The problem is that you are using an 8-bit clean version of ksh, with a partially 7-bit version of vi/ex. Older shells (csh and sh) used to (and in many versions still do) set the top bit of characters internally as a quoting mechanism. vi, somewhat rashly, uses this knowledge to quote the expansion of % and # filenames automatically, as if you had written '%' or '#'. Of course, when 8-bit clean shells such as recent versions of ksh appear, this behaviour of vi is broken, since such shells just accept the top bit as is. A fix is to change vi so that it does not attempt to 'quote' % and # filenames. If you are editing files with funny names, you might have to use explicit quotes around % or # in shell escapes; this seems eminently more reasonable to me than the 8-bit hack. An alternative would be to make vi actually put in \ and/or ' characters, but it seems hardly worth the effort. In Unix V.4, the quoting has been removed. Below is a patch to BSD and SysV[123] vi/ex to remove the 8-bit quoting. Your line numbers may vary depending on the version of vi, and because we have some source control info at the top of the files. *** port/ex_unix.c.old --- port/ex_unix.c *************** *** 77,83 **** while (*fp) { if (up >= &uxb[UXBSIZE]) goto tunix; ! *up++ = *fp++ | QUOTE; } break; } --- 77,83 ---- while (*fp) { if (up >= &uxb[UXBSIZE]) goto tunix; ! *up++ = *fp++; } break; } -- <<< standard disclaimers >>> Nick Crossley, ICL NA, 9801 Muirlands, Irvine, CA 92718-2521, USA 714-458-7282 uunet!ccicpg!ndjc / ndjc@ccicpg.UUCP
jeffr@bcs800.UUCP (Jeff Riegel) (11/29/90)
In <1990Nov28.140637.20499@cbnewsj.att.com> btwomey@cbnewsj.att.com (william.tw0mey) writes: >Re: Message-ID: <1990Nov27.210425.25747@cbnewsj.att.com> >For those of you that have replied to me, thanks. >Let me clarify my post, I am editing an existing file. >From within vi the following can happen >:!echo % | od -c >0000000 f o o . c \n > 346 357 357 256 343 012 >Does ksh NOT have a convention that vi and other shells use? >Thanks, >Bill Twomey, cbnewsj!btwomey attmail!btwomey journey!btwomey I have had problems using ksh with the '%', the workaroud is to put the following line in your .exrc file: set sh=/bin/sh This sets you comand shell back to bsh which seems to process the '%' properly.... -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jeff Riegel | uucp: ...!gatech!emory!bcs800!jeffr Technical Support | delphi: j2 tel: +800 444 3070 | A process is a terrible thing to waste!
guy@auspex.auspex.com (Guy Harris) (12/04/90)
>From within vi the following can happen >:!echo % | od -c >0000000 f o o . c \n > 346 357 357 256 343 012 > >Does ksh NOT have a convention that vi and other shells use? No, "ksh" is lacking a botch that some, but not all, shells have. I'm somewhat surprised that you're seeing this, given that you say you're running System V "R3.2.3". Is that actually a System V Release 3-flavored system, or is this a UNIX PC with its somewhat confusing release numbers? UNIX shells originally tended to use the 8th bit internally for quoting. "ex"/"vi", to its eternal shame, thought it "knew" this, and would quote the expansion of "%" in commands by turning on the 8th bit of all the characters in the expansion. Unfortunately for "ex"/"vi", this changed in System V Release 3; the Bourne shell was modified *not* to use the 8th bit for quoting, in order that 8-bit character sets such as ISO Latin 1 could be used in commands, file names, etc.. "ex"/"vi" was also changed in S5R3 not to bother quoting the expansion of "%" at all. Later versions of the Korn shell also don't use the 8th bit for quoting. The C shell as it comes from Berkeley does, but various vendors have modified it not to. I think some version of the Ultrix C shell doesn't, and the SunOS 4.1 C shell doesn't. The SunOS 4.1 C shell is the one upon which the System V Release 4 C shell is based. If, in fact, your machine is a UNIX PC, it probably has an older version of "ex"/"vi" that still thinks that shells use the 8th bit for quoting, and older versions of the Bourne and possibly C shells that do, in fact, use it for that; however, "ksh88d" is one of the later versions of the Korn shell, which doesn't use the 8th bit for quoting. As for your other questions: > Is vi/ex compiled incorrectly? The 4.3BSD "ex"/"vi" doesn't have any compile flag to turn off that quoting, so unless the "ex"/"vi" on your system was modified to have such a flag, no, it's not compiled incorrectly. > What flags have to be redefined for vi to pass the filename to > the shell with the high order bits unset? The 4.3BSD "ex"/"vi" has no such flags, so you're stuck unless you can convince "ksh" to strip the 8th bit off.
guy@auspex.auspex.com (Guy Harris) (12/05/90)
>Below is a patch to BSD and SysV[123] vi/ex to remove the 8-bit quoting. >Your line numbers may vary depending on the version of vi, and because >we have some source control info at the top of the files. auspex% cd s5r3_source/cmd/vi/port auspex% patch ex_unix.c <nicks_patch Hmm... Looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** port/ex_unix.c.old |--- port/ex_unix.c -------------------------- Patching file ex_unix.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] n S5R3's "ex"/"vi" *already* had the quoting removed....
ndjc@hobbit.UUCP (Nick Crossley) (12/06/90)
In article <4676@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >S5R3's "ex"/"vi" *already* had the quoting removed.... Yes, you are right. We must have had some mixed up version here, because we had some of the S5R3.* changes (other 8-bit clean up and other things), but for some reason not that one until I fixed it. I hope the fix is also going into BSD 4.4 (is it indeed already in 4.3reno?) -- <<< standard disclaimers >>> Nick Crossley, ICL NA, 9801 Muirlands, Irvine, CA 92718-2521, USA 714-458-7282 uunet!ccicpg!ndjc / ndjc@ccicpg.UUCP
sja2@cbnewsd.att.com (Steve Alesch) (12/10/90)
I have the following vi macros set-up: map ^K :se shell=/m1/exptools/bin/ksh^M map ^B :se shell=/bin/sh^M map ^P ^B:!chmod +x %^M ^K ^P will switch to bourne shell, execute a ``:!chmod +x %'' properly, and then switch back to korn shell. -- Steve Alesch, AT&T Bell Labs, ...!att!ihlpm!sja, (708)713-4188