jackb@ptsfa.UUCP (02/03/87)
Has anyone noticed this problem:
Let's say that during a session of vi, you have your shell set
to /bin/ksh (from EXINIT, .exrc, or manual setting). Let's also
assume you're editing an existing file. When you perform
a shell escape with file name substitution using %, the
program you call says the file does not exist.
I think the problem is that the substitution is made using
eight-bit characters. I tried this experiment on a monitor
capable of displaying graphics characters ala ALT-?, and the file
name is gobbledygreek.
--
J.J.Bailey
Voice: 415-823-1958
uucp: {ihnp4,lll-crg,qantel,pyramid}!ptsfa!jackbboykin@custom.UUCP (02/05/87)
In article <2063@ptsfa.UUCP>, jackb@ptsfa.UUCP (Jack Bailey) writes: > Let's say that during a session of vi, you have your shell set > to /bin/ksh (from EXINIT, .exrc, or manual setting). Let's also > assume you're editing an existing file. When you perform > a shell escape with file name substitution using %, the > program you call says the file does not exist. > -- > J.J.Bailey The problem is that UNIX VI sets the most significant bit when the '%' meta-character is expanded. Csh and sh strip the data to 7-bit ASCII and hence there is no problem. Ksh doesn't, hence the lookup fails. This was one of the things we noticed when we did PC/VI, but couldn't figure out any good reasons why VI did this. Among other reasons why we didn't do this was that DOS's command.com isn't wild about setting the MSB either. Joe Boykin Custom Software Systems {necntc, frog}!custom!boykin
dlu@puffin.UUCP (02/05/87)
What is happening, I think, is that you are running the "International Korn
Shell" which uses an 8 bit character set. vi, erroneously I would say, passes
the file name to the shell with the high bits set and the shell dutifully gets
confused. There are two solutions - one is to fix vi, the other is to disable
the recognition of 8 bit characters in ksh. I quote from the README in
../ksh-i/src:
"This version passes 8-bit characters transparently. As a result programs
which assume that the shell will strip off the 8th bit will fail. In
particular, the vi command puts an 8th bit on the characters corresponding
to % when invoking a shell. The best solution is to fix the vi command.
However, if necessary, you can change the value of STRIP in sh/defs.h from
0377 to 0177 and rebuild a seven bit version of ksh-i."
The following fragment from ex_unix.c *seems* to be the sight of the dirty
deed (it was at line 74 on the 4.3beta version of ex):
case '%':
fp = savedfile;
if (*fp == 0) {
uxb[0] = 0;
error("No filename@to substitute for %%");
}
uexp:
printub++;
while (*fp) {
if (up >= &uxb[UXBSIZE])
goto tunix;
/*
* setting QUOTE confuses ksh-i
*
*up++ = *fp++ | QUOTE;
*/
*up++ = *fp++;
}
The expansion of '#' uses this code too, so this should be the only place
you need to fix. I haven't tested this yet, and I don't know why vi and
friends think that it is reasonable but it sure looks like the place...
Doug Urner dlu@puffin.USS.TEK.COM
(503)627-5037dcm@sfsup.UUCP (02/06/87)
In article <2063@ptsfa.UUCP> jackb@ptsfa.UUCP (Jack Bailey) writes: >Has anyone noticed this problem: > >Let's say that during a session of vi, you have your shell set >to /bin/ksh (from EXINIT, .exrc, or manual setting). Let's also >assume you're editing an existing file. When you perform >a shell escape with file name substitution using %, the >program you call says the file does not exist. > >I think the problem is that the substitution is made using >eight-bit characters. I tried this experiment on a monitor >capable of displaying graphics characters ala ALT-?, and the file >name is gobbledygreek. > >-- >J.J.Bailey >Voice: 415-823-1958 >uucp: {ihnp4,lll-crg,qantel,pyramid}!ptsfa!jackb Yep, I had this happen last week. The folks here booted a new release of Amdahl UTS and vi bit the dust. Recompiled vi and all was well. So, give that a try. The freaky thing with this nasty bug is that it disappears if you make your shell anything other than K-shell. That's the fix. Now can anyone explain what happened? Dave -- David C. Miller, consultant Communications Interface Addresses: Paperware: AT&T Information Systems, 190 River Road, Summit, NJ 07901 Liveware: (201) 522-6107 Software: {allegra,burl,cbosgd,clyde,ihnp4,ulysses}!sfsup!dcm ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On good days life is T.A.N.S.T.A.A.F.L. On days like today: T.A.N.S.T.A.A.L. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
hansen@pegasus.UUCP (02/07/87)
< the '%' meta-character is expanded. Csh and sh strip < the data to 7-bit ASCII and hence there is no problem. < Ksh doesn't, hence the lookup fails. < < This was one of the things we noticed when we did PC/VI, but < couldn't figure out any good reasons why VI did this. (I let this question go unanswered for a while waiting for someone else to answer first. Since no one has that I've seen, I will.) When the old Bourne/C shell saw an argument with the eighth bit set, it would treat the character as if it were hard-quoted and strip the 8th bit. Hard quoting normally comes from prefixing characters with \ or using ' around them. Vi always turned on the 8th bit for all arguments so that all file names would get passed to the shell as if they were quoted, so that characters within the name couldn't possibly be interpreted as shell metacharacters. This way, you can edit a file named "xyz*abc" and not have the "*" expanded when you use '%' on a ! command. Note that the System V release 3 Bourne shell, as well as the Korn shell, no longer does the 8th-bit stripping. Tony Hansen ihnp4!pegasus!hansen