🚀 go-pugleaf

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

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-5037

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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

< 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