Unix Technical Discussions V1 #4

[unix at cbosgd.UUCP]

From: Ron Heiby (The Moderator) <unix-request at cbosgd.UUCP>


Unix Technical Discussions     Sat, 09 Mar 1985    Volume 1 : Issue 4

Today's topics:
		Looking for good csh tutorial (2)
	    Shells: programming and background pids (4)
----------------------------------------------------------------------

Date: 2 Feb 85 23:15:18 GMT
From: wa371 at sdcc12.UUCP (wa371)
Subject: Where can I find tutorials on writing C-shell scripts?

There seem to be many books and tutorials on UNIX, but they deal
with the writing of shell scripts only in passing, if at all.
Are there any texts or tutorials that teach the writing of
scripts for the C-shell in some detail?

Bernd Riechelmann                   (Not affiliated with U.C. San Diego)
UUCP: ...!ucbvax!sdcsvax!sdcc12!wa371,   ARPA: sdcsvax!sdcc12!wa371 at nosc

------------------------------

Date: 6 Feb 85 00:00:28 GMT
From: Greg McGary <lcc.gm at UCLA-LOCUS.ARPA>
Subject: Re: Where can I find tutorials on writing C-shell scripts?

The only tutorial I know of is Bill Joy's `An Introduction to the C-shell'.
This article is included with the BSD documentation set in Volume 2 of
the programmer's manual.

I think you've already discovered that most tutorials are written for
the Bourne shell. (/bin/sh)   The general consensus is that Kernighan
and Pike's `Unix Programming Environment' gives the best available
treatment of the subject.  Please do not shy away from learning the
Bourne Shell because you feel you are most interested in the C-shell.
The techniques of shell programming apply to both shells.  Once you
what you want to do with a shell program and generally how you want to
do it, in most cases it is a simple matter of consulting the manual page
to select the correct syntax.

Also, you may discover (like many of us) that the Bourne Shell is
really the shell of choice for programming.  It is more capable and
less buggy.  Personally, I prefer the C-shell for interactive use
(until the Korn Shell becomes available...) because of history, job
control, and aliases.  But for shell programming, I always use
the Bourne Shell.
			Greg McGary
			Locus Computing Corp.
						lcc!gm at ucla-cs
	 {ihnpr,randvax,sdcrdcf,ucbvax}!ucla-cs!lcc!gm
		{trwspp,ucivax}!ucla-va!ucla-cs!lcc!gm
					   trwb!lcc!gm

------------------------------

Date: 12 Feb 85 21:24:00 GMT
From: ss at wanginst.UUCP (Sid Shapiro)
Subject: getting the pid from the csh

Hi there unix-folks.
In keeping with the discussions of a few weeks ago about how to
automatically kill backgrounded process from the csh upon logout, I
thought I'd ask the question another way.  Or at least I thought I'd
take another shot at it.  I thought, if I could simply record the pid
of the process in a file or variable, then, golly, killing it later
would be easy.

So I cheerfully set off to try and figure out how to capture the pid
that is returned when you type foo&

Well, after I exhausted all the variations I could think of, I went to
the csh sources.  It sure looked to me like the shell simply does a
printf of the pid.  But I'll be darned if I can redirect or backquote
or set something to get that number.

Can anyone offer words of wisdom?  Thanks,

Sid Shapiro -- Wang Institute of Graduate Studies
    [apollo, bbncca, ucadmus, decvax, linus, masscomp]!wanginst!ss
    ss%wang-inst at Csnet-Relay.ARPA
	  (617)649-9731

------------------------------

Date: 14 Feb 85 02:18:44 GMT
From: msb at lsuc.UUCP (Mark Brader)
Subject: Re: getting the pid from the csh

In sh, on the other hand, you need only type:	(foo&) 2>foo.pid

Mark Brader

------------------------------

Date: 14 Feb 85 10:53:40 GMT
From: rpw3 at redwood.UUCP (Rob Warnock)
Subject: Re: getting the pid from the csh

In the Bourne Shell (either Edition 7 or 4.1bsd) the (parent) shell
variable "$!" contains the process number of the last background
process evoked. You don't need to write it into a file. Try:

	$ foo &
	$ ...		# anything but another background invocation
	$ echo $!

It works as documented. See "sh(1)".

Rob Warnock
Systems Architecture Consultant

UUCP:	{ihnp4,ucbvax!dual}!fortune!redwood!rpw3
DDD:	(415)572-2607
USPS:	510 Trinidad Lane, Foster City, CA  94404

------------------------------

Date: 14 Feb 85 14:24:45 GMT
From: ss at wanginst.UUCP (Sid Shapiro)
Subject: Re: getting the pid from the csh - answers

I have had three replies.  One that I had a little trouble relating to
my question, so I won't bother repeating it.  The second was from an
unnamed person (I don't want to embarrass him) who cheerfully told me
about a shell variable that got set in his shell, but not mine - (he
didn't realize that his shell had been hacked in that way).  And the
third from wizard Spencer Thomas (thomas at utah-cs.ARPA).  Spencer's was
the most useful (no surprise there):

>> Here is an alias we use to kill off selected or all jobs.  Works sort
>> of, most of the time.  But, it does show how to get the (in this case)
>> job id's of all your background or stopped tasks (the hard part is in
>> /usr/local/killall, included below).  The '%!$' at the end is to
>> continue processes (such as Gosling emacs) that want to print something
>> before they die.  If a subprocess doesn't die on SIGTERM (e.g., a
>> shell), this won't work correctly.
>> 
>> alias res 'if ("\!$" == "*") source /usr/local/killall;'\
>> 	'if ("\!$" != "*") kill %\!$; if ("\!$" != "*") %\!$'
>> 
>> # kill all subprocesses of this shell.
>> # 
>> jobs >~/.pcs
>> foreach i (`sed 's/.*\[\(.*\)\].*/\1/' ~/.pcs`)
>> 	res $i
>> end

With one mimor mod for me to pick up just the job I want killed, this
worked like gangbusters.  The only thing that puzzles me is that I
tried some combinations of sed scripts originally a few months ago
when I started this business and I had trouble - of course I don't
remember what the trouble was... Oh well.
Thanks for all your help, folks.
/ Sid /

------------------------------

End of Unix Technical Discussions
*****************************
-- 
Ronald W. Heiby / ihnp4!{wnuxa!heiby|wnuxb!netnews}
AT&T Information Systems, Inc.
Lisle, IL  (CU-D21)