csh echo to stderr

[Robert R. Bruner]

I have a cshell program which attempts to avoid overwriting a file
by using
echo -n The file already exists. Overwrite (y/n)?
The problem is that if I redirect output of the shell program to
a file, I never see the error message, and end up wondering what
enormous program is slowing the machine down so much. Eventually,
I realize what is going on, but I can't expect others to do so.
Is there a way I can make the echo command send its output to stderr
so that redirection of stdout will not hide the message? Obviously
I can write a little C program to print the message on stderr, but
I prefer to do it all within the script if at all possible.

Thanks in advance for any answers to what must be an incredibly
elementary question. I don't write that many scripts, and this is
my first attempt to use news.

Robert Bruner r...@math.wayne.edu

[Jonathan I. Kamens]

Unless either your /bin/echo has funky options to let you write to stderr, or
the built-in echo on your csh has such funky options, you have to resort to
something like this to echo to stderr from csh:

/bin/sh -c 'echo -n "The file already exists. Overwrite (y/n)? " 1>&2'

I'll preempt everyone else who's going to point this out by pointing out that
the C-shell isn't exactly a great language for doing shell programming, and
you'd probably be better off switching to sh or one of its variants such as
ksh.

--
Jonathan Kamens j...@CATS.UCSC.EDU

[Anthony P Lawrence]

In article <19...@darkstar.ucsc.edu> j...@cats.ucsc.edu (Jonathan I. Kamens) writes:

> the C-shell isn't exactly a great language for doing shell programming, and
> you'd probably be better off switching to sh or one of its variants such as
> ksh.

It is pretty obvious to anyone who reads this and other groups that
Jonathan Kamens knows what he is talking about.

It is interesting (to me) that I am constantly running into people who
insist on using csh (one even changed a client's root login to use csh;
this caused no end of problems and confusion until I realized what he
had done).

I never "got into" csh because way back when, the systems I worked on
only had sh. By the time csh was available, I was too sh oriented to
switch. (I now use ksh)

So, the question is: why is the csh so inappropriate for shell
programming and why don't those using it realize this?

Perhaps Jonathan or someone with an equal breadth of knowledge could
comment?

Tony

Lawrence & Clark, Inc (617) 762-0707

[Tom Christiansen]

From the keyboard of a...@world.std.com (Anthony P Lawrence):
:So, the question is: why is the csh so inappropriate for shell

:programming and why don't those using it realize this?

I've been trying to hold back my "don't do programming in csh"
warnings to one a day, but since you asked, let me attempt to
spell out some good reasons. I preface this from the tail of the
csh man page on Suns.

Although robust enough for general use, adventures
into the esoteric periphery of the C shell may reveal
unexpected quirks.

So here's a bunch of reasons why not to use the csh for programming.
I suspect that after reading them you'll agree.

--tom

1. FILE DESCRIPTORS

The most common problem encountered in csh programming is that
you can't do file-descriptor manipulation. All you are able to
do is redirect stdin, or stdout, or dup stderr into stdout.
Bourne-compatible shells offer you an abundance of more exotic
possibilies.

1a. Writing Files

In the Bourne shell, you can open or dup random file descriptors.
For example,

exec 2>errs.out

means that from then on, all of stderr goes into errs file.

Or what if you just want to throw away stderr and leave stdout
alone?

cmd 2>/dev/null

Works in the Bourne shell. In the csh, you can only make a pitiful
attempt like this:

(cmd > /dev/tty) >& /dev/null

But who said that stdout was my tty? So it's wrong.

1b. Reading Files

In the csh, all you've got is $<, which reads a line from your tty.
Read in the Bourne shell allows you to read from stdin. This allows
you do do things like this:

exec 3<file1
exec 4<file2

Now you can read from fd 3 and get lines from file1, or from file2 through
fd 4. In modern bournelike shells, this suffices:

read some_var 0<&3
read another_var 0<&4

Although in older ones where read only goes from 0, you trick it:

exec 5<&0 # save old stdin
exec 0<&3; read some_var
exec 0<&4; read another_var
exec 0<&5 # restore it

1c. Closing FDs

In the Bourne shell, you can close file descriptors you don't
want open, like 2>&-, which isn't the same as redirecting it
to /dev/null

1d. More Elaborate Combinations

Maybe you want to pipe stderr to a command and leave stdout alone.
You can't do this in as I mentioned in 1a. In a Bourne shell, you
can do things like this:

exec 3>&1; grep yyy xxx 2>&1 1>&3 3>&- | sed s/file/foobar/ 1>&2 3>&-
grep: xxx: No such foobar or directory

Normal output would be unaffected. The closes there were in case
something really cared about all it's FDs. We send stderr to the sed,
and then put it back out 2.

Consider the pipeline:

A | B | C

You want to know the status of C, well, that's easy: it's in $?,
or $status in csh. But if you want it from A, you're out of luck.
If you're in the csh. In the Bourne shell, you can get it. Here's
something I had to do where I ran dd's stderr into a grep -v pipe to
get rid of the records in/out noise, but had to return the dd's exit
status, not the grep's:

device=/dev/rmt8
dd_noise='^[0-9]+\+[0-9]+ records (in|out)$'
exec 3>&1
status=`((dd if=$device ibs=64k 2>&1 1>&3 3>&- 4>&-; echo $? >&4) |
egrep -v "$dd_noise" 1>&2 3>&- 4>&-) 4>&1`
exit $status;

2. COMMAND ORTHOGONALITY

2a. Built-ins

The csh is a horrid botch with its built-ins. You can't put them
together in many reasonable way. Even simple little things like this:

% time | echo

which while nonsensical, shouldn't give me this message:

Reset tty pgrp from 9341 to 26678

Others are more fun:

% sleep 1 | while
while: Too few arguments.
[5] 9402
% jobs
[5] 9402 Done sleep |

Some can even hang your shell. Try typing ^Z while you're sourcing
something. Or redirecting a source command.

2b. Flow control

You can't mix flow-control and commands, like this:

who | while read line; do
echo "gotta $line"
done

You can't combine multiline things in a csh using semicolons.
There's no easy way to do this

alias cmd 'if (foo) then bar; else snark; endif'

2c. Stupid non-orthogonal parsing bugs

Certain reasonable things just don't work, like this:

kill -1 `cat foo`
`cat foo`: Ambiguous.

But this is ok:

/bin/kill -1 `cat foo`

3. SIGNALS

In the csh, all you can do with signals is trap SIGINT. In the Bourne
shell, you can trap any signal, or the end-of-program exit. For example,
to blow away a tempfile on any of a variety of signals:

trap 'rm -f /usr/adm/tmp/i$$ ;
echo "ERROR: abnormal exit";
exit' 1 2 3 15

trap 'rm tmp.$$' 0 # on program exit

4. QUOTING

You can't quote things reasonably in the csh:

set foo = 'isn\'t this so?'

doesn't work. This makes it really hard to construct strings with
mixed quotes in them.

Dollar signs cannot be escaped in doublequotes in the csh. Ug.

set foo = "this is a \$dollar quoted and this is $HOME not quoted"
dollar: Undefined variable.

You have to use backslashes for newlines, and it's just darn hard to
get them into strings sometimes.

set foo = "this \
and that";
echo $foo
this and that
echo "$foo"
Unmatched ". # say what???
echo $foo:q

You don't have these problems in the Bourne shell.

5. VARIABLES

There's this big difference between global (environment) and local
(shell) variables. In csh, you use a totally different syntax
to set one from the other.

In Bourne shell, this
VAR=foo cmds args
is the same as
(export VAR; VAR=foo; cmd args)
or csh's
(setenv VAR; cmd args)

You can't use :t, :h, etc on envariables. Watch:
echo Try testing with $SHELL:t

It's really nice to be able to say

${PAGER-more}

to be able to run the user's PAGER if set, and more otherwise.
You can't do this in the csh. It takes more verbage.

You can't get the process number of the last background
command from the csh. In the Bourne shell, it's $!.

6. RANDOM BUGS

Here's one:

fg %?string
^Z
kill %?string
No match.

Huh? Here's another

!%s%x%s

Coredump, or garbage.

If you have an alias with backquotes, and use that in backquotes in
another one, you get a coredump.

Try this:
% repeat 3 echo "/vmu*"
/vmu*
/vmunix
/vmunix
What???

There are a lot, probably over 100, of these.

[Anthony P Lawrence]

In article <19...@darkstar.ucsc.edu> j...@cats.ucsc.edu (Jonathan I. Kamens) writes:

> We want our system to be accessible to people who aren't Unix junkies, and
> that means making it as user-friendly as possible. Having a shell with
> line editing, history recall, etc. is what that's all about,

Yes, I understand that. It's the people who ARE Unix junkies , who are
writing scripts to do medium complex things-not users, but consultants,
programmers, support people- it's THOSE people that I have never understood.

(Having never used csh, I didn't realize how much it was missing-

wow.)

Tony

[Jan B. Andersen]

a...@world.std.com (Anthony P Lawrence) writes:

>So, the question is: ... why don't those using it realize this?

I think that the slim User's Guides for SUN workstations uses Csh for
the examples (I think I saw this for the Sun-386i). If that's true,
I can understand why a lot of newcomers are tricked into using Csh
for all their work.

[Tom Christiansen]

From the keyboard of a...@world.std.com (Anthony P Lawrence):

Like Jonathan, I also use tcsh as my login shell. It offers me things
that ksh will not, and I'm not yet trusting of bash.

Annoying things about ksh:

1) No algebraic history, like !?bar:*
2) Can't "set notify"
3) No spelling correction (I bind spell-word to ^G in tcsh)
4) M-k puts me at the front of the line, not the end like ^P
5) No foo{this,that,something_else} notation
6) Completion is painful: give me <TAB> like tcsh
7) Can't rebind functions

Annoying things about tcsh:

1) It *IS* the csh after all, so there's all that... :-(
2) A truly bogus vi mode
3) History editing can't handle multiline commands (loops, etc)
4) Can't do $(cmd1 $(cmd2 args) more args) nested evals

For 1, there is no cure. For 2, I've a tolerable makeshift solution via
the redo alias. For 3 and 4, well, I just have to pop into ksh now and
then for them.

Notice none of the annoyances on ksh, modulo 5, interfere with my shell
programming, but they do with interactive work. On the other hand, both 1
and 3 of the tcsh annoyances do interfere with programming, with number 1
rendering it utterly useless for that purpose, so I don't touch it for
programming, but do keep it for interactive work. The other whistles and
bells from tcsh (sched, watch, ...) I don't use much.

If bash were to address all the ksh grievances PLUS stops dumping core,
I'd use it with passion and with joy. Another thing is that more systems
have csh than ksh. *SIGH*. Being stuck with sh for interactive work would
be unpleasant in the extreme, about like being stuck with csh for programming.

Of course, I only use sh for very simple programs (not usually more than a
dozen lines or so). For larger programs (say ten to ten thousand lines),
I use perl, but I bet all of you knew that already. :-)

--tom

[Jonathan I. Kamens]

In article <APL.91Au...@world.std.com>, a...@world.std.com (Anthony P Lawrence) writes:
|> It is interesting (to me) that I am constantly running into people who
|> insist on using csh (one even changed a client's root login to use csh;
|> this caused no end of problems and confusion until I realized what he
|> had done).

Now, now, let's not be so harsh here. We've used csh (or actually, tcsh) as
our default shell at MIT Project Athena for as long as I've been here, as well
as making it the defualt shell for root logins.

We want our system to be accessible to people who aren't Unix junkies, and
that means making it as user-friendly as possible. Having a shell with line

editing, history recall, etc. is what that's all about, and the advent of
bourne-compatible shells with such features has only happened in the last few
years. Before that, tcsh (which, I've been told, was created at MIT for this
very reason and later migrated to Ohio State, although I don't know how
accurate that is) was the only way to go, and that's one reason to go with a
tcsh or csh shell as the default shell.

Tcsh isn't all that bad as an interactive shell. And it is in many respects
friendlier than stock bourne shells. So it is understandable for people to
use csh as an interactive shell and sh as a programming shell.

Tom has done an excellent job in another message of explaining why not to use
csh for programming, much better than I would have done, probably because it's
one of his crusades :-), so I won't try to go into any detail about that.

--
Jonathan Kamens j...@CATS.UCSC.EDU

[Boyd Roberts]

Well, seeing we're on the `one true shell' crusade I'll add my N bytes.

When I moved here to PRL I was faced with the hideous problem of:

1. Getting the Sys V shell source and putting V8 hacks into it (again),
but this time on a system with job control!

2. Using csh. No, never again. I only want it for history.

3. Using tcsh. No way, _ever_! That thing is an abortion.

4. Using ksh. Been there, done that. After reading the manual
entry and installing it (some years ago) I laughed too much and
wondered what Steve Bourne had done to deserve this done to
his original creation. What a joke.

So, it was looking like choice 2. But, Byron Rakitzis put me out of my misery.

I use `rc', the Plan 9 shell. It's Tom Duff's excellent design and Byron's
code. What a lifesaver.

It's small, and does everything I want. But, there's no way it'll appeal
to the meta-editor-history-keyboard-accelerator-junky.

It writes its input to a a file set by $history. I have a tail -f $history, in
a window. But, if I need to edit a previous command I'll use `:', the Plan 9
name for the V8 `='. Or I can edit $history with a real editor.

No more quoting woes. Clean syntax. No gratuitous bloat. Small amount of source code. Free. Portable. Maintainable. Understandable.

Boyd Roberts bo...@prl.dec.com

``When the going gets wierd, the weird turn pro...''

[Michael Schroeder]

tch...@convex.COM (Tom Christiansen) writes:

>

[ good points against csh deleted ]

>2c. Stupid non-orthogonal parsing bugs

> Certain reasonable things just don't work, like this:

> kill -1 `cat foo`
> `cat foo`: Ambiguous.

> But this is ok:

> /bin/kill -1 `cat foo`

This is not a bug, but a feature! Try:

set list="`ls -l`"
echo $list[2]

Every line of the output of ls will become an element in the array.
If you really want to do something like 'kill -1 `cat foo` you
can write something like:

set list="`cat foo`"
kill -1 $list

>

[ more good points deleted ]

>

Michael

----------
mlsc...@immd4.informatik.uni-erlangen.de

[Chet Ramey]

In article <1991Aug8.1...@prl.dec.com> bo...@prl.dec.com (Boyd Roberts) writes:

>No more quoting woes. Clean syntax. No gratuitous bloat. Small amount
>of source code. Free. Portable. Maintainable. Understandable.

Ahh...

Always nice to get my MDR of religion with my coffee ;-).

(You know, of course, that you're completely wrong. ;-)

Chet
--
``Someday soon, I'm gonna tell the world about the crying game...''

Chet Ramey Internet: ch...@po.CWRU.Edu
Case Western Reserve University NeXT Mail: ch...@macbeth.INS.CWRU.Edu

[Mark Lanzo]

In a prior article a...@world.std.com (Anthony P Lawrence) wrote:
>In article <19...@darkstar.ucsc.edu> j...@cats.ucsc.edu (Jonathan I. Kamens) writes:

>> the C-shell isn't exactly a great language for doing shell programming,
>> and you'd probably be better off switching to sh or one of its variants
>> such as ksh.

...

>So, the question is: why is the csh so inappropriate for shell
>programming and why don't those using it realize this?

I used to be a csh chauvinist, but eventually "saw the light". :-)
It's been a while since I used csh for anything, but from my rusty memory,
here's a couple of reasons I found for giving up on Csh for scripts (and use
ksh instead):

1) Csh has very limited redirection abilities. About all you
can do is redirect 'stdout', or 'stderr' and 'stdout' as a
group.

Sh & ksh have much more flexibility here. You can redirect
any arbitrary file descriptor independently, close or open
file descriptors, duplicate file descriptors, etc.

2) Csh'es quoting mechanisms are totally braindead.
Try putting together a command-line which includes
single-quotes, double-quotes, back-quotes, dollar-signs,
backslashes, exclamation points, embedded newlines, etc. ...
especially where these things are nested inside each other.
Semicolons don't always equate to embedded newlines either.

Csh'es quoting mechanisms are also not wholly consistent.
Apparently code to handle quoting/metacharacters occurs
in several different places in csh, and the exact behavior
is different in each place.

3) Csh has no real equivalent to {k}sh "functions".
Csh'es "alias" facility in combination with its history
mechanisms provide a crude substitute, only adequate for
simple things.

4) Csh doesn't have ability to install signal handlers
(the "trap" mechanism of {k}sh).

5) {K}sh has lots of useful modes for expanding variables.
Constructs like `${foo:="default value"}' are quite handy.

6) Ksh (but not sh) has convenient facilities for *interactive*
editing of command lines.

Csh only has "history" mechanism. This is better for non-
interactive definitions (such as aliases), but pretty
obnoxious for interactive use. Occasionally I wish I had
history mechanism, but this is pretty rare.

7) Ksh (maybe some sh'es too) have more built in operators
and arithmetic ability (the "[ ... ]", "test", "(( ... ))"
stuff). A big win speed-wise if nothing else.

8) {K}sh scripts seem to run faster. I don't know why this
should be so. [No, it's not simply because csh always
reads ".cshrc" either, as some people would suggest.]

9) Several outright bugs in csh, although I no longer remember
what they were. In fairness, I've had even more problems
with some very blatant bugs in "sh", which is one reason
I write scripts using ksh rather than sh, despite the
fact that sh is more widespread than ksh.

Csh isn't all bad though. Some points against sh or ksh:

1) Csh syntax is nicer (when it works). Constructs like:

if (expr) then
...
endif

I prefer to {k}sh'es

if [ expr ] ; then
...
fi

I hate {k}sh'es use of reversed keywords like "fi", "esac", etc.
This is a nitpick though -- {k}sh syntax works and perhaps is
more powerful overall.

Also, the fact that characters like "[]" and "{}" and ":" aren't
metacharacters in {k}sh means you have to be extra careful with
spacing around these symbols. And why does ksh use "." as a
command name? (equivalent to csh'es "source" command).

2) Setting variable values in csh is nicer than {k}sh:

set foo = "bar"

as opposed to:

foo="bar"

It bothers me that {k}sh considers the space around the '=' sign
significant. This I mostly notice when writing scripts where I
want to "beautify" the scripts, e.g:

MAIN_DIR = "some_pathname"
CMD_DIR = ${MAIN_DIR}/bin
SRC_DIR = ${MAIN_DIR}/src ...

which of course isn't valid in sh or ksh.

Also, to my mind:

foo=bar

should just mean to run a command named "foo=bar".

3) Csh has multi-word variables (and ability to use them effectively):

set foo = (alpha beta gamma)

4) Sh (not ksh) has some pretty blatant gaffes.

A common example which pops up in this group all the time:

beep() { echo "$*" ; }

echo "$*"
beep hello world
echo "$*"

The 'echo "$*"' appearing after "beep hello world" will print
"hello world" with many versions of sh! The parameter list
"$*" is a global thing and gets reset upon any call to a function.
Note: Ksh fixes this.

Another common problem with sh is that it is not always obvious
when some command you run is actually running in a subprocess.
E.g., what happens when you do:

foo=xxx
if true ; then
foo=yyy
fi
echo $foo

Is $foo now equal to "xxx" or "yyy" ?

This is actually a bogus example; I think that in this case it's safe
to say that "$foo" will correctly be "yyy" ... but I ran into a
very similar case where I could not alter a variable's value from
inside a block (effective outside of the block) simply because "sh"
ran the block in a subprocess (unbeknownst to me of course).
Simply changing "#!/bin/sh" to "#!/bin/ksh" at the top of the
script cured that problem. I regret that I cannot remember the
real example to include here.

5) I like Csh'es "pushd" and "popd" commands.

6) {K}sh lacks the "{a,b,c}" expansion.

7) Ksh doesn't allow me to use arbitrary strings for identifiers
for aliases. For example, in csh I routinely had aliases to
the effect of:

alias ^H stty erase '^H'
alias ^? stty erase '^?'

where the first '^H' and '^?' in each line are the actual
"backspace" and "delete" characters. Also useful for things
like function keys.

Overall though, my arguments against ksh are nitpicks, whereas the
csh problems are often bad enough to stop me in my tracks, so in the
end I definitely go with ksh.

--Mark--

===============================================================================
= Mark Lanzo = Wandel & Goltermann Technologies, Inc. = // =
= uunet!wgate!lanzo = 1030 Swabia Court, Research Triangle Park = // =
= = North Carolina 27709-3585 = \\ // =
= = Phone: (919) 941-5730 FAX: (919) 941-5751 = \X/ =
===============================================================================
>>> Warning: return address in header is probably incorrect, use the above <<<

[Scott Schwartz]

bo...@prl.dec.com (Boyd Roberts) writes:
| I use `rc', ...

No job control. A mixed blessing, to be sure, but still...

[Boyd Roberts]

In article <l!8H!u4...@cs.psu.edu>, schw...@roke.cs.psu.edu (Scott Schwartz) writes:
>
> No job control. A mixed blessing, to be sure, but still...

I just don't understand this pre-occupation with job control. I don't
need it because I have windows, but even so I'd _never_ use it.

The semantics are just a nightmare and the implementation of user mode
stuff is just hideous. You have this neat system call interface, but it
gets totally broken when you add job control. Not to mention the tty
driver, issig(), psig() and whatever else.

What I would support is SIGSTOP & SIGCONT, sent by kill(2):

SIGSTOP - the process stops
SIGCONT - the process runs

No more, no less. Seamless. Invisible. Useful.

[Rich Stevens]

>I just don't understand this pre-occupation with job control. I don't
>need it because I have windows, but even so I'd _never_ use it.

I don't understand this pre-occupation with windows. I've worked with
a windowing terminal on a job-control system for the past 3 years
(AT&T 630 on 4.3BSD, then SunOS) and find it *much* more productive
to use job control for most things. Taking my hands off the keyboard,
moving the mouse, clicking the mouse, takes me longer than hitting
Control-Z, then whatever. I do run multiple windows, and switch
windows for some tasks, but in my normal mode use job control for
most switching.

Job control may not be perfect but it is useful. I, personally,
their is a place for both job control and windows.

Rich Stevens (rste...@noao.edu)

[Tom Christiansen]

From the keyboard of bo...@prl.dec.com (Boyd Roberts):

:In article <l!8H!u4...@cs.psu.edu>, schw...@roke.cs.psu.edu (Scott Schwartz) writes:
:>
:> No job control. A mixed blessing, to be sure, but still...
:
:I just don't understand this pre-occupation with job control. I don't
:need it because I have windows, but even so I'd _never_ use it.

I can see we're dealing with a man of the cloth here, but perhaps one
whose church meets on a peculiar day, like the second Tuesday of each
week. In short, it's religion that's blinded your eyes. They say there's
no use arguing with the truly Faithful, but this has never stopped me.

First, not everyone has a window system. Certainly at work I do, but not
at home. I would be utterly crippled at home without job control.

Secondly, just because you have a window system, DOES NOT mean that all
job control functions are subsumed by this system. In fact, quite a few
are not. How many of you with windows out there have more than one job in
the same window, some stopped?

The answer, you'll find, is most of them. I know this from some resource
management analysis I did on 100+ programmers. Why is this? It can be
argued that starting windows is expensive, but if I do that then Rob Pike
will get on my case, so I won't do that. :-)

The real reason is controlling output. I often stop and suspend jobs
willy-nilly. Sometimes it's to freeze it so I can check on what it's
doing the the filesystem or processes or whatever. It's crazy to
have to start a window just to stop it, or to require windows to do so.
I don't want to kill it, merely suspend it in its tracks.

Another thing is that I sometimes want a job to run until it blocks
for tty input (or occasionally output). I want to be asynchronously
notified when the job's status changes so that I might attend to its
urgent demands.

Finally, being able to send these signals to the whole darn process
group is quite convenient when you don't know what your job has spawned.
It's a real pain having to muck with ps output to figure it out. Sometimes
programs ignore interrupts, but ^Z followed by kill %, or kill -9 % in
a pinch, gets them all, unto the Nth generation.

You don't get these things out of windowing systems. It's called job
control, and it has its uses. Do not disdain what you do not have merely
for that reason. We call that the fox-and-the-grapes syndrome.

--tom

[Boyd Roberts]

In article <1991Aug09.1...@convex.com>, tch...@convex.COM (Tom Christiansen) writes:
> Secondly, just because you have a window system, DOES NOT mean that all
> job control functions are subsumed by this system. In fact, quite a few
> are not. How many of you with windows out there have more than one job in
> the same window, some stopped?

When I type a command I want it to complete.

> The answer, you'll find, is most of them. I know this from some resource
> management analysis I did on 100+ programmers. Why is this? It can be
> argued that starting windows is expensive, but if I do that then Rob Pike
> will get on my case, so I won't do that. :-)

Sure, X windows are expensive, but fortunately I have enough CPU to get
me a window in a reasonable time (~1s). So if I want to do something
else I get a new window, even just for one command, because I can get
to the window quickly. Admittedly my 3max is a bit overpowered for,
basically, an X terminal, but with X I need that CPU.

> Another thing is that I sometimes want a job to run until it blocks
> for tty input (or occasionally output). I want to be asynchronously
> notified when the job's status changes so that I might attend to its
> urgent demands.

You want to stop it when it `blocks for tty input'? Isn't it, err, stopped?

> Finally, being able to send these signals to the whole darn process
> group is quite convenient when you don't know what your job has spawned.
> It's a real pain having to muck with ps output to figure it out. Sometimes
> programs ignore interrupts, but ^Z followed by kill %, or kill -9 % in
> a pinch, gets them all, unto the Nth generation.

ps output? kill -STOP 0. That's what those process groups are there for.

> Do not disdain what you do not have merely
> for that reason. We call that the fox-and-the-grapes syndrome.

I have job control. I don't use it. It's just more misguided bloat.

This could be `Job Control is not necessary', so I'd better get in with the
first `douzo yoroshiku'...

[Rich Thomson]

In article <1991Aug8.1...@informatik.uni-erlangen.de>

mlsc...@immd4.informatik.uni-erlangen.de (Michael Schroeder) writes:
>
>If you really want to do something like 'kill -1 `cat foo` you
>can write something like:
>
>set list="`cat foo`"
>kill -1 $list

Ugh. How about:

xargs kill -1 < foo
--
``Read my MIPS -- no new VAXes!!'' -- George Bush after sniffing freon
Disclaimer: I speak for myself, except as noted.
UUCP: ...!uunet!dsd.es.com!rthomson Rich Thomson
Internet: rtho...@dsd.es.com IRC: _Rich_ PEXt Programmer

[Sean Eric Fagan]

In article <1991Aug9.1...@prl.dec.com> bo...@prl.dec.com (Boyd Roberts) writes:
>You want to stop it when it `blocks for tty input'? Isn't it, err, stopped?

On a non job-control (or sxt'd) system, do:

cat &

at your prompt. Enjoy.

--
Sean Eric Fagan | "What *does* that 33 do? I have no idea."
s...@kithrup.COM | -- Chris Torek
-----------------+ (to...@ee.lbl.gov)
Any opinions expressed are my own, and generally unpopular with others.

[Robert R. Bruner]

Ok Tom, I cry uncle! I'll start learning sh tomorrow. In self defense,
since my shell scripts are almost always doing simple minded things, when
I started writing them I found csh syntax much more natural than sh syntax.
Of course, my first reaction to C code was "That's the most godawful ugly
stuff I ever saw" and one day later I had learned to love it, so I'm sure
I'll soon feel the same about sh.

Bob Bruner r...@math.wayne.edu

PS: Thanks for the long list of examples/bugs/malfeatures.

[Martin Foord]

In article <1991Aug8.1...@prl.dec.com> bo...@prl.dec.com (Boyd Roberts) writes:

>I use `rc', the Plan 9 shell. It's Tom Duff's excellent design and Byron's
>code. What a lifesaver.

>No more quoting woes. Clean syntax. No gratuitous bloat. Small amount of source code. Free. Portable. Maintainable. Understandable.

But unfortuantely not very portable ...

Martin.
--
Martin Foord. MHSnet/ACSnet: m...@dbsm.oz.au
SBC Dominguez Barry. Internet Gateway:
Phone: +61-2-258-2724 maf%dbsm....@munnari.oz.au

[John R. MacMillan]

|>You want to stop it when it `blocks for tty input'? Isn't it, err, stopped?
|
|On a non job-control (or sxt'd) system, do:
|
| cat &
|
|at your prompt. Enjoy.

I could have misinterpreted, but I understood the point as being that
you wouldn't _do_ that. You'd create a new window, run cat in the
foreground, and it would stop, blocked for tty input.

The example of blocking for tty input is not really trying to do ``job
control'', it is trying to use job control to multiplex several jobs
to a single tty. This is one area where windows are probably more
natural; that's what their purpose is.

[John R. MacMillan]

|>I just don't understand this pre-occupation with job control. I don't
|>need it because I have windows, but even so I'd _never_ use it.
|
|I don't understand this pre-occupation with windows. I've worked with
|a windowing terminal on a job-control system for the past 3 years
|(AT&T 630 on 4.3BSD, then SunOS) and find it *much* more productive
|to use job control for most things. Taking my hands off the keyboard,
|moving the mouse, clicking the mouse, takes me longer than hitting
|Control-Z, then whatever.

So use a window system (or manager) that's less mouse-dependant. I
only use the mouse for cut and paste, and the rare times I resize
things.

The whole windows/job control thing is primarily religious. I'm in
the sect that says while they are different and both have their uses,
our current job control model is pretty ugly.

[Chris Torek]

In article <1991Aug09....@kithrup.COM> Sean Fagan suggests:

>>On a non job-control (or sxt'd) system, do:
>>
>> cat &
>>
>>at your prompt. Enjoy.

In article <1991Aug12....@sco.COM>

jo...@sco.COM (John R. MacMillan) writes:
>I could have misinterpreted, but I understood the point as being that
>you wouldn't _do_ that. You'd create a new window, run cat in the

>foreground, and it would stop, blocked for tty input. ...

If you are going to do this, you might as well drop the entire notion
of `background'. Everything always has a perfect input all to itself
(but which might be /dev/null or its moral equivalent; if you want `&'
to continue to work, do it as the Bourne shell did).

(Note that I am neither advocating nor disparaging this approach, merely
pointing out the logical conclusion [I hope!] for it. That is, if you
are going to enshrine a concept, do not just do this half-way.)
--
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA Domain: to...@ee.lbl.gov
new area code as of September 2, 1991: +1 510 486 5427

[Chet Ramey]

In article <3...@wgate02.UUCP> la...@wgate02.UUCP (Mark Lanzo) writes:
4) Sh (not ksh) has some pretty blatant gaffes.

A common example which pops up in this group all the time:

beep() { echo "$*" ; }

echo "$*"
beep hello world
echo "$*"

The 'echo "$*"' appearing after "beep hello world" will print
"hello world" with many versions of sh! The parameter list
"$*" is a global thing and gets reset upon any call to a function.
Note: Ksh fixes this.

This has been fixed in the System V.3 sh, as well as ksh and bash.

5) I like Csh'es "pushd" and "popd" commands.

These are easily emulated using arrays in ksh. The code to do so has
been posted many times; it might even be in the ksh book. They are
builtins in bash.

6) {K}sh lacks the "{a,b,c}" expansion.

ksh-88 can be compiled with brace expansion. Bash has it by default.

7) Ksh doesn't allow me to use arbitrary strings for identifiers
for aliases.

Korn put this into ksh in one of the minor releases of ksh-88, probably
ksh-88a.

With bash you could use readline macros to do the same thing, but bash does
allow arbitrary characters in aliases.

[Operator]

In article <1991Aug07....@convex.com>, tch...@convex.COM (Tom Christiansen) writes:
|> From the keyboard of a...@world.std.com (Anthony P Lawrence):
|> :So, the question is: why is the csh so inappropriate for shell
|> :programming and why don't those using it realize this?
|>

The diatribe against csh was eye-opening... like wow! Bugsville!

Now for the answer to the second part: Why are we using csh?

Because when we got UNIX bsd3.2, csh was sex and sh was syphilis.
ksh, tcsh, bash, &c were pipe dreams, and the pipe wasn't lit yet.
sh had limited documentation... Your best bet was to read /etc/rc*
csh had a history mechanism that worked well enough.
And, I (blushblush) still havn't got the hang of sh's version of 'foreach'
which I use frequently...
And I haven't the time to learn a whole new shell. I have to get work done here.

Happy bitsmashing

bru...@kazoo.ssd.loral.com

[Peter da Silva]

In article <1991Aug09.1...@convex.com> tch...@convex.COM (Tom Christiansen) writes:
> First, not everyone has a window system. Certainly at work I do, but not
> at home. I would be utterly crippled at home without job control.

Shell layers. Which are basically the core of one of AT&T's old window
systems run over a single stream.

> You don't get these things out of windowing systems. It's called job
> control, and it has its uses.

Yes, but most people use it as a cheap window system. The "job control"
part could be added to something like shell layers without creating the
excessive complexity of doing both things at once.
--
Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180;
Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"

[Mark Lanzo]

In a prior article ch...@po.CWRU.Edu wrote:
In article <3...@wgate02.UUCP> la...@wgate02.UUCP (Mark Lanzo) writes:
4) Sh (not ksh) has some pretty blatant gaffes.

A common example which pops up in this group all the time:

beep() { echo "$*" ; }

echo "$*"
beep hello world
echo "$*"

The 'echo "$*"' appearing after "beep hello world" will print
"hello world" with many versions of sh! The parameter list
"$*" is a global thing and gets reset upon any call to a function.
Note: Ksh fixes this.

This has been fixed in the System V.3 sh, as well as ksh and bash.

This may be true, but isn't really relevant. Note that I said that it was
a problem with "many versions of sh". I know that not all version have this
problem. I just don't trust to write 'sh' scripts at all since it is never
obvious which bugs I'm going to have to deal with. You can even make a good
argument that this is not an actual bug in sh, since it was never documented
otherwise. Ksh at least specifies these things.

6) {K}sh lacks the "{a,b,c}" expansion.

ksh-88 can be compiled with brace expansion. Bash has it by default.

I wouldn't know. We don't have a source license. Nor could I say for sure
what version we are running (although running 'strings' on '/bin/ksh' did
show a string which implies that it might be version '86a').

Is the source for ksh publicly available?
If so, how would I obtain it? [alas, no internet connection here, just uucp!]
Apologies in advance if this is something with a well known answer, such
as in one of the comp.* FAQ lists.

7) Ksh doesn't allow me to use arbitrary strings for identifiers
for aliases.

Korn put this into ksh in one of the minor releases of ksh-88, probably
ksh-88a.

I would not doubt it if the version of ksh supplied with our system is
considerably out of date. We still have X11R3 and Motif 1.0 too ... :-)
We're getting some new machines soon (a different manufacturer's that is) --
it will be interesting to see if things are different there.

--Mark--

[Matthew Farwell]

In article <1991Aug11.2...@dbsm.oz.au> maf@thor (Martin Foord) writes:
>In article <1991Aug8.1...@prl.dec.com> bo...@prl.dec.com (Boyd Roberts) writes:
>>I use `rc', the Plan 9 shell. It's Tom Duff's excellent design and Byron's
>>code. What a lifesaver.
>>No more quoting woes. Clean syntax. No gratuitous bloat.
>>Small amount of source code. Free. Portable. Maintainable. Understandable.
>But unfortuantely not very portable ...

Yeah, but installable at the flick of a switch (practically). I compiled
it, installed it in a day. The next day I switched all of my shell's to
it.

Neither of these problems have anything to do with rc.

I've looked at the manual twice since I first read it. I now know the
syntax well enough to be able to write scripts in it fairly competently.

In short, I agree with Boyd. I must buy Byron and/or Tom a drink sometime...

Dylan.
--
Matthew J Farwell: dy...@ibmpcug.co.uk || ...!uunet!ukc!ibmpcug!dylan
Never trust a programmer with a screwdriver.

[Martin Foord]

In article <1991Aug18....@ibmpcug.co.uk> dy...@ibmpcug.CO.UK (Matthew Farwell) writes:
>In article <1991Aug11.2...@dbsm.oz.au> maf@thor (Martin Foord) writes:
>>In article <1991Aug8.1...@prl.dec.com> bo...@prl.dec.com (Boyd Roberts) writes:
>>>I use `rc', the Plan 9 shell. It's Tom Duff's excellent design and Byron's
>>>code. What a lifesaver.
>>>No more quoting woes. Clean syntax. No gratuitous bloat.
>>>Small amount of source code. Free. Portable. Maintainable. Understandable.
>>But unfortuantely not very portable ...
>
>Yeah, but installable at the flick of a switch (practically). I compiled
>it, installed it in a day. The next day I switched all of my shell's to
>it.
>
>Neither of these problems have anything to do with rc.

I can only see one problem mentioned above. `rc' is a beautiful shell. It
fixes many of the woes shell programmers have faced for many years. When `rc'
came over the net I immediately installed and used it. The problem above
is portability. `rc' unfortunately is not found all UN*X systems (pity).
So what happens when I use `rc' all the time and have it fully under my belt
and then take on the new contract at a site that doesn't have rc and what's
more doesn't want public domain s/w on it's production machines (and in the
scripts that are used in the production code). I then have to learn the ins
and outs of the Bourne shell. Then what about all those groovy scripts I'd
like to post over the net to those who don't have rc ... etc. etc.

There is *much* advantage in knowing the Bourne shell (and the standard UN*X
utilities ...). Maybe the moral to the story is to start pushing people
to distribute `rc' with their o/s ... But then again I wouldn't mind seeing
perl on all UN*Xs :-)

All our thanks to Byron on his implementation of `rc' and the ease at which
one can make it on their system.

maf.

[Tony J Yeates]

In comp.unix.shell you write:

>In article <1991Aug07....@convex.com>, tch...@convex.COM (Tom Christiansen) writes:
>|> From the keyboard of a...@world.std.com (Anthony P Lawrence):
>|> :So, the question is: why is the csh so inappropriate for shell
>|> :programming and why don't those using it realize this?
>|>

The reason is that despite some weaknesses (my favourite is when you
try to give a gizillion filenames to a command like grep and is says
"Arguments too long" - soln... go into ksh and execute the same command!),
csh does have some redeeming features. Its script language is fairly
intuitive for C-programmers (&&, etc.), its history mechanism was
a big improvement on nothing (the sh option at the time), although
this feature is somewhat dated, its "terseness" when incorporated into
the more modern (ksh-like) history mechanism of tcsh makes for a VERY nice
interactive environment (its really fast and easy to, say, swap the
arguments of a command around, or alter a single char. or phrase in a command
without actually recalling the line and editing it). The switch/case
mechanism is better in csh than ksh IMHO (you can fall thro' to
the case if you wish to execute the same commands) and the word arrays
work very well, although I now prefer to write scripts in ksh
(see favourite bug weakness above) it also seems to be more widely "spoken" here.

>Now for the answer to the second part: Why are we using csh?

The bottom line is that you can write most scripts just as easily in csh as
ksh or sh. I haven't found csh to be paricularly buggy, only one bug springs
to mind, and I've written a lot of csh scripts, some quite "involved".

>Because when we got UNIX bsd3.2, csh was sex and sh was syphilis.

Interesting analogy!

>And, I (blushblush) still havn't got the hang of sh's version of 'foreach'
>which I use frequently...

I just tried this on the command line (I do that a lot in tcsh/csh), its pretty
similar, but you have an additional step ...putting a "do" as the first "command"
after the for e.g.

for i in a b c d e f g
> do
> echo $i
> done

vs.
foreach i ( a b c d e f g )
> echo $i
> end

Blush no more!

>And I haven't the time to learn a whole new shell.

Thats prob. the biggest reason we still use csh for scripts.

[Sergio L Aponte]

I've found that almost (99%) of all scripts we write and use are sh,
but most all of us "live" on csh. I've tried ksh for a while and ended
up back on csh.
--
=============================================================== _|||_
Sergio L. Aponte, MTS @ ASK Computer, Ingres Product Division <*,*>
Internet : ser...@coqui.ingres.com [`-'] Keko
UUCP : {sun,mtxinu,pyramid,pacbell}!ingres!coqui!sergio _"_"_ Jones

[Ronald Mayer]

Lots of people write:
[Since csh is a lousy script language, and various hacks based on sh
have been written which contain all the advantages of csh, why would
anyone use csh]

What about the inverse of this question:
Why do we use *sh* anymore?

For normal interactive use, csh is considered a bit friendlier than sh
by many people. Recently people have written programs which are much
better scripting languages than sh (most notably, Larry Wall's perl).
If I were recommending shells to someone relatively new to unix shell
programming, I would suggest that they learn csh [or some variant] for
interactive use and perl for a scripting langage. Does anyone have
any problems with this suggestion?

Looking over Tom Christiansen's posting, it seems that nearly all the
advantages of sh don't apply much to normal interactive use, except
for csh's really stoopid quoting conventions. [For interactive use:
redirection can usually be done easier through files; inconsistancies
with builtins can usually be avoided via trial-and-error; trapping
signals doesn't apply; variables aren't used that extensively; and
random bugs are often more entertaining than harmful.] Does anyone
have a list of advantages of sh over csh for interactive use?

Yes, as a scripting language, sh's advantages regarding portablility
is vital to some people, but this really isn't much of a concern for
most scripts that most people write.

Summary:
For interactive use: csh >= sh
tcsh == ksh = bash = ...
As a scripting language: sh >> csh
sh <= ksh <= bash # due to portability concerns
perl >> sh

What we really need is a good new interactive shell; designed to
be an interactive shell, *not* a scripting language.

Ron Mayer
ma...@sono.uucp

Of course we could write a one-line shell in perl so we can have the
same shell as scripting language (1/2 :-)

[Tom Christiansen]

From the keyboard of ma...@sono.uucp (Ronald Mayer):

:Lots of people write:
:[Since csh is a lousy script language, and various hacks based on sh
: have been written which contain all the advantages of csh, why would
: anyone use csh]
:
:What about the inverse of this question:
: Why do we use *sh* anymore?
:
:For normal interactive use, csh is considered a bit friendlier than sh
:by many people. Recently people have written programs which are much
:better scripting languages than sh (most notably, Larry Wall's perl).
:If I were recommending shells to someone relatively new to unix shell
:programming, I would suggest that they learn csh [or some variant] for
:interactive use and perl for a scripting langage. Does anyone have
:any problems with this suggestion?

Oh, probably, but I'm surely not one of them.

Actually, I'd probably vote for bash as an interactive shell.
Tcsh is ok, too, but the cshness give me the willies. If you
don't have either of these, use ksh. Otherwise write your own. :-)

--tom

[Bruce Barnett]

In article <1991Aug21.2...@sono.uucp> ma...@sono.uucp (Ronald Mayer) writes:
> What we really need is a good new interactive shell; designed to
> be an interactive shell, *not* a scripting language.

A good posting, but I don't quite agree with the last line.

Several good (i.e. better than csh) interactive shells *are* available.
This doesn't make them a standard, however. 90% of the people here use
csh, mostly because of inertia. Also because there is no other shell
installed on every machine we have here. People use the csh for
scripts because they use it for their interactive session.

I think every vendor should ship ksh. Once this happens, csh might go away.
Not before.

Why force a beginner to learn two complex tasks simultaneously?
It's hard enough to learn one shell, yet alone two.
Keeping track of the subtle differences between csh and sh is
difficult for a beginner. I understand why a csh user uses csh for the first
shell scripts: it avoids the doubly steep learning curve.

In fact, the C shell has a built-in migration strategy. Sooner or later the user
will discover a bug in the C shell, and be forced to write it in sh. :-)

--
Bruce G. Barnett bar...@crdgw1.ge.com uunet!crdgw1!barnett

[jimka...@gmail.com]

A good way to redirect output to stderr in csh is the following trick.

csh> echo hello | sh -c 'cat 1>&2'

In fact you can make it a bit more readable as follows :

csh> alias STDERR "sh -c 'cat 1>&2'"
csh> echo hello | STDERR


I hope this helps someone.

[Kaz Kylheku]

On 2016-09-27, jimka...@gmail.com <jimka...@gmail.com> wrote:
> A good way to redirect output to stderr in csh is the following trick.
>
> csh> echo hello | sh -c 'cat 1>&2'

LOL!

You just essentially posited that a good way to do something in the csh
is to invoke the POSIX shell.

We can take this suggested improvement to the next level:

csh> exec sh
$ echo hello 1>&2

[Lew Pitcher]

On Tuesday September 27 2016 09:47, in comp.unix.shell, "jimka...@gmail.com"

<jimka...@gmail.com> wrote:

> A good way to redirect output to stderr in csh is the following trick.
>
> csh> echo hello | sh -c 'cat 1>&2'

I don't understand how this improves on the csh(1) manpage suggestion to use a
construct like:
(command > output-file) >& error-file
(where either output-file or error-file may be /dev/tty)


--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[Rakesh Sharma]

I use the following stratagem to get cshell to write messages to stderr:

% alias 2err 'echo \!* > /dev/stderr;'
% 2err hello world

N.B.: This presupposes the existence of /dev/stderr, which may not be true for
all OSs (e.g., SunOS)

[Michael Paoli]

On Sunday, August 4, 1991 at 1:11:47 PM UTC-7, Robert R. Bruner wrote:
> I have a cshell program which attempts to avoid overwriting a file
> by using
> echo -n The file already exists. Overwrite (y/n)?
> The problem is that if I redirect output of the shell program to
> a file, I never see the error message, and end up wondering what
> enormous program is slowing the machine down so much. Eventually,
> I realize what is going on, but I can't expect others to do so.
> Is there a way I can make the echo command send its output to stderr
> so that redirection of stdout will not hide the message? Obviously
> I can write a little C program to print the message on stderr, but
> I prefer to do it all within the script if at all possible.
>
> Thanks in advance for any answers to what must be an incredibly
> elementary question. I don't write that many scripts, and this is
> my first attempt to use news.
>
> Robert Bruner r...@math.wayne.edu

First, see ...
https://www.google.com/search?q=(+"c-shell"+OR+csh+)+"considered+harmful"

And, well, then if you must in csh, do something like:
/bin/sh -c ' \
echo \\c | read x \
if [ $? -ne 0 ]; then \
1>&2 echo The file already exists. Overwrite \(y/n\)?\\c \
else \
2>>/dev/null echo -n "" | read x \
if [ $? -ne 0 ]; then \
1>&2 echo -n The file already exists. Overwrite \(y/n\)? \
else \
exit 1 \
fi \
fi \
' || your_error_handling_code_here

or perhaps:
perl -e 'print STDERR q(The file already exists. Overwrite (y/n)?);' || your_error_handling_code_here

Also, not what you asked, but if it might be suitable, could potentially
redirect to, instead of stderr, /dev/tty
Some operating systems may also provide a (pseudo) file pathname that
can be used as stderr, e.g. /dev/fd/2 or /dev/stderr - but that's quite
non-portable, as, well, is csh code/scripts in general.

And as was elsepost suggested on/around "thread":
echo -n 'The file already exists. Overwrite (y/n)?' | sh -c 'cat 1>&2'

[Keith Thompson]

Lew Pitcher <lew.p...@digitalfreehold.ca> writes:
> On Tuesday September 27 2016 09:47, in comp.unix.shell, "jimka...@gmail.com"
> <jimka...@gmail.com> wrote:
>
>> A good way to redirect output to stderr in csh is the following trick.
>>
>> csh> echo hello | sh -c 'cat 1>&2'
>
> I don't understand how this improves on the csh(1) manpage suggestion
> to use a construct like:
> (command > output-file) >& error-file
> (where either output-file or error-file may be /dev/tty)

The "sh -c" trick sends both stdout and stderr to stderr.

The pure csh construct sends stdout to one named file and stderr
to another. Redirecting to /dev/tty is not helpful if the command
is in a script whose output has already been redirected.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"