[net.bugs.4bsd] vi bug

mike@peregrine.UUCP (Mike Wexler) (07/23/85)

My standard shell is the /bin/csh.  When I try doing a any command
with a name that needs to be shell expanded the editor calls the shell,
but gets confused by the shell prompt and includes that in the file list.
This is a pain when using the n command, but makes things like e ~/.signature
impossible(at lease I don't no how to make it work.).
I do not have source code.  I am running on a SUN 2/120 under Unix 4.2BSD(Sun
release 2.00).
--------------------------------------------------------------------------------
Mike Wexler(trwrb!pertec!peregrine!mike) | Send all flames to:
15530 Rockfield, Building C              |	trwrb!pertec!peregrine!nobody
Irvine, Ca 92718                         | They will then be given the 
(714)855-3923                            | consideration they are due.

-- 
--------------------------------------------------------------------------------
Mike Wexler(trwrb!pertec!peregrine!mike) | Send all flames to:
15530 Rockfield, Building C              |	trwrb!pertec!peregrine!nobody
Irvine, Ca 92718                         | They will then be given the 
(714)855-3923                            | consideration they are due.

john@genrad.UUCP (John P. Nelson) (07/26/85)

In article <144@peregrine.UUCP> mike@peregrine.UUCP (Mike Wexler) writes:
>My standard shell is the /bin/csh.  When I try doing a any command
>with a name that needs to be shell expanded the editor calls the shell,
>but gets confused by the shell prompt and includes that in the file list.

This is an easily solved problem.  No doubt you have a "set prompt" line in
your .cshrc.  Simply replace it with the following:

if ($?prompt) then
	set prompt="whatever> "
endif

This will not set your prompt unless it was already set to SOMETHING
(i.e. you are interactive!)

mp@allegra.UUCP (Mark Plotnick) (07/26/85)

Don't put any commands that may cause output (like tset or clear) in
your .cshrc file; place them in your .login file instead.

Also, in your .cshrc, make sure that any csh variables that may cause
output (such as prompt, mail, or time) are only set if the csh
is an interactive one, e.g.

if ($?prompt) then
   set time=(10 "%Uu %Ss %E %P %Xktext+%Dkdata %Ireads %Owrites %Fpf %Wswaps")
   set prompt="`hostname | sed s/tempo-//`% "
endif

ron@men1.UUCP (Ron Flax) (07/26/85)

> My standard shell is the /bin/csh.  When I try doing a any command
> with a name that needs to be shell expanded the editor calls the shell,
> but gets confused by the shell prompt and includes that in the file list.
> This is a pain when using the n command, but makes things like e ~/.signature
> impossible(at lease I don't no how to make it work.).
> I do not have source code.  I am running on a SUN 2/120 under Unix 4.2BSD(Sun
> release 2.00).

Try putting your 'set prompt=xx' in .login not .cshrc!  .login is only
read when you login and .cshrc is read each time you call the shell.
You should probably only put aliases in .cshrc.

--
Ron Flax  (ron@men1.UUCP)
ARPA:	men1!ron@seismo.arpa
UUCP:	..!{seismo,rlgvax,cal-unix}!men1!ron
USPS:	1501 Wilson Blvd., Suite 500, Arlington VA  22209

robert@gitpyr.UUCP (Robert Viduya) (07/27/85)

In article <144@peregrine.UUCP>, mike@peregrine.UUCP (Mike Wexler) writes:
> My standard shell is the /bin/csh.  When I try doing a any command
> with a name that needs to be shell expanded the editor calls the shell,
> but gets confused by the shell prompt and includes that in the file list.

The problem isn't in vi, but in csh.  Whenever csh starts up as a non-
interactive shell, it unsets the prompt variable.  An unset prompt var-
iable will never get mixed up in other program output.  If your .cshrc
file goes ahead and sets the prompt then it will print out the prompt
when it thinks it's supposed to.  The solution, in your .cshrc, is to
check if the prompt is already set to something ('% ') and, if it is
then set it to what you want it to be, otherwise leave it alone.  The
following is similar to what I have in my .cshrc:

    if ${?prompt} then     # don't set prompt if not set (only with -c/-t flag)
	set prompt="Prompt> "
    endif

Hope this helps....

					robert
-- 
Robert Viduya							01111000
Georgia Institute of Technology

...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert
...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert

ramey@waltz (07/29/85)

I remember seeing the filename expansion from vi (or mail, or ...)
before.  We finally tracked down the problem to the fact that when
the csh was called to do the echo, it first printed out the prompt,
then the output of the echo, then the prompt again.  Note that this
only happened when you have a `set prompt ...' in your .cshrc.
If you use the default prompt, or set the prompt in your .login, there
was no problem.  Seems the csh knows it shouldn't print the prompt
in a non-interactive shell.  Instead of using an if statement around
the prompt printing code, they just don't give the prompt an initial
value, so the csh prints out a null prompt.  So, if you set your prompt
in the .cshrc file, the prompt is echoed.  The fix to the csh source
is easy; if you don't have source, just don't set the prompt in the .cshrc
(or as was pointed out before, only set the prompt in an interactive shell).

Joe Ramey
convex!smu!waltz!ramey

pedz@ctvax (07/30/85)

Reason 8491 why I hate csh(1):
The solution is to fix csh(1) so that it does not print the
prompt string on non-interactive shells.  I have fixed my csh(1)
to do just that.

pedz@ctvax

malloy@ittral.UUCP (William P. Malloy) (07/30/85)

> From: mike@peregrine.UUCP (Mike Wexler)
> 
> My standard shell is the /bin/csh.  When I try doing a any command
> with a name that needs to be shell expanded the editor calls the shell,
> but gets confused by the shell prompt and includes that in the file list.
> This is a pain when using the n command, but makes things like e ~/.signature
> impossible(at lease I don't no how to make it work.).
> I do not have source code.  I am running on a SUN 2/120 under Unix 4.2BSD(Sun
> release 2.00).

Your problem is with C Shell and not with vi.  The problem comes due to the
interaction of resetting shell variables in non-interactive shells.  I run into
this here every couple of months when someone plays with their .cshrc file.
See the reminder I wrote to myself (below) in my .cshrc file [I kept forget-
ting about it].  What it means is make sure ALL set's are done inside such an
``if (?prompt) then set var=value endif'' structure and you'll be safe.
#
# The reason for setting a prompt only if a prompt already exists.
#
# If it sets a prompt in a non-interactive shell, for instance vi(1)
# firing up a sub-shell to expand shell meta-characters, the set prompt
# will stomp on alot of shell variables used for the expansion (like ~)
#
if ( $?prompt ) then
   set history=500
   set mail=/usr/spool/mail/malloy
   set prompt="`hostname`:$cwd> "
   set histchars=",;"
   set cdpath=(~ ~/work /usr/src/local)
   set path=(. /usr/new /usr/new/mh ~/mybin ~/mycmd /usr/local/staff $path)
endif
-- 
Address: William P. Malloy, ITT Telecom, B & CC Engineering Group, Raleigh NC
         {ihnp4!mcnc, burl, ncsu, decvax!ittvax}!ittral!malloy

frank@aaec.OZ (Frank Crawford) (07/31/85)

> My standard shell is the /bin/csh.  When I try doing a any command
> with a name that needs to be shell expanded the editor calls the shell,
> but gets confused by the shell prompt and includes that in the file list.
> This is a pain when using the n command, but makes things like e ~/.signature
> impossible(at lease I don't no how to make it work.).
> I do not have source code.  I am running on a SUN 2/120 under Unix 4.2BSD(Sun
> release 2.00).

	The problem is probably caused by you unconditionally setting your
prompt in your `.cshrc'.  What happens is that when /bin/csh is invoked
by `vi' it does it in such a way that the prompt is undefined.   What you
need to do is test if it is defined before you set it, i.e.

if ($?prompt == 1) set prompt="my prompt[\!] "

That should fix it.

						Frank Crawford

ACSnet:	frank@aaec.OZ
UUCP:	...{decvax,vax135,eagle,pesnta}!mulga!aaec!frank

pilotti@telesoft.UUCP (Keith Pilotti @shine) (08/07/85)

In article <190@ittral.UUCP> malloy@ittral.UUCP (William P. Malloy) writes:
>> From: mike@peregrine.UUCP (Mike Wexler)
>> 
>> My standard shell is the /bin/csh.  When I try doing a any command
>> with a name that needs to be shell expanded the editor calls the shell,
>> but gets confused by the shell prompt and includes that in the file list.
>> ...
>
>Your problem is with C Shell and not with vi.
>...

    Under 4.2BSD, the best solution seems to be the following:

        %%%%%%%%
        .cshrc
        %%%%%%%%
        set path = ( . ~ ~/bin ~/frammis /usr/ucb /usr/bin /bin )
        if ( ! $?prompt ) exit
        # IF THIS IS A NON-INTERACTIVE SHELL, EXIT IMMEDIATELY!
        ...
        <rest of your (interactive) run commands>

    This supports command execution finding the commands you expect, and
    avoids problems (and delays) when issueing shell commands from the
    editor, as well as in remote commands (via rsh and rcp). 

    If there are other things you desire to be set always, just include them
    before the "if ... exit", though the fewer there are, the faster shell
    startup will be.  In particular, no output-producing commands (eg. echo)
    should appear prior to the "if ... exit" line.

    The deficiency with the previous example is that the C-shell must
    continue to read the ".cshrc" file to find the "endif"  where the above
    forces it to exit immediately after determining that it is a
    non-interactive shell.

    /+\ Keith
    ________________________________________________________
    KEITH F. PILOTTI -- TeleSoft         (619) 457-2700 x172
                        10639 Roselle St, SanDiego, CA 92121

        (UUCP) {decvax,ucbvax}!sdcsvax!telesoft!pilotti
        (ARPA) Pilotti@UCSD

mouse@mcgill-vision.UUCP (der Mouse) (08/09/85)

There's a way around the prompt problem which still allows you to set your
prompt in the .cshrc (so you get it in subshells).  Simply place

if $?prompt then
  ....
endif

around the `set prompt' and any similar commands (such as the aliases some
people have for cd/pushd/popd which modify the prompt....).

					der Mouse

peter@graffiti.UUCP (Peter da Silva) (09/02/85)

> Reason 8491 why I hate csh(1):
> The solution is to fix csh(1) so that it does not print the
> prompt string on non-interactive shells.  I have fixed my csh(1)
> to do just that.

No need to do this, just don't set the prompt string in your .cshrc, since
CSH doesn't set the prompt string on non-interactive shells. In your
.cshrc you can tell if the shell is interactive or not and act as follows:

if ( $?prompt ) then
	set prompt=...
	blah blah blah
endif

peter@graffiti.UUCP (Peter da Silva) (09/02/85)

Oh yeh, my main gripe with CSH: It expands *history* in non-interactive shells,
which makes it a pain to do a uucp mail from vi, which also expands history.
My solution? At the end of my .cshrc I add the line: "setenv SHELL /bin/sh".

dce@hammer.UUCP (David Elliott) (09/04/85)

In article <155@graffiti.UUCP> peter@graffiti.UUCP (Peter da Silva) writes:
>Oh yeh, my main gripe with CSH: It expands *history* in non-interactive shells,
>which makes it a pain to do a uucp mail from vi, which also expands history.
>My solution? At the end of my .cshrc I add the line: "setenv SHELL /bin/sh".

How about this for weird:

	% cat foo
	#!/bin/csh -f
	set histchars=""
	echo !!
	echo ""
	echo " "
	% foo
	!!

	%

I know what "feature" I'm going to add to my manual pages.

			David Elliott

andrew@stc.UUCP (Andrew Macpherson) (09/05/85)

In article <155@graffiti.UUCP> peter@graffiti.UUCP (Peter da Silva) writes:
>Oh yeh, my main gripe with CSH: It expands *history* in non-interactive shells,
>which makes it a pain to do a uucp mail from vi, which also expands history.
>My solution? At the end of my .cshrc I add the line: "setenv SHELL /bin/sh".

That's rather extreme: how about

if ( ! $?prompt ) then
	set histchars=''
	exit
endif
interactive csh bits...

That way you can still get your real SHELL from more and simmilar...

-- 
Regards,
	Andrew Macpherson.	<andrew@stc.UUCP>
	{creed, datlog, idec, iclbra, iclkid, root44, stl, ukc}!stc!andrew