Path: utzoo!attcan!uunet!munnari!munnari.oz!kre
From: kre@munnari.oz (Robert Elz)
Newsgroups: comp.unix.wizards
Subject: Re: Should ``csh'' be part of the System V distribution?
Keywords: csh==Berkeley shell, should it be in System V or not?
Message-ID: <2125@munnari.oz>
Date: 18 May 88 11:38:13 GMT
References: <2599@usceast.UUCP> <2601@usceast.UUCP> <4095@mtgzz.UUCP>
Sender: news@munnari.oz
Lines: 100

In article <4095@mtgzz.UUCP>, avr@mtgzz.UUCP (XMRP50000[jcm]-a.v.reed) writes:
> Why would any sane person wish to use csh when they can use ksh?

Because (apart from not necessarily being able to use ksh), ksh doesn't
do everything that csh does quite as well.  It certainly does a lot of
things better, but the few bits and pices lacking seem to be enough of
a drawback to people who have used csh for a long time that the other
advantages of ksh just don't overcome them.  If you've never really
used csh, that is, if you've never once done

	cmd !?ff?:% !?gg?:%

which I think isn't trivial in ksh, then you probably would find ksh
perfectly adequate.

In <1072@X.UUCP> john@frog.UUCP (John Woods) writes:
> Perhaps there are subtleties in the csh !$ construct that I am missing, but
> in ksh, $_ is the last word of the previous command line.

No, as Arthur Olson (ado@elsie.UUCP, aka ado@ncifcrf.gov) pointed out
in <8063@elsie.UUCP>, $_ in ksh is the last arg passed to the last
command that you executed (ie: argv[argc-1]), it has little to do
with the command line, which is what !$ references.  Ado's message
showed that if the last word on the command line used a shell magic
character, ksh's and csh's results are quite different.

A similar thing happens if the previous command line ended with
output (or input) redirection

	cat a b c > d
	vi !$

is quite different in effect (in csh) from

	cat a b c > d
	vi $_

in ksh.

Note, neither of these interpretations is better in all circumstances,
you'll find that

	cc foo.c &
	vi !$

is not particularly useful, whereas

	cc foo.c &
	vi $_

probably would be, if only it would set $_ at all, rather than just
leaving it unchanged.  However, csh users tend to be used to the csh !$
construct, and $_ just isn't what is wanted most of the time.

Like David Elliott (dce@mips.COM) in <2199@quacky.mips.COM>, I have
found personally (when I've used ksh on occasions) that csh's history
operators are much easier to use for quick substitutions, than ksh's
editing, I often use a sequence a bit like

	mv A B
	cp !$ !^

which is a lot harder to accomplish in ksh.

Aside: I know I could define a ksh (or SysV sh) function to do this, as I
  could define a csh alias, or for that matter, just write a sh script, but
  I don't want a new command, I don't do it often enough to bother remembering
  a new name, I really want to type two commands (which aren't always cp & mv),
  I just don't want to have to type the path names (A and B are often
  fairly lengthy).

I also use the { } csh operator a LOT, though I thought that it
had been added to some version of ksh?

I wish that someone (Korn, or almost anyone else) would add these few
remaining trivialities to ksh (I could actually do without the ^ and
!!:s/// stuff, just give access to the !{^,$,[0-9]*,!} operators,
probably as variables of some form, maybe 

	$^  for !^
	$=n for !n
	$=  for !!
	$%  for !$  (the real !$, rather than $_ which should remain)

and add {}, I could even accept $( and $), then I might be able to
justify spending the $US3000 that ksh costs, or did last time I checked
(which is a little amazing, considering that I can get the whole rest of
unix, including utilities for $US800, again, the last time I checked,
and under an academic licence of course).  Until then, ksh isn't an option
at all on most of our hosts, it exists only on a couple where the vendor
happens to supply it.

kre		kre@munnari.oz.au

ps: if ksh really does set the env variable '_' to be the full path of
the command executed, which I have no evidence to support, how would a
ksh script access this information, since $_ already has a defined
meaning?  Seems a little odd, even if putting this kind of thing in
the shell was the right place to put it, which it isn't (every program
is, or could be, a shell, so put it in the shell means put it everywhere).