[comp.sys.amiga] Csh and K_directive

nor1675@dsac.dla.mil (Michael Figg) (01/13/90)

I've tried to post this a couple times, from two different systems, but it
doesn't look like it has taken. Sorry if you have seen this before.


I've had a couple of problems with running shell scripts under Csh v2.07. I
don't use scripts often enough (although I can't seem to live without 
s:startup-sequence!) to have looked into the problem before. The latest was
a message of something along the line of "missing k directive" when trying to
execute the Lattice v5.04 patch against v5.02. I was able to get around this
by using WShell, but am curious about what the problem is with Csh. I vaguely
remember (now that I'm away from the machine) something about 'run execute'. Is
this the problem and does one of the newer versions of Csh address this? What is
the current version?

A slightly related (maybe more than I realize) question. I also tried using
the 'protect' command to set the script bit, but it seemed like under Csh it
also had no effect and the 's' didn't show up when running 'list' as I expected.I didn't check the bit under WShell, but the script ran without using    
'execute'.

Any enlightenment on this would be welcome. Thanks.
-- 
"Could we be the bellwether  | Michael Figg  DSAC-FSD
 of major societal shifts?"  | DLA Systems Automation Center - Columbus,Oh
mfigg@dsacg2.dsac.dla.mil

hull@hao.ucar.edu (Howard Hull) (01/15/90)

In Article <1643@dsac.dla.mil> Y'all said...
>a message of something along the line of "missing k directive" when trying to
>execute the Lattice v5.04 patch against v5.02. I was able to get around this
>by using WShell, but am curious about what the problem is with Csh. I vaguely
>remember (now that I'm away from the machine) something about 'run execute'. Is
>this the problem and does one of the newer versions of Csh address this?

It may be a problem under some circumstances, but in this case, it's not your
problem.  Your problem has been very recently addressed on the net as per
message ID: $89110303365772@masnet.uucp$ date: 2 Nov 89 14:36:00 GMT
from vic.rocha@canremote.uucp (VIC ROCHA) subject: re: Missing k directive

BH> From: farhi@athena.mit.edu (Bill Hoston)
BH> Orga: Massachusetts Institute of Technology
BH> thing I recall doing to the script was  modifying it to run dmouse 
BH> and adding ls3.1 to my list of resident commands.  I didn't test to
VR> Bill, check for an undefined default .bra and .ket pair such as a `run 
VR> <nil: >nil: df0:dmouse', could even be over two lines.  Another way to 
VR> avoid the problem is to define .bra as something, ie: `.bra {', that way
VR> it's unlikely to confuse `Execute's finding of any `<'s or `>'s!!

and as per message ID: $585@medusa.informatik.uni-erlangen.de$ date: 20 Nov 89
13:51:37 GMT from mlelstv@immd4.informatik.uni-erlangen.de (Michael van Elst )
subject: re: Missing k directive - claudio@forty2.UUCP (Claudio Nieder) writes:
CN> In article <1105@forty2.UUCP> I wrote:
CN> Thanks to everybody who sent me mail, telling me that I probably have
CN> a "<" somewherer in my Shell-Startup. After cleaning up my prompt
CN> which contained that character everything worked well again. 
MVE> If you use EXECUTE, then parameters are parsed by the command and
MVE> substituted in the script. Actually a second script is generated with
MVE> those substitutes.
MVE> If it is called from NEWSHELL or as a startup-sequence, you just feed
MVE> it into the CLIs standard input without ever looking at parameters or
MVE> meta-commands (.bra, .dot, .key, etc....)
MVE> I use in my startup-sequence:
MVE>    EXECUTE shell-execute
MVE> and my shell-execute file comes up with .BRA { since otherwise any
MVE> io-redirections would cause a 'missing K-directive' error.
MVE>				Michael van Elst

As pointed out by Claudio Nieder, the Dillon/Drew and Dillon/Drew/Borreo-Cesare
shells use ">" in the default prompt, so that's probably where your problem is
originating.

>What is the current version?

The current distributed version is 3.03A by Carlo Borreo & Cesare Dieni. They
may have another version well under way by now (or they may not).  The revs
may be interpreted as meaning 'any cshell of the Dillon/Drew extraction with a
version level of 2.xx is for AmigaDOS v1.2 and any with version level of 3.xx
is for AmigaDOS v1.3 with ARP library support.'  If you don't provide a home
for arp.library, then you won't be able to use the v1.3 lineage of cshells.

>A slightly related (maybe more than I realize) question. I also tried using the
>'protect' command to set the script bit, but it seemed like under Csh it also
>had no effect and the 's' didn't show up when running 'list' as I expected.  I
>didn't check the bit under WShell, but the script ran without using 'execute'.
The versions of list intended for use under v1.2 AmigaDOS only show the 'rwed'
protection bits.  What this means is that even if you are using the v1.3 Protect
command or the 'protect' command (lower case) from a shell that knows about the
'chsp' protection bits, you won't see the result when you invoke v1.2 list.

>
>Any enlightenment on this would be welcome. Thanks.
{
As cited by Dave Haynie (in DiskSalv v1.0 circa de 1985):

	"I gained nothing at all from Supreme Enlightenment, and
	 for that very reason it is called Supreme Enlightenment."
					-Gotama Buddha
}
>"Could we be the bellwether  | Michael Figg  DSAC-FSD
>of major societal shifts?"  | DLA Systems Automation Center - Columbus,Oh
>mfigg@dsacg2.dsac.dla.mil

Interpreting something related by James Burke in "The Day the Earth Changed":
Plate tektonics are nothing more than weather in what we thought was solid rock.
In this concept, a volcano is evidence for the development of an occluded front.

					Howard Hull
					hull@ncar.ucar.edu