csh scripts
Gerald Hall
either an attempt at humor or just plain bull. It reminds me
of a group of clerics insisting that significant intellectual
discussion can only take place in Latin (when of course we know
that only Greek is capable of expressing truly deep thoughts).
I will give you that if portability is of ultimate importance
then using /bin/sh (7th Edition features only) is clearly
necessary. If it is speed that is at issue I think you will
find that there is not that much difference for most tasks
and that some of the csh builtins can actually make it faster
for some things. If speed is really that important then it
should be in C. If it is bugs, any wizard should know what
to avoid with csh to avoid problems (add those spaces!).
In defense of csh scripts I will quote Nietzsche: "Whoever
knows he is deep strives for clarity." I find that csh scripts
are generally easier to understand and maintain. I occasionally
feel a bit of nostalgic pull for esac and fi, or knowing that
'[' is linked to 'test', and I do write a few sh scripts.
But, I use csh for significant script work. I have writen a
couple of 200-300 line csh scripts and a bunch of shorter ones
that make my life significantly easier as sysadmin at a moderately
large (~200 system) UNIX site. To assert that these are flawed
because they are not in the blessed sh is pure pedantry and
hubris.
--
/
/ Jerry, CalmaSD UNIX SysAdmin, +1 619 587 3065
/
John Navarra
>
>I will give you that if portability is of ultimate importance
>then using /bin/sh (7th Edition features only) is clearly
>necessary.
ok.
> If it is speed that is at issue I think you will
>find that there is not that much difference for most tasks
>and that some of the csh builtins can actually make it faster
>for some things.
ok. I guess.
> If speed is really that important then it
>should be in C.
agreed.
> If it is bugs, any wizard should know what
>to avoid with csh to avoid problems (add those spaces!).
Here is the problem. A wizard knows when to use the best tool for the job.
Csh is never really the best tool for the job when it comes to programming.
Why would I want to have detailed knowledge of what to avoid with csh when
I can program in relative safety in sh?
Furthermore, if I want speed and power, but do not have the time
to muddle through a C program, why would I not use perl -- a damn fine
tool for any job?
Assume, for a moment, that I do know everything to avoid when it comes to
csh. Now, my boss (the great sympathetic man he is) wants me to add more
functionality to my script. Meanwhile, summing up my sad puppy look, I
manage to say "Csh can't do that". Whereas, if I had just used another
shell, or another utility, this could all be avoided. Csh programming
can also be considered DANGEROUS.
>
>In defense of csh scripts I will quote Nietzsche: "Whoever
>knows he is deep strives for clarity."
This is the same guy who claimed to be God. ;-)
>To assert that these are flawed
>because they are not in the blessed sh is pure pedantry and
>hubris.
Quick Robin, to the dictionary.
-tms
Larry Briski
>In article <48...@calmasd.Prime.COM> g...@calmasd.Prime.COM (Gerald Hall) writes:
( Bunch of stuff deleted )
> Csh programming
>can also be considered DANGEROUS.
^^^^^^^^^
Could somebody expand on this thought. What is meant by "DANGEROUS" here.
( More stuff deleted )
>-tms
>
larry
--------------------------------------------------------------------------------
Lawrence Briski | "If at first you don't succeed, try,
Cray Research Inc. | try again; then quit--there's no sense
Chippewa Falls, WI 54729 | in being a damn fool about it."
lawrenc...@cray.com | W.C. Fields
--------------------------------------------------------------------------------
All Disclaimers Apply
--------------------------------------------------------------------------------
John Navarra
>In article <1992Aug4.0...@news.acns.nwu.edu> nav...@casbah.acns.nwu.edu (John Navarra) writes:
>> Csh programming
>>can also be considered DANGEROUS.
> ^^^^^^^^^
As in 'job threatening'.
-tms
Robert A. Lentz
Depends on what you do with it, John :-)
Actually, maybe I am missing something (I looked through the man page) but
it seems to me that csh is much better at debugging. I recently had to deal
with a package with large sh scripts and it was a pain debugging for our
environment, sh does not seem to have anything as nice as "csh -xv".
(Or, dare I say, even VMS's SET TERM/VERIFY.) And the output from sh -x is
real screwy anyhow in the way it echoes some stuff. Of course if I had
written the scripts I could have built in a nice debugging structure, but
it would have taken too long to add.
-Robert Lentz
--
r-l...@nwu.edu "We're a rock-and-roll band and we'll bring down the house
the way Bill is going to bring down the country."
-Roger Clinton, on his band's plans to play at the
Inauguration if his half brother, Bill, wins.
Tom Christiansen
:Actually, maybe I am missing something (I looked through the man page) but
:it seems to me that csh is much better at debugging. I recently had to deal
:with a package with large sh scripts and it was a pain debugging for our
:environment, sh does not seem to have anything as nice as "csh -xv".
:(Or, dare I say, even VMS's SET TERM/VERIFY.) And the output from sh -x is
:real screwy anyhow in the way it echoes some stuff. Of course if I had
:written the scripts I could have built in a nice debugging structure, but
:it would have taken too long to add.
My sh certainly groks -xv, and it's a pretty old one. Yours doesn't?
Of course for scripts of any complexity, I always use "perl -d", which
gives me a real symbolic debugger rather than merely a tracing facility.
--tom
--
Tom Christiansen tch...@convex.com convex!tchrist
"* Unix is a footnote of AT&T Bell Laboratories."
--Barry Shein
Bruce Barnett
> Here is the problem. A wizard knows when to use the best tool for the job.
> Csh is never really the best tool for the job when it comes to programming.
> Why would I want to have detailed knowledge of what to avoid with csh when
> I can program in relative safety in sh?
That is bull. A wizard knows the limitation of their tools. I've
written thousands of scripts in sed, sh, perl, csh and awk. I use them all.
Yes, csh has bugs. So? I know how to avoid 99.99% of them when I
write a csh script.
Many people who deride csh use csh or tcsh as their login shell.
Are they hypocrites? Perhaps.
Many sites do not have any shell besides sh and csh. Blame the
vendors, not the users.
Many users have a hard time learning csh and sh at the same time.
They need to learn csh so they can have a nice interactive
environment. Telling them they have to forget to learn csh and to only
learn sh is very condescending. Many MUST learn csh ANYWAY.
In my book, a wizard is NOT someone who criticizes their tools. It's
someone who recognizes the limitations of each tool and knows how to
get the job done in spite of the limitations of each of those tools.
I'm really getting tired of all of these "my shell is better that
yours" postings.....
--
Bruce Barnett <bar...@crd.ge.com> uunet!crdgw1!barnett
Terry Lambert
|> In article <48...@calmasd.Prime.COM> g...@calmasd.Prime.COM (Gerald Hall) writes:
|> >
|> > If it is bugs, any wizard should know what
|> >to avoid with csh to avoid problems (add those spaces!).
|>
|> Here is the problem. A wizard knows when to use the best tool for the job.
|> Csh is never really the best tool for the job when it comes to programming.
"A true Wizard may write FORTRAN programs in any language, except,
perhaps, FORTRAN itself".
I have to assume that this includes csh script.
|> Furthermore, if I want speed and power, but do not have the time
|> to muddle through a C program, why would I not use perl -- a damn fine
|> tool for any job?
"When the Tao is in a Wizard, he does not code; rather, the code flows
_through_ the Wizard. He is but a conduit for the Tao, to be used by
the Tao as it desires. The Wizard may not know of that which he codes,
until he looks back upon the completed work, and so sees it in it's
entirety. Then the Wizard will say 'Oh, that's obvious'. That is the
nature of the Tao."
This sort of implies that Wizards do not muddle. It also implies that
the same amount of time will be taken for "the Tao to flow through", as it were,
regardless of the destination language. This is not to denigrate perl, however,
even thout it doesn't seem to appear anywhere in the holy writ.
|> Assume, for a moment, that I do know everything to avoid when it comes to
|> csh. Now, my boss (the great sympathetic man he is) wants me to add more
|> functionality to my script. Meanwhile, summing up my sad puppy look, I
|> manage to say "Csh can't do that". Whereas, if I had just used another
|> shell, or another utility, this could all be avoided. Csh programming
|> can also be considered DANGEROUS.
"The student approached the Master and hesitated. 'Master', asked the
student, 'will you not enlighten me? I have written a C program to
perform a task, but can not overcome the one remaining obstacle; yet
I know it can be overcome. One of the small utility programs does so.'
The master shook his head and answered the students question with one
of his own 'does not C support the system(3) library function? Call
the small utility program from your program. When you have become a
Wizard, you can rewrite your program; until then, it is not wrong to
stand on another's shoulders'".
This would imply that "Csh can't do that" is an incorrect statement;
any language capable of calling another program, even a Bourne shell script,
includes the capabilities of that program.
|> >To assert that these are flawed
|> >because they are not in the blessed sh is pure pedantry and
|> >hubris.
Pedantry: This posting, among other things. ;-) ;-)
Hubris: Greek, loosely translatable as "Inordinate Pride", esp. in
references to statements above one's station.
Quotes from "The Annotated, Translated Tao of UNIX Wizardry" -- another fine
example of pedantry and hubris. 8-).
Terry Lambert
terry_...@gateway.novell.com
te...@icarus.weber.edu
---
"We don't care; we don't have to: we're the phone company"
"You'll eat it; you have to: we're Beatrice"
---
Disclaimer: Any opinions in this posting are my own and not those of
my present or previous employers.
John Navarra
>In article <1992Aug4.0...@news.acns.nwu.edu> nav...@casbah.acns.nwu.edu (John Navarra) writes:
>
>> Here is the problem. A wizard knows when to use the best tool for the job.
>> Csh is never really the best tool for the job when it comes to programming.
>> Why would I want to have detailed knowledge of what to avoid with csh when
>> I can program in relative safety in sh?
>
>That is bull. A wizard knows the limitation of their tools. I've
>written thousands of scripts in sed, sh, perl, csh and awk. I use them all.
So do I. (all except csh)
Given that csh is NOT my login shell (bash is), name something I
cannot do in bash/sh, perl, sed or awk that can do in csh. Since I can't
think of anything off the top of my head, I would have to say I can do
everything you can do with less. Sounds better to me.
>
>Yes, csh has bugs. So? I know how to avoid 99.99% of them when I
>write a csh script.
Yeah, so do I. I don't use it. And, its not just the bugs,
its the 'limitations' as you keep saying.
>
>Many people who deride csh use csh or tcsh as their login shell.
>Are they hypocrites? Perhaps.
No. Part of the reason you quote below. If given a choice between
a login shell, I would pick csh. However, that doesn't mean I would ever
program in it. And obviously, those who get used to csh naturally migrate
to tcsh which is much much better.
>Many sites do not have any shell besides sh and csh. Blame the
>vendors, not the users.
I am not blaming ANYONE for *having* to use csh. I do blame
EVERYONE who uses csh to program in. It's real simple:
#!/bin/sh
But its not like I can't get off my lazy ass and ftp bash, zsh, tcsh etc
from somewhere and compile it. Then I have more choices.
>Many users have a hard time learning csh and sh at the same time.
>They need to learn csh so they can have a nice interactive
>environment. Telling them they have to forget to learn csh and to only
>learn sh is very condescending. Many MUST learn csh ANYWAY.
I am not being condescending. Neither are other people who warn
of the dangers of programming in csh. Learning to use csh as an interactive
shell is different than learning how to program in csh.
>
>In my book, a wizard is NOT someone who criticizes their tools. It's
>someone who recognizes the limitations of each tool and knows how to
>get the job done in spite of the limitations of each of those tools.
?? This is silly. Remember the three pigs? Well, which one would
move back into the straw house when he can live in the brick one? Wizards
use the best tool for the job, period. I don't count myself a wizard yet
but I certainly don't want to be discussing limitations (i.e. circumventing
dumb problems with a brain-dead shell) when I could be thinking more
of results (and the next challenge)
>I'm really getting tired of all of these "my shell is better that
>yours" postings.....
>
Hey now look -- this is the farthest from what I was saying.
The general statement "Csh programming is a bad thing" is considered
a true statement by most of those in the know. This is a very different
statement than, "Sh is a better shell than Csh" or "Bash is better than
Tcsh". Not that I mind arguing which shell is better, but if people like
you continue to feel as if you MUST use csh, then how are the vendors
going to know NOT to ship it?
-tms
John Navarra
>
>
>Quotes from "The Annotated, Translated Tao of UNIX Wizardry" -- another fine
>example of pedantry and hubris. 8-).
>
that in the last few days we have had quotes from both Nietzsche and
Confucius, use of the word 'pendantry' and 'hubris' in the same post,
various tidbits from the 'Tao of UNIX Wizardry' (obviously a real sick
someone), an enlightening discussion of the merits of recognizing wizards
by which hot beverage they prefer (cappucino vs coffee), and Dan
Bernstein's breaking of the five-foo rule in his last post.
What was that about costing the net thousands of dollars????
-tms
Bruce Barnett
> Given that csh is NOT my login shell (bash is), name something I
> cannot do in bash/sh, perl, sed or awk that can do in csh. Since I can't
> think of anything off the top of my head, I would have to say I can do
> everything you can do with less. Sounds better to me.
Okay. I'll give some examples. Some ground rules here. We are
comparing sh and csh only. As I said, assume using shells all vendors
support. If you assume non-portable shells, perl is what I use. The
issue is not what sh can do that csh cannot do. There are many cases
when sh is obviously better.
I am talking about programming constructs that are easier to do in csh
than in sh, which is why I use csh for some scripts.
Of *course* they could be done in sh. But the point is that it is more
*complicated* to do them in sh than in csh.
1) Cases where the { , , } construct is useful. The mklost+found
script bsd systems had that created many temporary files is an example.
Creating the files A000 thru A999 is simply
touch A{0,1,2,3,4,5,6,7,8,9}{0,1,2,3,4,5,6,7,8,9}{0,1,2,3,4,5,6,7,8,9}
2) Cases where you want to browse thru the search path. For instance,
a simple version of which(1) that (a) ignores aliases and (b) shows
all executables instead of the first one can be simply
foreach p ( $path )
foreach i ( $* )
if ( -f $p/$i && -x $p/$i ) echo $p/$i
end
end
I examine my searchpath in many scripts, BTW.
3) Cases where you want several arrays at once.
This is one case when sh is a real pain to use. It only has one array: $*.
There are many times when I want to have several arrays with *names*
and I want to do something like
A[1] = B[1] + C[1]
or
echo "$name[$i] $size[$i] $perm[$i] $owner[$i]"
I would have to go thru many complicated steps if I used sh.
I can't see why it's worth it.
4) Cases when you wish to avoid excessive use of basename or expr.
I normally don't care about the number of processes, but I wrote a csh
script that bounced a shelltool window around the display, with
appropriate flattening of the window whenever it richocheted off a
side of the screen. It didn't require any forks to execute.
I couldn't do this in sh. Okay - that's a contrived example. But it is
fun to watch :-)
> Yeah, so do I. I don't use it. And, its not just the bugs,
> its the 'limitations' as you keep saying.
And as I said, sh has limitations also. I use both.
> No. Part of the reason you quote below. If given a choice between
> a login shell, I would pick csh. However, that doesn't mean I would ever
> program in it.
> I am not being condescending. Neither are other people who warn
> of the dangers of programming in csh. Learning to use csh as an interactive
> shell is different than learning how to program in csh.
I disagree.
So you are saying people should use csh as an interactive shell and
not know how to write an if statement? Everyone should
learn how to program in the shell they use as an interactive environment.
It is easier to learn one thing at a time than to learn two things at
a time. Telling people that can use a shell interactively but don't
bother to learn anything else about it is unrealistic.
Rather than get into a heated argument, how about an example in a
hopefully humorous vein.
Here is a scenario that I imagine some people might go thru when
confronted with a devoted csh basher. The individual known as "PW" is
not based on anyone in particular.
New User: I want to change my search path and also have my directory
shown as part of my prompt. How do I do this in csh?
Pretentious Wizard on USENET: The C shell in an abomination! Remove it from your
disk! FTP the UltraShell, compile it and install it.
NU: What's FTP? How do I compile it? I don't have permission to
install it.
PW: Never mind. Use the Bourne shell. It's much better for programming purposes.
NU: So I use use sh for everything?
PW: No (grumble, mutter) csh is okay for interactive use, if that's all you have.
NU: I am getting so confused. I keep getting syntax errors.
PW: Of course you are! You are typing sh commands when in csh and vice versa.
NU: Okay. I finally wrote a sh script that changes my search path. But
it doesn't work.
PW: Of course it doesn't work! You can't change your environment from
a child process!
NU: But you told me to use sh for programming!
PW: Of course! All you have to do is use the '.' command - oh, I mean
the "source" command since you are using the abominable shell.
NU: I tried this and everything broke!
PW: Of course! You set your search path using the sh format and not
the csh format! No wonder everything broke! All right - you are
allowed to read SOME of the csh manual pages, but if it looks like
programming, ignore it.
NU: Okay. I've set my search path. But if I'm on machine "A" I want
one search path. If I'm on machine "B" I want another search path.
How do I write a csh script that does this.......?
PW: The C shell in an abomination! Remove it from your
disk! FTP the UltraShell ....
Larry Wall
: someone who recognizes the limitations of each tool and knows how to
: get the job done in spite of the limitations of each of those tools.
Hmm, you've sort of contradicted yourself. Part of getting the job
done is knowing when to scrap the tools you have. This requires a
certain critical facility.
Now, I understand that you're using the word "criticize" in the popular
sense of "express emotionally vexing utterances", and I even understand
the sentiment of not wanting to be emotionally vexed. Nevertheless,
this does not mean that some of us should not want, in a rather
dispassionate sort of way, to put a bullet through csh's head.
Larry Wall
lw...@netlabs.com
John Navarra
>
>> Given that csh is NOT my login shell (bash is), name something I
>> cannot do in bash/sh, perl, sed or awk that can do in csh. Since I can't
>> think of anything off the top of my head, I would have to say I can do
>> everything you can do with less. Sounds better to me.
>
>Okay. I'll give some examples. Some ground rules here. We are
>comparing sh and csh only. As I said, assume using shells all vendors
>support. If you assume non-portable shells, perl is what I use. The
>issue is not what sh can do that csh cannot do. There are many cases
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>I am talking about programming constructs that are easier to do in csh
>than in sh, which is why I use csh for some scripts.
>Of *course* they could be done in sh. But the point is that it is more
>*complicated* to do them in sh than in csh.
[cases when csh is far far superior to sh deleted]
I said in a previous post "Wizards use the best tool for the job, period."
Now, given the environment you suggest (vendor shipped only sh and csh)
you present some cases where csh constructs are superior to similar sh
constructs. According to my statement, then, a wizard would then use
csh in the cases you present because it was the best tool for the job.
However, if to use your own statements, "There are many cases when sh
is obviously better" and "Of *course* they could be done in sh", at
what point does being 'wizardly' mean that you neglect a tool that
in rare circumstances, may perform better than another tool in favor
of a tool which is obviously better in most cirumstances? If the
answer to that question is "No, you would never neglect that tool
because being a wizard means you use the best tool for the job", then
what about that fact that some things just simply CANNOT be done
in csh? Then do you start neglecting it? No? At the very least,
I would not have nightmares wondering about what I could not do
to improve my csh script because of lack of functionality.
Let me retract that 'period' in the statement "Wizards use the best
tool for the job, period." Upon further examination which I would be
happy to hear other opinions on, it would seem to be that reliability
may be just a bit more important than 'the best tool for the job.'
The environment you suggest is very very constricting. If I only have
sh and csh to work with and no way of improving this situation, I
am pretty much stuck between a rock and a hard place.
>> Yeah, so do I. I don't use it. And, its not just the bugs,
>> its the 'limitations' as you keep saying.
>
>And as I said, sh has limitations also. I use both.
Given the environment you suggest ( a hell on earth for a
serious programmer) I guess I would become real adept at when to
use csh and when to use sh too. If csh and sh didn't have limitations,
there would be no need for bash, tcsh, zsh, rc, perl, awk, etc. Given
that I have access to all those tools, I find no circumstance where I need
to use csh. Given that you have access to all those tools, I don't know why
you use csh.
>> I am not being condescending. Neither are other people who warn
>> of the dangers of programming in csh. Learning to use csh as an interactive
>> shell is different than learning how to program in csh.
>
>I disagree.
>So you are saying people should use csh as an interactive shell and
>not know how to write an if statement? Everyone should
>learn how to program in the shell they use as an interactive environment.
>It is easier to learn one thing at a time than to learn two things at
>a time. Telling people that can use a shell interactively but don't
>bother to learn anything else about it is unrealistic.
I don't really know a foolproof way of addressing this problem.
I see many people in various stages of development with UNIX. The ones
that use csh and then begin to write shell scripts discover that they
have to learn sh real quick. The ones that use sh discover that their
shell isn't user-friendly enough as an interactive shell and may then
migrate to csh. I find the second case an easier transition.
Since I used bash from day 1, I had all the interactive
capabilities of csh combined with all the programming capabilities
of sh. I never had to learn much about csh. And I still find no reason
to know *that* much about it.
Perhaps those who program extensively in sh but use csh or
tcsh as an interactive shell may want to comment on that. How much
csh do you use?
You imaginary conversation below is not unrealistic. And I
would admit you have touched on a problem that all new users face.
Unfortunately, the only solution I see is banning csh from the planet
so no one ever has to use it. At least my way, a user would never have
to discover that he now has to know two shells -- one to program in,
and one to use interactively. Obviously, many people have already
seen this problem wrote new shells so this process would be unneeded.
Now, all we need is for people to USE them and lay csh to rest once
and for all.
-tms
--
From the Lab of the MaD ScIenTiST:
nav...@casbah.acns.nwu.edu
Neil Rickert
>Let me retract that 'period' in the statement "Wizards use the best
>tool for the job, period." Upon further examination which I would be
>happy to hear other opinions on, it would seem to be that reliability
>may be just a bit more important than 'the best tool for the job.'
>
>The environment you suggest is very very constricting. If I only have
>sh and csh to work with and no way of improving this situation, I
>am pretty much stuck between a rock and a hard place.
I'm afraid I look at things differently from you.
As I see it, if I need a script which can be handled adequately with
sh or csh, I should use those, and not try bash or perl etc. Perhaps
next week somebody else will take over my position. Perhaps the week
after that the hardware will be replaced, and my successor may not want
(or be able) to install perl on the new hardware. If I use sh or csh
my efforts will still have paid off. Professionalism requires using
the most generally available and well known tools that are adequate for
the job. Occasionally this means csh.
> Given the environment you suggest ( a hell on earth for a
>serious programmer) I guess I would become real adept at when to
>use csh and when to use sh too.
A serious programmer uses the best tools available to him and understood
by him when programming for himself. But when programming for somebody
else, he uses the best tools available to and understood by his client.
> Perhaps those who program extensively in sh but use csh or
>tcsh as an interactive shell may want to comment on that. How much
>csh do you use?
I almost exclusively use csh as an interactive shell, but most of my
shell programming is in sh. However there are a few circumstances when
I would prefer csh. One obvious example would be if I need the builtin
'kill'.
Mark Bush
# As I see it, if I need a script which can be handled adequately with
#sh or csh, I should use those, and not try bash or perl etc. Perhaps
#next week somebody else will take over my position. Perhaps the week
#after that the hardware will be replaced, and my successor may not want
#(or be able) to install perl on the new hardware. If I use sh or csh
#my efforts will still have paid off. Professionalism requires using
#the most generally available and well known tools that are adequate for
#the job. Occasionally this means csh.
Perhaps this reasoning is why the progress of things like `bash' and `perl'
takes so long.
If the hardware changes and a new OS is used, who is to say that the csh and
sh (if available) will be compatable enough that your scripts still work?
Perhaps the new setup will be so different that they don't have csh or sh?
If these things really concern you, then wouldn't it be better to use an
independant scripting language?
I don't use perl for everything, but I don't let any future posibilities
stop me from using it in situations where it is the best tool for the job.
My scripts are for me to use to make my life easier on the system we have
here now. If future systems/people mean that these tools will not be
available, I suspect that converting my scripts to use on the new setup
would be the least of anyone's problems (that is, if it is so different that
the current binary won't just drop in, then the same will be true of most
(if not all) our third party software).
I sincerely hope that the future does not mean we must continually restrict
ourselves to the tools that were available 10 years ago.
Mark
Bruce Barnett
>is obviously better" and "Of *course* they could be done in sh", at
>what point does being 'wizardly' mean that you neglect a tool that
>in rare circumstances, may perform better than another tool in favor
>of a tool which is obviously better in most cirumstances? If the
>answer to that question is "No, you would never neglect that tool
>because being a wizard means you use the best tool for the job", then
>what about that fact that some things just simply CANNOT be done
>in csh? Then do you start neglecting it? No? At the very least,
>I would not have nightmares wondering about what I could not do
>to improve my csh script because of lack of functionality.
As I said earlier, I use sh and csh for shell scripts. Since I know
what can be done easily in sh and what can be done easily in csh, and
since I know what limitations csh has, I don't have problems.
>The environment you suggest is very very constricting. If I only have
>sh and csh to work with and no way of improving this situation, I
>am pretty much stuck between a rock and a hard place.
Yup. Life is hard for someone trying to get up to speed with UNIX.
Many are still trying to handle quoting properly, and many never
master it.
The main point is that many people must master csh, because they are
beginners and have a restricted environment. Yet the
fashionable thing to do is to bash on all csh users, saying how much
better the {x,y,z}shell is. This can really confuse users, who just
want to solve a simple problem and don't want a debate on the greatest
shell in the world.
Perhaps I should include comp.unix.shell in this thread, because that
is where the worst bashing occurs. But the self-proclaimed "wizards"
are more likely to bash than not.
I am arguing for those users who haven't had years of
UNIX experience. Telling these users to "/bin/rm /bin/csh", switch
shells, FTP the Ultra shell, etc. while they are still learning about
the function of environment variables is very disruptive. It really
doesn't help.
> Now, all we need is for people to USE them and lay csh to rest once
> and for all.
Only when all vendors support shells besides sh and csh.
Until then, show some compassion once in a while.
John Navarra
>beginners and have a restricted environment. Yet the
>fashionable thing to do is to bash on all csh users, saying how much
>better the {x,y,z}shell is. This can really confuse users, who just
>want to solve a simple problem and don't want a debate on the greatest
>shell in the world.
>
don't use csh. I didn't say anything about beginners using csh. I also
didn't say much about those who were forced to use csh. In my opinion,
that is the fault of the people purchasing the software/too lazy to get
improved software.
>> Now, all we need is for people to USE them and lay csh to rest once
>> and for all.
>
>Only when all vendors support shells besides sh and csh.
>Until then, show some compassion once in a while.
Not for those who use csh when there are obvious better things
around. And certainly not for those who continue to support csh programming
when they know damn well that there are better things out there yet still
seem to insist on beating a dead horse.
Tom Christiansen
:In article <1992Aug5.2...@news.acns.nwu.edu> nav...@casbah.acns.nwu.edu (John Navarra) writes:
:
:1) Cases where the { , , } construct is useful. The mklost+found
:script bsd systems had that created many temporary files is an example.
:Creating the files A000 thru A999 is simply
: touch A{0,1,2,3,4,5,6,7,8,9}{0,1,2,3,4,5,6,7,8,9}{0,1,2,3,4,5,6,7,8,9}
Absolutely. Then again, wouldn't it be easier to
touch A{0-9}{0-9}{0-9}
:2) Cases where you want to browse thru the search path. For instance,
:a simple version of which(1) that (a) ignores aliases and (b) shows
:all executables instead of the first one can be simply
:
:foreach p ( $path )
: foreach i ( $* )
: if ( -f $p/$i && -x $p/$i ) echo $p/$i
: end
:end
Hm.. I'm not sure that I can see how this any easier in csh syntax than sh.
:
:3) Cases where you want several arrays at once.
Yup. Of course, you could use awk or perl if you wanted this.
:4) Cases when you wish to avoid excessive use of basename or expr.
You ought to see some people's makewhatis scripts.
:Here is a scenario that I imagine some people might go thru when
:confronted with a devoted csh basher. The individual known as "PW" is
:not based on anyone in particular.
That's actually pretty funny -- it goes in my humor directory.
--tom
--
Tom Christiansen tch...@convex.com convex!tchrist
"UNIX was not designed to stop you from doing stupid things, because
that would also stop you from doing clever things." -- Doug Gwyn
Bruce Barnett
>
>:2) Cases where you want to browse thru the search path. For instance,
>:a simple version of which(1) that (a) ignores aliases and (b) shows
>:all executables instead of the first one can be simply
>:
>:foreach p ( $path )
>: foreach i ( $* )
>: if ( -f $p/$i && -x $p/$i ) echo $p/$i
>: end
>:end
>
>Hm.. I'm not sure that I can see how this any easier in csh syntax than sh.
With the Bourne shell syntax of $PATH, you have to change colons into
field delimiters, and change blank values into "."
True, it only an extra five lines....
>:3) Cases where you want several arrays at once.
>Yup. Of course, you could use awk or perl if you wanted this.
Perl is always a good solution for complex problems. I am a big fan of
readability. I prefer scripts that are easy to follow. It's true that
perl has a syntax that's harder to master than *sh, but it's
consistent and with liberal comments it's not too bad.
The problem with the awk solution is that it splits the logic between
the shell and awk. If you have arrays in awk, and invocation of other
shell processes in sh, you have split the control into two of more
programs. Besides being awkward, this may force a redesign because the
problem is now more complex.
Allen Swingle
reader, a "Broken Pipe" message is printed. This does not seem to
surprising except the C shell, the K shell, SVR3 Bourne shell, and BSD
shells specifically do not print out "Broken Pipe" when a SIGPIPE signal
is caught, they print nothing. They have special code to not print these
messages out when SIGINT or SIGPIPE is received.
My dilemma, if I change Pyramids SVR4 /bin/sh to not print the messages
that go with SIGINT and SIGPIPE, it will be like all of the other shells,
but it will NOT be like other SVR4 Bourne shells. It appears that there
is an oversight in the SVR4 Bourne shell code, but who should I ask to
get an authoritative answer to this?
Allen Swingle
Pyramid Technology
all...@pyramid.com
John Brock
Seriously. It's nice to know which tools knowledgeable people respect
and which they don't. But what about ksh? It's hardly figured in
the proceedings and I'm feeling left out! Is it worthy? Considered
harmful? Beneath consideration?
Incidentally, as far as I'm concerned IBM's REXX blows away any UNIX shell
I've every seen, at least as a programming language :-)
--
John Brock (212) 909-4662
The First Boston Corporation
12 East 49th Street
New York, NY 10017
uunet!csfb1!jbrock
John Navarra
>Seriously. It's nice to know which tools knowledgeable people respect
>and which they don't. But what about ksh? It's hardly figured in
>the proceedings and I'm feeling left out! Is it worthy? Considered
>harmful? Beneath consideration?
It's not that we aren't considering ksh, but that we are arguing
over the merits of programming in csh vs NOT programming in csh. I claim
that experts do not program in csh unless they HAVE to (for .login scripts
and the like) and even then, they still regret it. Other people claim that
csh is actually useful to program in for rare circumstances. There is the
point that some people do not have access to all the available tools, but
part of the reason for that is because people still insist on using csh
even though there are obviously better FREE choices. The vendors are to
blame here and so are the proponents of a shell which is long past
sticking a fork in.
To argue the merits of a particular shell vs another shell would
be to close to comp.unix.shells.
A Wizard of Earth C
>In article <BswF5...@csfb1.fir.fbc.com> uunet!csfb1!jbrock writes:
>>Seriously. It's nice to know which tools knowledgeable people respect
>>and which they don't. But what about ksh? It's hardly figured in
>>the proceedings and I'm feeling left out! Is it worthy? Considered
>>harmful? Beneath consideration?
>
> It's not that we aren't considering ksh, but that we are arguing
>over the merits of programming in csh vs NOT programming in csh.
If this is literal (which I rather think it isn't), then, as opposed to what
I might answer for "programming in csh vs programming in *anything but* chs",
I'd have to say that programming in csh was much better than not programming,
but it certainly wouldn't be my first choice. 8-).
Terry Lambert
terry_...@gateway.novell.com
te...@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
te...@icarus.weber.edu
"I have an 8 user poetic license" - me
-------------------------------------------------------------------------------