Group asking, what is best SHELL for scripting?
Doug Lenser
shell for scripting and need more ideas.
1--Are there any security or other issues in
using csh for scripting rather than korn shell?
2-- Is there any advantage in using csh for
scripting instead of ksh?
3-- Is there any advantage in using ksh for
scripting instead of csh?
4--Should we forget about shells and go to perl?
What is the latest thought?
thanks for your ideas.
doug
---
Email: doug....@Sun.COM
AlterEgo
: 4--Should we forget about shells and go to perl?
That would be my vote.
You'll get the best of both worlds with a boatload of features and tricks
no shell can give you. And it's more secure, especially for suid scripts.
-AE
Doug McIntyre
>We are having a discussion of the best
>shell for scripting and need more ideas.
>1--Are there any security or other issues in
>using csh for scripting rather than korn shell?
Yes, you can never ever make a csh script setuid or setgid, because
anybody knowing the right tricks can totally circumvent security and
gain whatever rights the script has. No version of csh has ever fixed
this to the best of my knowledge.
>2-- Is there any advantage in using csh for
>scripting instead of ksh?
A more C like scripting environment?
>3-- Is there any advantage in using ksh for
>scripting instead of csh?
Too many to list. Lots of scripting features were added to ksh. Its
not a complete programming language like perl, but it did alot of nice
stuff.
>4--Should we forget about shells and go to perl?
Sure, although perl has a pretty high overhead in memory and
CPU. Watching a perl script go like majordomo on many many lists with
many users is quite the maching humbling experience. Its probably the
best optimized of the lot though, even though its syntax is a horrible
jumble from so many different places.
--
Doug McIntyre mer...@visi.com
Network Engineer/Tech Support/Jack of All Trades of Vector Internet
Due to circumstances beyond your control, you are master of your fate
and captain of your soul.
Thomas L|fgren
Doug> We are having a discussion of the best shell for scripting
Doug> and need more ideas.
Doug> 1--Are there any security or other issues in using csh for
Doug> scripting rather than korn shell?
Doug> 2-- Is there any advantage in using csh for scripting
Doug> instead of ksh?
Doug> 3-- Is there any advantage in using ksh for scripting
Doug> instead of csh?
Any current csh-derived shell should not be used for shell scripting.
There are _plenty_ of reasons on
http://www.cs.ruu.nl/wais/html/na-faq/unix-faq-shell-csh-whynot.html
My reason for not using csh-derived shells at all is that then I would
have to learn two shells; one for interactive use and one for
programming.
Hth,
Tom
--
Wherever I lay my .emacs, that's my ${HOME}
ynot...@my-dejanews.com
mer...@visi.com (Doug McIntyre) asked for the best scripting "shell".
perl rules, IMHO, but the best scripting language is the one that you feel
competent in. Get the job done, unless you're gov't, which will study it to
death!
tony
______________________________________________________________________________
"A real person has two reasons for doing anything ... a good reason and
the real reason."
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Wolfgang Denk
>1--Are there any security or other issues in
>using csh for scripting rather than korn shell?
Yes, there are. Especially if you think about setuid csh scripts -
you can delete your root password as well.
>2-- Is there any advantage in using csh for
>scripting instead of ksh?
No, csh is broken and should *never* used to write scripts. See: "Csh
Programming Considered Harmful", for instance at
http://www.cs.ruu.nl/wais/html/na-faq/unix-faq-shell-csh-whynot.html
>3-- Is there any advantage in using ksh for
>scripting instead of csh?
Yes, it's just better...
>4--Should we forget about shells and go to perl?
If you want to stick with a shell, stick with pure bourne shell
syntax and enjoy being portable between sh, ksh, bash.
If you have the choice, go for Perl.
Wolfgang
--
Phone: (+49)-89-95720-110 Fax: (+49)-89-95720-112 w...@denx.muc.de
Office: (+49)-89-722-27328 Wolfga...@ICN.Siemens.DE
Technology is dominated by those who manage what they do not under-
stand.
Rev. Don Kool
Kind of mirrors my reason for using csh instead of sh.
Don
--
********************** You a bounty hunter?
* Rev. Don McDonald * Man's gotta earn a living.
* Baltimore, MD * Dying ain't much of a living, boy.
********************** "Outlaw Josey Wales"
http://members.home.net/oldno7
Rev. Don Kool
> We are having a discussion of the best
> shell for scripting and need more ideas.
>
> 1--Are there any security or other issues in
> using csh for scripting rather than korn shell?
Not really.
> 2-- Is there any advantage in using csh for
> scripting instead of ksh?
It makes more sense and is easier to learn/use.
> 3-- Is there any advantage in using ksh for
> scripting instead of csh?
Nope.
> 4--Should we forget about shells and go to perl?
Sure, if your goal is to raise the level of complexity.
Hope this helps,
Rev. Don Kool
> do...@mtlassen.central.sun.com (Doug Lenser) writes:
> >1--Are there any security or other issues in
> >using csh for scripting rather than korn shell?
>
> Yes, there are. Especially if you think about setuid csh scripts -
> you can delete your root password as well.
>
> >2-- Is there any advantage in using csh for
> >scripting instead of ksh?
>
> No, csh is broken and should *never* used to write scripts. See: "Csh
> Programming Considered Harmful", for instance at
> http://www.cs.ruu.nl/wais/html/na-faq/unix-faq-shell-csh-whynot.html
Please excuse my intemperate language but bull fucking shit. The
C-Shell works just fine despite what the unix-eratti may have
decided. Bourne and Korn blow chunks for an interactive shell and
any Admin that put either one of them in my "passwd" entry would
have to meet me in the alley out back. Now if you're going to use a
shell with some actual features (like "csh" or "tcsh") for
interactive use, it kind of makes sense to use the same one for
scripts. After all, you are pretty familiar with the syntax and a
script is just a file full of commands. When I pop an 8mm tape out
of the drive after a "cron" job did a backup for me, I want you to
explain how I have a "better" backup because it ran as a Bourne
shell script than as a C-Shell script. As far as I'm concerned the
only time all these overblown concerns about C-Shell scripting
become even remotely valid is when you're talking about SUID scripts
(which only an idiot would allow on his system) or when you're
really making an effort to program out into the outer fringes of
what the shell can do. I hate to disappoint the snobs in the
audience but I feel supremely confident running C-Shell scripts to
fire off backups or do an "rdate" or other bullshit, mundane
drudgery and I've done it without incident for well over a decade.
Telling me that C-Shell is "broken" is like telling me that nothing
but NIKEs will keep my feet dry.
Yours in Christ,
Rev. Don Kool
> >shell for scripting and need more ideas.
>
> >using csh for scripting rather than korn shell?
>
> anybody knowing the right tricks can totally circumvent security and
> gain whatever rights the script has. No version of csh has ever fixed
> this to the best of my knowledge.
<sigh> Where would we be without "urban legends".
> >2-- Is there any advantage in using csh for
> >scripting instead of ksh?
> A more C like scripting environment?
> >3-- Is there any advantage in using ksh for
> >scripting instead of csh?
> Too many to list. Lots of scripting features were added to ksh. Its
> not a complete programming language like perl, but it did alot of nice
> stuff.
However you seem unable to name one.
> >4--Should we forget about shells and go to perl?
> Sure, although perl has a pretty high overhead in memory and
> CPU. Watching a perl script go like majordomo on many many lists with
> many users is quite the maching humbling experience. Its probably the
> best optimized of the lot though, even though its syntax is a horrible
> jumble from so many different places.
Agreed. Totally overkill for most mundane applications.
Stefan Monnier
> do...@mtlassen.central.sun.com (Doug Lenser) writes:
>> 1--Are there any security or other issues in
>> using csh for scripting rather than korn shell?
> you can delete your root password as well.
No, there basically aren't any differences security-wise.
Any sensitive piece of code should be written in neither csh nor sh nor ksh.
>> 2-- Is there any advantage in using csh for
>> scripting instead of ksh?
> No, csh is broken and should *never* used to write scripts. See: "Csh
I agree, but it's not what he asked.
The main advantage is that most users know (t)csh (because it took way too
much time for sh-style shells to become interactive-friendly. Recent ksh
and bash are acceptable replacements for tcsh (tho not quite as featureful
in some respects) while zsh is probably the most advanced nowadays).
The `I know csh' argument is often irrelevant, tho, because most of the
language is not (or only rarely) used in interactive use. I must agree that
I ended up switching from tcsh to zsh mostly because I wanted to be able
to write the same loops interactively as in my scripts.
The string processing abilities of tcsh and bash are fairly different, so
in some cases you could also argue that tcsh makes it easier (while in others,
bash has the advantage).
Also, if you compare to the /bin/sh distributed with too many systems,
csh has the advantage of supporting arrays.
>> 3-- Is there any advantage in using ksh for
>> scripting instead of csh?
Last I looked, tcsh was still very poor at redirecting stderr and stdout
independently. Not a big deal, but annoying at times.
For me the big difference is that tcsh has no notion of a function. That
makes it very painful to write any serious script.
Also the $(cmd) form (aka `cmd`) is very handy and allows to keep your sanity
when you need to put quotes at too many places:
foo="this is mu$(echo "ch") better"
The latest ksh (as well as some not-yet-official versions of zsh) also have
added associative arrays which can be quite handy.
>> 4--Should we forget about shells and go to perl?
> If you want to stick with a shell, stick with pure bourne shell
> syntax and enjoy being portable between sh, ksh, bash.
But pure bourne shell is very primitive and has many limitations that would
make me almost prefer tcsh (lack of arrays for one).
> If you have the choice, go for Perl.
For anything substantial, Perl will indeed end up being the best choice.
Stefan
Rev. Don Kool
> >>>>> "Wolfgang" == Wolfgang Denk <w...@denx.muc.de> writes:
> > do...@mtlassen.central.sun.com (Doug Lenser) writes:
[...snip...]
> The string processing abilities of tcsh and bash are fairly different, so
> in some cases you could also argue that tcsh makes it easier (while in others,
> bash has the advantage).
> Also, if you compare to the /bin/sh distributed with too many systems,
> csh has the advantage of supporting arrays.
BINGO! I never will figure out how the "sh" faithful manage to
fool themselves into believing that manipulating file descriptors is
more important or more useful in general practice than supporting
arrays.
> >> 3-- Is there any advantage in using ksh for
> >> scripting instead of csh?
>
> Last I looked, tcsh was still very poor at redirecting stderr and stdout
> independently. Not a big deal, but annoying at times.
Exactly. A minor annoyance.
> For me the big difference is that tcsh has no notion of a function. That
> makes it very painful to write any serious script.
> Also the $(cmd) form (aka `cmd`) is very handy and allows to keep your sanity
> when you need to put quotes at too many places:
>
> foo="this is mu$(echo "ch") better"
>
> The latest ksh (as well as some not-yet-official versions of zsh) also have
> added associative arrays which can be quite handy.
>
> >> 4--Should we forget about shells and go to perl?
>
> > If you want to stick with a shell, stick with pure bourne shell
> > syntax and enjoy being portable between sh, ksh, bash.
>
> But pure bourne shell is very primitive and has many limitations that would
> make me almost prefer tcsh (lack of arrays for one).
And they told me that I was the only one who saw that....
> > If you have the choice, go for Perl.
>
> For anything substantial, Perl will indeed end up being the best choice.
Yup. For your basic bread and butter scripting, stick with a shell
that actually does what you need to do.
Hello Kittyhawk
Stefan Monnier <monnier+comp/unix/admin/news/@tequila.cs.yale.edu> wrote:
|
|> If you have the choice, go for Perl.
|
|For anything substantial, Perl will indeed end up being the best choice.
...or even the dreaded C monster, which has dragged
many a stout heart into the binary deeps...
--
,u, Bruce Becker Toronto, Ontario 1 416 699 1868
a \i\ Internet: b...@gts.org Uucp: ...!gts!bdb
`/o/-e "We congratulate you on your free elections and your
_\ >_ successful dengue-abatement campaign!" - W. Gibson
Bruce Barnett
> We are having a discussion of the best
> shell for scripting and need more ideas.
>
> 1--Are there any security or other issues in
> using csh for scripting rather than korn shell?
Do not use csh for setuid shell scripts ever.
On some systems (e.g. Solaris), you can have setuid-to-root shell
scripts, but CSH cannot do it safely.
>
> 2-- Is there any advantage in using csh for
> scripting instead of ksh?
Csh has a few minor advantages over sh for scripting, but ksh
has advantages over both.
The csh advantages over sh for shell scripting are
* In-line expansion of arguments (e.g. echo {a,b,c}{1,2,3} )
* Multiple word lists (like multiple arrays). You can also express
parts of a list easily.
* Some commands are built-in (basename, expr, test)
* It's easier to manipulate $PATH variables
* The built-in time command can provide useful information, if available.
The first is rarely useful. The second has a work-around, and the
third is a very minor advantage. I've tested some programs using csh with
built-in commands versus sh with external built-in commands. I was
surprised the sh script was faster.
The only other advantage is that some systems don't have ksh,
and the environment makes it hard to install new shells.
>
> 3-- Is there any advantage in using ksh for
> scripting instead of csh?
Yes. Many. These are the advantages sh has over csh.
(and ksh is a SUPERSET of sh)
1) Ad Hoc Parser - full of surprises/core dumps
2) Multiple-line quotes difficult - hard to include awk/sed scripts
3) Quoting can be confusing, inconsistent
4) if/while/for loops cannot use <
5) Limited file I/O redirection
6) Difficult to read a line at a time, and to choose `tty` vs. stdin
7) Signal management are not flexible, difficult to manage subprocesses
8) Fewer ways to test for missing variables
9) Can't pass spaces in arguments, spaces can disappear
10) No way to disable the field separator
11) Bigger and slower that sh
12) No functions - aliases are hard to make multiple-lines
These are the type of problems that can stop you "dead in the water."
Some CSH flaws have no work-arounds.
> 4--Should we forget about shells and go to perl?
I'd to that if the scripts were several pages long.
--
Bruce <barnett at crd. ge. com> (speaking as myself, and not a GE employee)
Bruce Barnett
> No, csh is broken and should *never* used to write scripts. See: "Csh
> Programming Considered Harmful", for instance at
> http://www.cs.ruu.nl/wais/html/na-faq/unix-faq-shell-csh-whynot.html
Nonsense. Please allow the user to decide for themselves.
I hate this condesending attitude. It's insulting to novices who use
the C shell, and alienates them from this newsgroup.
I use many shell languages, and if csh is the best for the job, I will
use it. Especally if I can do it in fewer characters, faster.
As yes, I am quite aware of the flaws of the C shell.
Never say never.
Casper H.S. Dik - Network Security Engineer
Bruce Barnett <see.my.add...@domain.com> writes:
>Nonsense. Please allow the user to decide for themselves.
>I hate this condesending attitude. It's insulting to novices who use
>the C shell, and alienates them from this newsgroup.
Yes, but experienced users shouldn't write C-shell scripts.
(So what hsould we train novices in? Wriring C-shell scripts?
I think not.)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Michael T Pins
>[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
>Bruce Barnett <see.my.add...@domain.com> writes:
>>Nonsense. Please allow the user to decide for themselves.
>>I hate this condesending attitude. It's insulting to novices who use
>>the C shell, and alienates them from this newsgroup.
>Yes, but experienced users shouldn't write C-shell scripts.
I've been using csh for nearly fifteen years now, but I wouldn't write
anything more complex than a one-off foreach script in it.
While it's a nice interactive shell, it has way too much brain-damage to
use as a shell scripting language.
>(So what hsould we train novices in? Wriring C-shell scripts?
>I think not.)
I don't think we should train novices in csh at all. When I started using
it there wasn't another decent shell available. Today, ksh does basically
everything csh does, and it's quoting and globbing actually make sense.
All my new users get ksh.
--
**************************************************************************
* Michael T Pins | mtp...@visi.com *
* keeper of the nn sources | mtp...@isca.uiowa.edu *
* ftp://ftp.visi.com/users/mtpins | #include <std.disclaimer> *
Bruce Barnett
> >Wolfgang Denk <w...@denx.muc.de> writes:
> >> No, csh is broken and should *never* used to write scripts. See: "Csh
> >> Programming Considered Harmful", for instance at
> >> http://www.cs.ruu.nl/wais/html/na-faq/unix-faq-shell-csh-whynot.html
> >
> >Nonsense. Please allow the user to decide for themselves.
>
> That's why he posted the http site.
The trouble is, Tom's document is not suitable for novices. It's
accurate, yes. But it's condesending, and overly complicated. Many
novices who read it simply shrug, and go away with the understanding
that the C shell is something that snobbish people make fun of, but
they don't understand exactly why. Let's examine his document, and
perhaps you can see what I mean:
Section 1:
He said the biggest problem is that you can't do
file-descriptor manipulation. As an example, he says:
"In the Bourne shell, you can open or dup arbitrary file
descriptors."
What novice wants to "dup" file descriptors, or wants to open/close
arbitrary ones? A novice barely understands the difference between
STDOUT and STDERR. In fact, the biggest problem most C shell users
have is discarding STDERR, which can be done with
(command >/dev/tty) >& /dev/null
He goes on to say:
The Bourne shell allows you to type
exec 3<file1
and switch between different file descriptors. How often do you see
this question asked? And how often do they want to close a FD?
Then he gives this example:
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;
Most people I know run away screaming right about now. He has just
scared away 90% of the potential audience.
Now let's go to Section 2. He mentions two nonsense examples:
time | echo
and
sleep 1 | while
So they don't work. Who cares? This guy is really reaching, they think.
He does give this example:
who | while read line; do
echo "gotta $line"
done
This is a problem, but it isn't the biggest one new users have. I
think it is serious, but you can split one shell into two scripts to
fix this problem. Then Tom mentions a bunch of bugs that are fixed on
my system. Yawn.
Section 3:
Signals - again an advanced topic. Most beginners don't use
signals. Most don't even understand them.
Example 4:
He complains about
set foo = "Bill asked, \"How's tricks?\"
but says sh works fine:
foo="Bill asked, \"How's tricks?\""
However, the beginner is more likely to use
foo='Bill asked, "How\'s tricks?"'
And that DOESN'T work in the Bourne shell. This is the big reason to
avoid the C shell? Hardly. So this is just sour grapes, they might
say. So far it isn't a convincing argument. Yes, you have to put a \
before a !. I can live with that, the beginner thinks.
Section 5:
He then talks about the C shell, and the different syntax between
regular and environment variables. He says you can't type
$SHELL:t
Well - who the heck WANTS to? He describes something that has a
work-around in the C shell.
Then he says:
% setenv TERM '`/bin/ls -l / > /dev/tty`'
% csh -f
Most people have heard of the joke "Doc! It hurts when I go like
this." Doc says "Don't go like this!" This is the same thing.
People read this, and shrug. Who cares? I don't plan to do this.
Section 6:
He complains about
if ($?MANPAGER) setenv PAGER $MANPAGER
Now on my system, it's documented in the manual page that you have to type:
if ($?MANPAGER) then
setenv PAGER $MANPAGER
endif
Tom then complains about
if ($?X && $X == 'foo') echo ok
because "it renders short-circuit booleans useless." This makes no
sense to the beginner. They think "What the heck is he talking about,
and what should I care?"
He then mentions the problem with spaces, and that you need a lot of
them in the C shell. Most C shell programmers learn this as a work-around.
Section 7: Error handling
Another minor point made.
I think Tom's document is fine for those experts who want an excuse to
flame C shell users. But as a document for novices, it's not very
useful. I just checked on a system at a random site I have access
too, and found that 257 users use CSH, 44 use TCSH, and 3 use KSH. I
will bet that 99 percent of them use the C shell for scripts. I will
also bet that few would change shells if they did read Tom's document.
The biggest trouble I have is the fact that c.u.s users don't seem to
understand that some people barely understand UNIX, and every concept
is a strugle. We always hear from the opinionated expert, but rarely
do we hear from an opinionated novice. And when someone who can barely
understand the issues asks a question, most tell him/her that they
should NEVER use the C shell, but few can say why, and fewer can do so
and still be helpful.
I can see it now:
Novice:
How do I do XYZ using the C shell?
Expert:
You shouldn't use the C shell. Use the Bourne shell.
Novice:
I try to, but I get syntax errors.
Expert:
That's because you are using the C shell. Use the Bourne shell.
Novice:
I've now using the Bourne shell. I'm getting syntax errors.
Expert: That's because you are using the C shell syntax. You must
learn a new language.
Novice:
That makes my brain hurt. The two shells are similar, but then
again, they are not. Okay. How to I create aliases
and do command-line editing in the Bourne shell?
Expert:
You can't. Use bash, or ksh.
Novice:
I don't have these shells on all of the systems I use.
What can I use?
Expert:
In that case, use the C shell for interactive use, and the
Bourne shell for scripts.
Novice:
I keep getting the syntax of the two shells confused.
And you told me I shouldn't use the C shell!
Expert:
Well, if you have to, you can use the C shell.
It's fine for interactive sessions.
But you shouldn't use it for scripts.
Novice:
I'm trying to customize my environment, and deal with
different searchpaths, terminals and systems. When I write a
Bourne shell script, fix the syntax errors, and execute it. It
doesn't change my environment.
Expert:
You can't easily change your environment from a shell script.
You have to use the "." command.
Novice:
Sigh. Syntax errors. I'd rather learn enough about the C
shell to get by.
Expert:
Well, it's your funeral. Look at
http://www.cs.ruu.nl/wais/html/na-faq/unix-faq-shell-csh-whynot.html
Novice:
I really don't understand half of what that document says.
And I don't care about the other half.
Now, how do I do XYZ using the C shell?
Another Expert:
You shouldn't be using the C shell. Use the Bourne shell.
Novice:
@#%&!
Now when a Novice has this experience, and then reads:
Resolved: The csh is a tool utterly inadequate for programming,
and its use for such purposes should be strictly banned!
And consider that Tom Christiansen's shell was TCSH at the time, how
do you expect that the C shell user feels?
Lawson Hanson
>We are having a discussion of the best
>shell for scripting and need more ideas.
Just to add my 2 cents worth: I think that the best choice of shell
for "scripting" is the Bourne shell (i.e.: the original) for several
reasons, which include:
1. ANY Unix machine you choose will have a version of the Bourne shell,
and the syntax will be virtually the same (so your script will
almost certainly run with little or no changes required),
2. The Bourne shell includes the ability to define shell function
(this is something that the C-shell does NOT have),
3. Shell scripts written to conform to the Bourne shell syntax will
also be able to run under the other popular Bourne-like shell,
such as the Korn Shell, and Bash (the Bourne Again Shell).
>1--Are there any security or other issues in
>using csh for scripting rather than korn shell?
If you are concerned about "security" issues, perhaps you should
consider using something other than a shell script.
>2--Is there any advantage in using csh for
>scripting instead of ksh?
Only if you are used to using the C-shell interactively to
run small looping programs, etc.; and some people like its
C-like syntax, but it does NOT permit shell functions.
>3--Is there any advantage in using ksh for
>scripting instead of csh?
Well for one thing, it allows you to define shell functions,
whereas in the C-shell the best you can do is define an alias,
but that, to my way of thinking, is not as flexible.
>4--Should we forget about shells and go to perl?
I still find it easier to write short scripts in the Bourne shell
language, whereas when I want to write a script which accesses
lots of files, or needs some arithmetic, or performs more system
type operations, then I find that Perl is the better choice.
Of course, if I want to present the user with a GUI front end,
then I use Tcl/Tk (sometimes calling Perl scripts, or shell scripts,
or compiled binaries from within the Tcl/Tk script to perform
whatever is required).
>What is the latest thought?
>thanks for your ideas.
>doug
>---
>Email: doug....@Sun.COM
I hope that may help your deliberations.
Best regards,
Lawson Hanson
Bruce Barnett
> Yes, but experienced users shouldn't write C-shell scripts.
I never said that. Over the last year in c.u.s I have discussed in
detail the shortcomings of the C shell more than anyone else.
Wolfgang said that the C shell should NEVER be
used. This is what I object too.
Pick one shell for someone who is using SunOS 4.1, Caspar, and who can't
compile/install a new shell. The only choices are csh and sh as I
recall. The systems here don't have ksh except for the one we installed.
If you pick sh, then the person will have a terrible interactive
environment. Surely you don't expect them to use sh as their
interactive shell?
If you pick csh, and the most complicated script that user will ever
write is their .login and .cshrc file, so what? Should we flame some
poor newbie because they ask a question about the C shell?
All they may want is a way to write a 6-line shell script, and they
don't want to spend a week learning a new shell language.
Their most complicated program might be a nested if condition.
And their lab partner knows the C shell, and only the C shell.
Some people never go beyond the bare minimum in scripting. They only
write programs for themselves, and not for customers. They don't know
AWK or SED, and don't care. Yes, eventually they might run into
problems. Perhaps. It might be tomorrow. Or it might be never.
I can't believe that there are people who will apparently say:
Yes, you *CAN* do that in 5 minutes with 6 lines of C shell,
but I won't tell you how. You should spend one week learning a
new shell language, because it is possible in a few months or
years you might run into a problem that will be difficult to
solve in the C shell.
I am tired of this attitude. I've seen it for 10 years in this
newsgroup. Pointing people to Tom's document is not going to fix the
problem the person above has. All they want is a solution, not flames.
Yes, they should eventually learn another shell IF THEY PLAN TO DO A
LOT OF SHELL PROGRAMMING. But let them pick the time and place to
change. Telling them to immediately stop programming in the C shell is
just being rude, and inconsiderate.
Stefan Monnier
> 1. ANY Unix machine you choose will have a version of the Bourne shell,
> and the syntax will be virtually the same (so your script will
> almost certainly run with little or no changes required),
No way. Each unix has a sightly different version of /bin/sh
(barring xpg4). If you really restrict yourself to the common denominator,
then it really sometimes feels like torture.
> 2. The Bourne shell includes the ability to define shell function
> (this is something that the C-shell does NOT have),
Shell functions were not in the original Bourne Shell AFAIK.
Now, maybe all vendors support functions in their /bin/sh, but I haven't
checked.
Stefan
Stefan Monnier
[ ... many very good points ... ]
> useful. I just checked on a system at a random site I have access
This is really the part that I don't understand: people keep screaming
against csh and then they make /bin/csh to default shell for their users.
csh is *the worst* login shell. If you want to be consistent with the
argumentation then use ksh, bash or zsh as the default login shell.
And if you don't care about self-consistency, then *at least* provide them
with tcsh.
Stefan "who's /bin/csh is a symlink to tcsh"
Charles Demas
Doug Lenser <do...@mtlassen.central.sun.com> wrote:
>
>We are having a discussion of the best
>shell for scripting and need more ideas.
>
>using csh for scripting rather than korn shell?
>
>scripting instead of ksh?
>
>3-- Is there any advantage in using ksh for
>scripting instead of csh?
>
>4--Should we forget about shells and go to perl?
>
>
>thanks for your ideas.
Best approach, IMO, is to ask the person you're working for. It
is he/she that you must please. Of course, you can give him/her
information about possible reasons for choosing one. Also, don't
ask unless you're prepared to accept and live with the answer. :-)
IMO, the most important thing in choosing a shell for scripting is
who you will ask for help and what they can/will support.
It will be of little solice that you are using a superior shell or
language if you cannot get your scripts/programs to work and everyone
you turn to is using something else.
Chuck Demas
Needham, Mass.
--
Eat Healthy | _ _ | Nothing would be done at all,
Stay Fit | @ @ | If a man waited to do it so well,
Die Anyway | v | That no one could find fault with it.
de...@tiac.net | \___/ | http://www.tiac.net/users/demas
Wolfgang Denk
>Wolfgang Denk <w...@denx.muc.de> writes:
>> No, csh is broken and should *never* used to write scripts. See: "Csh
>> Programming Considered Harmful", for instance at
>> http://www.cs.ruu.nl/wais/html/na-faq/unix-faq-shell-csh-whynot.html
>Nonsense. Please allow the user to decide for themselves.
Exactly. But especially a new user is well advised to read about the
shortcomings and pitfalls of a tool that - at first and unexperienced
look - _looks_ like an adequate tool for scripts.
>I hate this condesending attitude. It's insulting to novices who use
>the C shell, and alienates them from this newsgroup.
Anybody is free to ignore any advice given - good or bad. I go with
Terry Pratchett (_Equal Rites_):
They say a little knowledge is a dangerous thing,
but it is not one half so bad as a lot of ignorance.
>I use many shell languages, and if csh is the best for the job, I will
>use it. Especally if I can do it in fewer characters, faster.
May I bet that it's fewer characters and faster using Perl? :-)
>As yes, I am quite aware of the flaws of the C shell.
Well, This _makes_ for a difference. The average novice is not
immediately aware of these problems. Why let him walk or even lead
him into a cul-de-sac?
>Never say never.
I won't, never. :-)
Wolfgang
--
Phone: (+49)-89-95720-110 Fax: (+49)-89-95720-112 w...@denx.muc.de
Office: (+49)-89-722-27328 Wolfga...@ICN.Siemens.DE
The C-shell doesn't parse. It adhoculates.
- Caspe...@Holland.Sun.COM in <3ol96k$b...@engnews2.Eng.Sun.COM>
Mathew A. Hennessy
I'm quite fond of bash myself, and install it on all systems I
access, but I suppose learning ksh is like learning vi.. ;)
ps: How many variants besides AIX symlink ksh to sh?
--
Mathew A. Hennessy (henn...@thoughtcrime.com)
bleh.
Matthew Vernon
> >>>>> "Bruce" == Bruce Barnett <see.my.add...@domain.com> writes:
> [ ... many very good points ... ]
> > useful. I just checked on a system at a random site I have access
> > to, and found that 257 users use CSH, 44 use TCSH, and 3 use KSH. I
>
> This is really the part that I don't understand: people keep screaming
> against csh and then they make /bin/csh to default shell for their users.
> csh is *the worst* login shell. If you want to be consistent with the
> argumentation then use ksh, bash or zsh as the default login shell.
> And if you don't care about self-consistency, then *at least* provide them
> with tcsh.
FWIW bash is the default user shell on my system, except root who uses
sash.
I have yet to need to use the c shell, but then I don't do much shell
scripting.
Matthew
--
Elen Sila Lumenn' Omentielvo
Matthew Vernon, Steward of the Cambridge Tolkien Society
Selwyn College Computer support
http://pick.sel.cam.ac.uk http://www.cam.ac.uk/CambUniv/Societies/tolkien/
Roman Dieser
>
> We are having a discussion of the best
> shell for scripting and need more ideas.
>
> 1--Are there any security or other issues in
> using csh for scripting rather than korn shell?
>
> 2-- Is there any advantage in using csh for
> scripting instead of ksh?
>
> 3-- Is there any advantage in using ksh for
> scripting instead of csh?
>
> 4--Should we forget about shells and go to perl?
IMHO perl is the best choice for scripting.
But anyway even within a perl script sometimes
you need to interact with bash and/or csh.
>
> What is the latest thought?
> thanks for your ideas.
>
> doug
>
> ---
> Email: doug....@Sun.COM
--
Trachtet zuerst nach dem Reich Gottes...
John Doherty
<see.my.add...@domain.com> wrote:
[a lot of pretty good writing snipped]
| The biggest trouble I have is the fact that c.u.s users don't seem to
| understand that some people barely understand UNIX, and every concept
| is a strugle. We always hear from the opinionated expert, but rarely
| do we hear from an opinionated novice.
Well, I'm an opinionated novice, so I'll put in my two cents here.
Quick background: I'm self-taught unix user of about five years, now
responsible for a handful of machines that support about 80 users in
a typesetting company, and that also provide basic internet services,
etc.
When I started out, I used csh, because that was the default login
shell, I didn't know any better, and there was nobody around to offer
any advice. I eventually became reasonably proficient with it and even
sort of grew to like it.
I never wrote too much beyond a .login script with it, although I'm
sure I wrote a few csh scripts. Fairly early on, I was lucky enough
to pick up The UNIX Programming Environment [Kernighan and Pike], so
I became an sh-and-filters kind of guy. This continues to serve me
pretty well.
For a couple of years, I used csh interactively and sh for scripting.
The syntactical differences drove me nuts: it was actually my practice
for a long time to use csh as my login shell, but to switch to sh any
time I wanted a loop or test on the command line, just because I'd
written lots of loops and tests in sh scripts already and so I could
at least sometimes get them right the first time.
I really hated this, though, and sooner or later stumbled across the
fact that ksh was really a pretty good shell for scripting and had
enough features that it seemed at least conceivable that you could
use it interactively. I tried it, didn't like it, went back to csh,
still hated using different shells for scripting and interactive use,
tried ksh again, and stuck with it. I've been using it for about a
year and a half, I think, and I'm reasonably happy with it.
I do miss a few things about csh: in particular, I learned how to use
its history features pretty well and sort of miss them.
But overall, I wish I'd never heard of csh. The time I spent learning
how to use it now seems like time completely wasted. The very first
unix machine I ever had to deal with had ksh on it, and I really think
the vendor would have done me a better service by making it the default
user login shell.
I agree with your basic point, that users who ask "how do I do this with
csh?" really ought to get an answer that tells them how to do that with
csh (if it can be done, and if it can't, then pointing them at csh-whynot
is perfectly reasonable), but it really doesn't hurt much to point out
that they could probably spend time better by learning about better shells.
I wish there had been somebody to do that for me. Again, I think the time
I spent learning csh was completely wasted. If there had been someone
looking over my shoulder the first time I logged in to a unix machine
who noticed that my login shell was csh and switched it to ksh without
even bothering to explain what they'd done, I'd probably have been happier
in the long run.
So there's two cents (or more) from one opinionated novice.
Ken Wallis
> I'm quite fond of bash myself, and install it on all systems I
>access, but I suppose learning ksh is like learning vi.. ;)
What? A fundamental, life enriching, experience without which no human
being is complete? I like ksh, but not that much ;^)
>ps: How many variants besides AIX symlink ksh to sh?
I think the deal is that the POSIX shell is supposed to be called "sh", but
is also supposed to have everything ksh has, so those vendors who implement
it (IBM, HP at least) feel that they can support ksh by creating a link
instead of maintaining multiple executables.
A side effect of this is that root can easily have ksh functionality in its
login shell without any need for a complex /.profile (to check whether ksh
exists and exec it when appropriate). Clearly if ksh physically resides in
/usr root shouldn't be running it when the system is in single user mode and
/usr isn't mounted!
I personally find it interesting that the Solaris 2.6 AdminTool defaults all
the choices for user shells to "/bin/sh", "/bin/ksh", etc when /bin is
itself just a symlink to /usr/bin.
As for the question of which shell to use: my vote would be for ksh. Used
to be the only shell you could rely on platform to platform, site to site
was sh since some didn't have csh, but I can pretty much rely on finding ksh
on every box I come across now. Of course I don't work with SunOS 4.1
systems...
To my mind it is very important that you script in the same shell that you
use interactively. That way you can check syntax easily by trying simple
interactive examples, and you can save commands off your history stack as
scripts if you decide you might need them again. I use ksh interactively so
I script in ksh.
Just my 2 cents worth.
Best Regards,
Ken Wallis
Empower Data Solutions Pty Limited, ACN 079 955 196
Envision, enable, enhance... empower
Unix
<<eaten snipped or munched>
>
>4--Should we forget about shells and go to perl?
>
>
>thanks for your ideas.
>
>doug
old git in all others,p'raps we should also include REXX(sorry Big Blue,
Object Rexx) which for one reason or a.n.other The Big Blue Co at the
end (or near end) of the rainbow are giving away free?? for Linux at
least. I used to be a(an) VM/MVS/VTAM(whas tcp other than something you
gargle?) sysprog whose main thought about *u*x was that it was for
eunuchs, still each to 'is own as they say in the east end of London.
Mr Mike Cowlishaw(who? we're not worthy but he is on the same planet as
Mr Larry Wall) writ/wrote this as a scripting lang for the old M/F scene
very flexible IMHO and as good compared to PERL(again IMHO) but I am not
very used to either in the last 8 years, however being at risk of being
flamed I thought Oh so what lets add a.n.other variable into this saga.
When I grow up I wan't to be as old as the very Reverend Don or the very
Kool Gary no dis'pecked guys but oh well what TheF***.
all please feel free to substitute uck/ool/art for *** above
Also if you want a flame war see news.demon.ip.support.newuser to see
how it is in the good ole lickle ingland
Old is PC too ;-)> Drink Cider and be relieved!
--
Rob The World is My Oyster , Korn is my Shell
The Perl(sic) in the middle is Rexx!!
Thomas L|fgren
BB> I am tired of this attitude. I've seen it for 10 years in this
BB> newsgroup. Pointing people to Tom's document is not going to
BB> fix the problem the person above has. All they want is a
BB> solution, not flames.
The original poster was looking for differences between csh and ksh;
in particular he was asking for reasons for/against the use of each.
When pointing to Tom's document, we pointed to exactly (some of) those
reasons. He was not looking for a solution, but a comparison. Even
look at the subject line, and you'll see what it's about.
I agree, that if someone asked how to check for read permision on a
file in csh, it wouldn't be appropriate to give the same URL.
The fact is that csh isn't the best shell for shell scripting, and
where the poster asked for reasons, we pointed him to the FAQ. Is
there _anything_ wrong with that?
Tom
--
Wherever I lay my .emacs, that's my ${HOME}
Donn Cave
|> ps: How many variants besides AIX symlink ksh to sh?
|
| I think the deal is that the POSIX shell is supposed to be called "sh", but
| is also supposed to have everything ksh has, so those vendors who implement
| it (IBM, HP at least) feel that they can support ksh by creating a link
| instead of maintaining multiple executables.
Last time I looked at this, it appeared to me that HP/UX 10.20's POSIX
shell was derived from ksh, but wasn't the same shell. Digital UNIX's
/bin/posix/sh is the same inode as /bin/ksh, but at least the way we
install it, /bin/sh is different (half the size, for one thing.) Our
AIX /bin/ksh is same as /bin/sh (not a symbolic link, a hard link.)
It's a potential problem. I'm unable to check the HP version at the
moment, but I think they did the right thing and disabled ENV while
they were building their special version. If you want to run shell
scripts in an environment where some hosts are AIX, and you care enough
about reliability to worry about ENV, then the best thing I can think
of is to install a /bin/bsh link on the non-AIX hosts. (AIX /bin/bsh
is the traditional Bourne shell.)
Graham Broadbridge
> In article <8YC82.1651$764.6...@ptah.visi.com>,
> Michael T Pins <mtp...@visi.com> wrote:
>>All my new users get ksh.
> ps: How many variants besides AIX symlink ksh to sh?
IBS only started doing this with AIX4 or later (and it's a hard link not
a soft link).
AIX still provides a pure bourne shell as /bin/bsh (believe it or not).
--
Graham Broadbridge Home <gra...@peachy.apana.org.au>
Marsfield NSW Australia Work <gra...@ins.unilink.oz.au>
Australia AmprNet <vk2...@gw.vk2yui.ampr.org>
<vk2...@amsat.org>
Friedrich Dominicus
Shell-Script you probably find more often.
And I thinkg here all the sh derivatives are in front
there are sh, bash, ksh, zsh
but for C there are just two
csh and tcsh AFAIK
I don't know if it's really true that csh-programming is a pain. I never
have it. And after a while of using bash I switched ot zsh and of
course, I like this shell most of them all.
If you like to have a C-like syntax (or a C-Interpterter) then try
ch. It's a shell (not very comfortable IMO) but you can do C-Programming
with it.
>
> 4--Should we forget about shells and go to perl?
It depend on what you're going to do. If you like C-Syntax than maybe
Perl is a good choice, if you don't like it, it's a poor one.
If you try to decide what Scripting-language to use. Then you should
consider more than Perl. My favourite would be Python here. But you have
the choice:
1) Perl
2) Python; http://www.python.org
3) Scheme (If you work with Emacs maybe that's a good choice)
4) Ruby
5) REXX
6) OREXX
7) Tcl/Tk
...
more and more and more
Take a look at:
http://www.rhein-neckar.de/~cetus/software.html
for some more languages.
Don't know if that is helpful, but I hope so
regards
Friedrich
Bruce Barnett
> >2--Is there any advantage in using csh for
> >scripting instead of ksh?
>
> Only if you are used to using the C-shell interactively to
> run small looping programs, etc.; and some people like its
> C-like syntax, but it does NOT permit shell functions.
There are three problems with the C shell in this respect.
The if/while loops cannot be redirected, to get input from a pipe or a
here-is document. As a work-around, you can use multiple scripts.
Second - the C shell doesn't have the ability to read one line at a
time. This can be very hard to work around.
Third - the C shell has a command to get input from the terminal. And
ONLY from the terminal. The "set ans = $<" construct ought to get
input from standard input, which may be a terminal or a pipe.
Instead, it is ALWAYS a terminal, even if you don't have one, or want
one. It's one of these things that allows you to write a script, but
if you want to run the interactive script in batch mode, you
CANNOT. The Bourne shell allows you to do it either way.
Bruce Barnett
> The fact is that csh isn't the best shell for shell scripting, and
> where the poster asked for reasons, we pointed him to the FAQ. Is
> there _anything_ wrong with that?
There is a BIG difference between
"The C shell isn't the best for shell scripting"
and
"Never use the C shell for writing scripts"
As I recall, he says the usage of the C shell should be banned. This
attitude alienates those that need help. THAT is what I object too.
Tom Keats
>
> We are having a discussion of the best
> shell for scripting and need more ideas.
>
> 1--Are there any security or other issues in
> using csh for scripting rather than korn shell?
>
> 2-- Is there any advantage in using csh for
> scripting instead of ksh?
>
> 3-- Is there any advantage in using ksh for
> scripting instead of csh?
>
> 4--Should we forget about shells and go to perl?
>
> What is the latest thought?
> thanks for your ideas.
>
> doug
>
> ---
> Email: doug....@Sun.COM
There are reasons to use shells.
Security isn't one of them.
Avoid _any_ shell script for progs
requiring security ---
especially anything requiring root
access.
Where shell scripts *are* appropriate,
i've never seen
anything where ksh really has anything
over sh.
Arrays? They can be "faked" in sh using
the jot utility
and a loop and somewhat artistic
variable assignments.
sh is more "universal" than ksh or csh
or zsh. Of course,
jot is even less universal than ksh.
One thing ksh has over sh, tho', is
interactive (or
at least verbose) debugging.
On the interactive side, tcsh is great
...
_if_ you're used to emacs ---
tcsh uses emacs-y command-line syntax.
This is actually an important point to
using tcsh as
a command-line shell (the devil you
*know* <grin>.)
It's often fun to do a foreach loop on
the
tcsh command-line to "educate" folks who
think
shell scripts are nothing more than DOS
batch files.
Personal Opinion:
Everytime I try writing something in
PERL it always
ends up in C anyway.
cheers,
tom keats
Rev. Don Kool
> I am tired of this attitude. I've seen it for 10 years in this
> newsgroup. Pointing people to Tom's document is not going to fix the
> problem the person above has. All they want is a solution, not flames.
>
> Yes, they should eventually learn another shell IF THEY PLAN TO DO A
> LOT OF SHELL PROGRAMMING. But let them pick the time and place to
> change. Telling them to immediately stop programming in the C shell is
> just being rude, and inconsiderate.
Amen, to that!
Yours in Christ,
Don
--
********************** You a bounty hunter?
* Rev. Don McDonald * Man's gotta earn a living.
* Baltimore, MD * Dying ain't much of a living, boy.
********************** "Outlaw Josey Wales"
http://members.home.net/oldno7
Dr. Michael Albert
I was wondering if this would be a good time to mention my favorite
csh bug. This occurs of Solaris2.5, so I'm not sure if I'm seeing
something particular to Solaris.
Suppose I want to run a program out of inittab, but I want to run
as a user other than root, and I want to redirect stdout and stderr.
For a user of "sh", I can do
xx:34:respawn:su - shuser -c "exec program > programLog 2>&1"
For csh I would be tempted to do:
########ALERT: BAD EXAMPLE################
xx:34:respawn:su - cshuser -c "exec program >>& programLog"
but playing with truss showed that as a result of this, instead of having
programLog open on fd's 1 and 2, it is open on 0 an 1 !!!
If I do this:
xx:34:respawn:su - cshuser -c "exec program < /dev/null >>& programLog"
things work as expected.
Ok, should this have been obvious to me? Am I missing something?
Thanks.
-Mike
Mathew A. Hennessy
>>access, but I suppose learning ksh is like learning vi.. ;)
>
>
>What? A fundamental, life enriching, experience without which no human
>being is complete? I like ksh, but not that much ;^)
I agree.. That would be Perl.. ;)
>To my mind it is very important that you script in the same shell that you
>use interactively. That way you can check syntax easily by trying simple
>interactive examples, and you can save commands off your history stack as
>scripts if you decide you might need them again. I use ksh interactively so
>I script in ksh.
Yes, but bash has a few neat features which I prefer
interactively.. My habits:
o command line scripts ('find / -print|while read FILE'- style)
are in bash, and I rarely conflict with ksh-semantics.
o widely-distributed scripts, or trivial scripts are in /bin/ksh
o anything larger than simple file manipulation is Perl
Granted, there may be (and have been) bits which are not quite
compatible, the trouble is offset (for me, anyways) by the countless
keystrokes saved thanks to bash's tab-completion ;)
Cheers,
Icarus Sparry
Well, it is by no means obvious. I can give a good piece of reasoning
about why it happens thou.
There are 2 system calls for manipulating file descriptors, called
'dup' and 'dup2'. 'dup' is the older one, it takes one integer (a file
descriptor) and makes a copy onto THE LOWEST AVAILABLE one (which it
returns). So if you ASSUME that file descriptors 0, 1 and 2 are open,
you can do redirection to a file by
open(filename,mode) (which returns an int, say 5)
close(1) (don't bother to check if this works)
dup(5) (will return 1, so don't bother to check)
close(5)
but if file descriptor 0 is closed, then the 'dup' will dup onto fd
0! Given redirections are done left to right, and programs spawned by
inittab start without any open file descriptors I suspect that this
explains everything that you have seen if you assume that csh uses 'dup'.
On the other hand, 'dup2' takes two arguments, which are used to specify
exactly which file descriptors are involved.
Icarus
Donn Cave
| The fact is that csh isn't the best shell for shell scripting, and
| where the poster asked for reasons, we pointed him to the FAQ. Is
| there _anything_ wrong with that?
The way I read Bruce Barnett's post, his essential point was that
it's not a very good FAQ. It's a diatribe, and its technical focus
is a poor fit with the target audience.
I agree with you, there's a general concensus that csh isn't the
best shell for programs. The ``Why not'' article helped forge that
concensus, and the way I see it, it has served its purpose. Maybe
it's time for this community to produce a real FAQ?
Wouldn't need to be a lengthy document - I think five or six well
explained reasons ought to be enough, and certainly better than
a 20 questionable ones. Mr. Barnett appears to have an informed
perspective on the matter, maybe he'd be willing to draft something?
Donn Cave, University Computing Services, University of Washington
do...@u.washington.edu
Reinier Post
>We are having a discussion of the best
>shell for scripting and need more ideas.
I use /bin/sh for simple things (below 20 lines or so).
I try to stay away from any features that might be specific
to the /bin/sh I happen to be using.
>1--Are there any security or other issues in
>using csh for scripting rather than korn shell?
Not that I know of.
>2-- Is there any advantage in using csh for
>scripting instead of ksh?
Well, it's nice to have a single shell for both scripting and
interactive use. If you find this important, use ksh or bash.
>3-- Is there any advantage in using ksh for
>scripting instead of csh?
Never use csh, it's not orthogonal. It appears to do I/O redirection,
pipes, subroutine definitions, flow control statements (while, if) but
they break down as soon as you try to mix them. In /bin/sh, they don't.
/bin/sh just has ugly syntax; /bin/csh is ugly all the way through.
See Tom Christiansen's csh-whynot, referred to in another posting.
>4--Should we forget about shells and go to perl?
For anything that is likely to grow beyond 20 lines, do. /bin/sh
syntax (spacing, quoting) remains awkward, especially when you're
calling many different auxiliary programs to do small jobs that sh
cannot handle by itself. This also makes it slow to execute.
Solutions such as ksh or awk, less powerful than Perl, are a waste of
effort, if you can learn/use Perl just as easily.
>doug
Try comp.unix.shell and comp.lang.perl.* for more info.
[Newsgroups: line limited to comp.unix.shell]
--
Reinier Post rein...@win.tue.nl
(who uses sh for scripting, tcsh interactively)
Chris Waters
> There is a BIG difference between
> "The C shell isn't the best for shell scripting"
> and
> "Never use the C shell for writing scripts"
Yes, there is. The former is so weak as to be almost criminal! The
latter is only a *little* too weak (it still allows recommending csh
for interactive use, which is evil).
> As I recall, he says the usage of the C shell should be banned.
Who says? We in the Committee to Ban CSH are always looking for new
members. :-)
--
Chris Waters |
cwa...@systems.DHL.COM | Or, in other words, I couldn't fail not to
xt...@dsp.net (personal) | disagree with you less.
www.dsp.net/xtifr/ (web) |
Bruce Barnett
> Wouldn't need to be a lengthy document - I think five or six well
> explained reasons ought to be enough, and certainly better than
> a 20 questionable ones. Mr. Barnett appears to have an informed
> perspective on the matter, maybe he'd be willing to draft something?
I am willing, but my time is short this month. I have already listed
some of the major problems of the C shell. My list is in the order of
problems a new user would typically face, instead of the order of
Tom's document, which isn't (IMHO) novice friendly. I'll try to fill this
out during the holidays, and give some examples suitable for
beginners. I think with help from others to add things I have omited,
we can do a credible job, without alienating C shell users.
Top 12 reasons not to use the C shell:
1) Ad Hoc Parser - full of surprises/core dumps
2) Multiple-line quotes difficult - hard to include awk/sed scripts
3) Quoting can be confusing, inconsistent
4) if/while/for loops cannot use <
5) Limited file I/O redirection
6) Difficult to read a line at a time, and to choose `tty` vs. stdin
7) Signal management are not flexible, difficult to manage subprocesses
8) Fewer ways to test for missing variables
9) Can't pass spaces in arguments, spaces can disappear
10) No way to disable the field separator
11) Bigger and slower that sh
12) No functions - aliases are hard to make multiple-lines
Keith Bennett
hi,
okay, well i know everybody's about to jump on me bu here goes
with my brain-dead question:
using bash (and presumably awk or something) how do i remove
to consecutive lines from a file?
ie. match on the first line with a regexp /^foo/ and
remove it, then remove the following line also and save
the remaining text (in it's original order) into a new file.
thanks in advance.
keith.
============================================================================
Keith Bennett Tel: 01334 463731
Mathematics Institute Fax: 01334 463748
University of St.Andrews, mailto:ke...@dcs.st-and.ac.uk
St.Andrews, Fife KY16 9SS
SCOTLAND http://www-solar.dcs.st-and.ac.uk/~keith
============================================================================
John Beppu
Keith Bennett <ke...@dcs.st-and.ac.uk> wrote:
>hi,
>
>okay, well i know everybody's about to jump on me bu here goes
>with my brain-dead question:
>
>using bash (and presumably awk or something) how do i remove
>to consecutive lines from a file?
>
>ie. match on the first line with a regexp /^foo/ and
>remove it, then remove the following line also and save
>the remaining text (in it's original order) into a new file.
>
>thanks in advance.
>
>keith.
>
The technique I use involves using sed(1).
sed '/^foo/,/.*/d'
In English, that means to find a line matching ^foo, then
find a line matching anything (which will inevitably be
the next line), and then delete them.
If you want to do more than two lines, I don't know. Use
Perl, maybe ;-).
--
/** be...@uci.edu ......................................................... */
bo...@babinga.dms.state.us
> [[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
> Bruce Barnett <see.my.add...@domain.com> writes:
>>Nonsense. Please allow the user to decide for themselves.
>>I hate this condesending attitude. It's insulting to novices who use
>>the C shell, and alienates them from this newsgroup.
> Yes, but experienced users shouldn't write C-shell scripts.
Experienced users should write their scripts in whatever allows
them to accomplish their task quickly and efficiently. If a
10 line csh script is what does that and that is what they are
comfortable with that's fine. The attitude of "You shouldn't
do that because I don't think you should" is a very MS-ish
attitude. You are not in a position to decide what is best for
everyone else. If you want to never do csh, that's fine, however
if my shell script is not a trivial csh script I will jump to
Perl, TCL, or C, depending on what is the best fit.
And yes, I can write scripts in ksh/sh/bash/... If it requires
the extra capabilities those shells have I am almost always better
off going to Perl or TCL.
Roger
Charles Demas
Keith Bennett <ke...@dcs.st-and.ac.uk> wrote:
>
>hi,
>
>okay, well i know everybody's about to jump on me bu here goes
>with my brain-dead question:
>
>using bash (and presumably awk or something) how do i remove
>to consecutive lines from a file?
>
>ie. match on the first line with a regexp /^foo/ and
>remove it, then remove the following line also and save
>the remaining text (in it's original order) into a new file.
awk '(/^foo/ && f==0) || f==1 {f++;next} {print}' infile > outfile
Will do the job with awk.
The f==0 part is to only skip the first foo. :-)
Chuck Demas
Needham, Mass.
--
Eat Healthy | _ _ | Nothing would be done at all,
Stay Fit | @ @ | If a man waited to do it so well,
Die Anyway | v | That no one could find fault with it.
de...@tiac.net | \___/ | http://www.tiac.net/users/demas
Charles Demas
John Beppu <be...@rigel.oac.uci.edu> wrote:
>In article <Pine.OSF.4.05.9812012143410.30096-100000@tennents>,
>Keith Bennett <ke...@dcs.st-and.ac.uk> wrote:
>
>>hi,
>>
>>okay, well i know everybody's about to jump on me bu here goes
>>with my brain-dead question:
>>
>>using bash (and presumably awk or something) how do i remove
>>to consecutive lines from a file?
>>
>>ie. match on the first line with a regexp /^foo/ and
>>remove it, then remove the following line also and save
>>the remaining text (in it's original order) into a new file.
>>
>>
>>keith.
>>
>
>
> The technique I use involves using sed(1).
>
> sed '/^foo/,/.*/d'
>
> In English, that means to find a line matching ^foo, then
> find a line matching anything (which will inevitably be
> the next line), and then delete them.
>
> If you want to do more than two lines, I don't know. Use
> Perl, maybe ;-).
Unfortunately, it will also delete subsequent occurances of foo and its
following line.
Consider the effect of your code on this file:
The first
foo 1
line 1
line 2
foo 2
line 3
line 4
FWIW, this does the job requested with awk:
awk '(/^foo/ && f==0) || f==1 {f++;next} {print}' infile
Jeremy Isserlis
portability and functionality.
I have been using various UNIXes for at least 12 years. At the very
beginning I was warned of csh's problems and the advisability of using
Bourne shell for scripting. Experience since has simply confirmed this.
Korn Shell (including the Posix shell, which is a different program from
Bourne shell on HP-UX 10.20 and 11 by the way) seems to me to be rather
good, including functions, long integer arithmetic, arrays, emacs or vi
history editing and so on. It makes sense to use the same shell for both
scripts and interactive work, especially if one enjoys quick "inline"
scripts. Ksh functions can even be defined for use in the interactive
environment; hence one may define one's own cd command for instance. For
those who have to struggle with NT as well, various Korn shells are
available for that too.
Perl is good; I am not convinced that it is THAT good as its syntax
seems to lead many of its users into competitions for the most obscure
code. Again, I use it where I can be sure that Perl will be installed and
on NT my first task is always to install Perl, finding that Perl scripts
generally run 90% unchanged on both NT and UNIX. But it can be rather
heavyweight for the majority of daily scripting tasks, installation
packages, cron jobs etc.. Of course, other than Perl, the sine qua non is
awk: brilliant and simple. Scripting will require:
a shell language, e.g. ksh, sh
ancilliary tools e.g awk, sed, tr, pr, mail, find, make, nroff, tbl,
expr, bc,
date, egrep ...
comments in your code
simplicity, assuming the least and clarity
the ability to type "man ..." and understand the results.
Perl has a most of the ancilliary tools within it, plus enough libraries
etc. to enable remarkably complex programming akin to C. But for most work
and portability, a Bourne shell plus the usual UNIX tools should be highly
satisfactory.
Rev. Don Kool
> Bruce Barnett <see.my.add...@domain.com> writes:
> > There is a BIG difference between
>
> > "The C shell isn't the best for shell scripting"
> > and
> > "Never use the C shell for writing scripts"
>
> Yes, there is. The former is so weak as to be almost criminal! The
> latter is only a *little* too weak (it still allows recommending csh
> for interactive use, which is evil).
>
> > As I recall, he says the usage of the C shell should be banned.
>
> Who says? We in the Committee to Ban CSH are always looking for new
> members. :-)
Translation: any UNIX command/construct/shell/technique/etc. that
isn't arcane, torturous, forbidding to novices, counterintuative,
unavailable through a GUI or doesn't use twisted syntax doesn't
validate my self-worth or make me feel 'special' for having learned
it.
Hope this helps,
Wolfgang Denk
>gbur...@databasix.com (Gary L. Burnore) writes:
>STDOUT and STDERR. In fact, the biggest problem most C shell users
>have is discarding STDERR, which can be done with
If this is true, most C shell scripts are even worse than I thought.
Ignoring error messages? Not checking for error codes? Letting the
user think everything went fine only to find out later that
_omewhere_ _something_ whent wrong, without any hint what or why?
Eeek!
>and switch between different file descriptors. How often do you see
>this question asked? And how often do they want to close a FD?
First question: every month or so?
Second question: evey second day or so...
>Then he gives this example:
> 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;
>Most people I know run away screaming right about now. He has just
>scared away 90% of the potential audience.
Seems you know the wrong people. He presented a (complicated, yes)
solution for a non-trivial problem. See how it's working, understand
the magic and capabilities of this approach. Don't run away from new
ideas or a level of complexity you didn't try before. How else do you
think to learn more complicated things? A good example is worth a
thousand postings :-)
>Now let's go to Section 2. He mentions two nonsense examples:
> time | echo
>and
> sleep 1 | while
>So they don't work. Who cares? This guy is really reaching, they think.
TYhese are examples for a general design flaw in the csh. Ane newbee
trying such a thing will go crazy trying to figure out _why_ this
does not work. And he is right to expect this working; his only error
is to use a broken shell.
>He does give this example:
> who | while read line; do
> echo "gotta $line"
> done
>This is a problem, but it isn't the biggest one new users have. I
No, not the biggest, but an unnecessary one, and caused by a bug in
the csh.
>Section 3:
> Signals - again an advanced topic. Most beginners don't use
> signals. Most don't even understand them.
So what is your suggestion? Let beginners start going with csh, only
to find out that they will have to switch to a decent shell just
because they are trying to do some non-beginner things?
Can you really recommend this to anyone???
>Section 5:
>He then talks about the C shell, and the different syntax between
>regular and environment variables. He says you can't type
> $SHELL:t
>Well - who the heck WANTS to? He describes something that has a
Maybe someone who has left the beginner state a few days behind?
>work-around in the C shell.
>Then he says:
> % setenv TERM '`/bin/ls -l / > /dev/tty`'
> % csh -f
>Most people have heard of the joke "Doc! It hurts when I go like
>this." Doc says "Don't go like this!" This is the same thing.
>People read this, and shrug. Who cares? I don't plan to do this.
You don't plan to use it, until someday one of your C shell scripts
starts behaving in a funny way, and you have hard times figuring out
why. If you can login at all when your login C shell goes crazy.
>Tom then complains about
> if ($?X && $X == 'foo') echo ok
>because "it renders short-circuit booleans useless." This makes no
>sense to the beginner. They think "What the heck is he talking about,
>and what should I care?"
So you simply ignore everything you don't know?
Great. I hope you are not responsible for - say - the security of
your systems. I can hear you: "Never heard of syn cookies? What good
are they for? I don't plan to use them... Never heard of SSH and
one-time passwords? What good are they for? Why not use my good old
root passwort of "toor" for another five years?" etc.
Go on...
>He then mentions the problem with spaces, and that you need a lot of
>them in the C shell. Most C shell programmers learn this as a work-around.
Hell! Why learn workarounds just to use a buggy program, when there
are free alternatives without all those bugs???
>useful. I just checked on a system at a random site I have access
>too, and found that 257 users use CSH, 44 use TCSH, and 3 use KSH. I
>will bet that 99 percent of them use the C shell for scripts. I will
>also bet that few would change shells if they did read Tom's document.
You probably did not check in a software developers environment? Make
a poll among professionals which shell they use for _scripts_. And
don't bet on an assumption just based on which interactive shell they
are using.
>The biggest trouble I have is the fact that c.u.s users don't seem to
>understand that some people barely understand UNIX, and every concept
>is a strugle. We always hear from the opinionated expert, but rarely
That's why we try to help and to explain. Even when you have to learn
that there are people with other opinions than yours. Or another
level of experience. Is it bad to listen to an expert? Tom C.
definitely is one.
>do we hear from an opinionated novice. And when someone who can barely
>understand the issues asks a question, most tell him/her that they
>should NEVER use the C shell, but few can say why, and fewer can do so
At least NEVER for _scripts_, remember this small, but important detail.
>Novice:
> I don't have these shells on all of the systems I use.
> What can I use?
>Expert:
> In that case, use the C shell for interactive use, and the
> Bourne shell for scripts.
C'me on? Which system does _not_ have a ksh or bash?
...
>Now when a Novice has this experience, and then reads:
>Resolved: The csh is a tool utterly inadequate for programming,
> and its use for such purposes should be strictly banned!
>And consider that Tom Christiansen's shell was TCSH at the time, how
>do you expect that the C shell user feels?
Well, I would feel that an expert has spoken. Maybe I don't under-
stand everything he said, but this does not make me question his
competence. Yes, he knows the innards of the csh very well. Now, when
even with his superior knowledge he comes to this conclusion - should
I ignore it? Or accept that there are things that I still have to
learn? Can I accept good advice from someone more advanced than
myself?
Some people can't. I always try to learn new things. It's fun at
least.
[And yes, I have been using the csh, too. Long back ago on BSD 2.9
and BSD 4.1 systems where it was the only shell with job control. I
_do_ know why I switched to another shell as soon as they became
available...]
Wolfgang
--
Phone: (+49)-89-95720-110 Fax: (+49)-89-95720-112 w...@denx.muc.de
Office: (+49)-89-722-27328 Wolfga...@ICN.Siemens.DE
Philosophy: A route of many roads leading from nowhere to nothing.
- Ambrose Bierce
Dan Mercer
Tom Keats <tom_...@bc.sympatico.ca> writes:
> Doug Lenser wrote:
>>
>> We are having a discussion of the best
>
>> shell for scripting and need more ideas.
>>
>> using csh for scripting rather than korn shell?
>>
>> scripting instead of ksh?
>>
>> scripting instead of csh?
>>
>>
>> thanks for your ideas.
>>
>> doug
>>
>> ---
>> Email: doug....@Sun.COM
>
> There are reasons to use shells.
> Security isn't one of them.
>
> Avoid _any_ shell script for progs
> requiring security ---
> especially anything requiring root
> access.
>
> Where shell scripts *are* appropriate,
> i've never seen
> anything where ksh really has anything
> over sh.
typeset allows:
functions to have local variables
variables to have specific attributes (upper/lowercase, integer,
left and right justification.
aliases:
combined with functions, allows you to modify the behaviour of
"cd", for instance.
conditional expressions:
don't require variables to be quoted;
has time based comparison operators "-nt" and "-ot";
ownership based comparison operator "-O";
string collation operators "<" and ">"
far more powerful than test expressions, combined with
the expanded
Pattern Matching Notation:
if [[ $var = !(pat1|pat2|...) ]]
which is true as long as $var does not match any of the patterns
(pat1, pat2, etc) in the expression. Since Patterns are nestable,
you can not only create expressions with the power of regular
expressions, but often more powerful. Pattern Matching Notation
can also be used with Parameter Substitution (${var%%pattern})
to allow string editing.
Arithmetic Operations:
using let or by implicit actions. If x is defined as an integer,
then the following are equivalent:
let x = x + 1
((x += 1))
x=x+1
So, for instance, after using getopts, to shift off the
operators:
shift OPTIND-1
Coprocesses:
let's you set up interactive, two way communications with
another process, for instance, bc.
Of course, there's a lot, lot more. Anyone who finds they
can do what they want as easily in Bourne as ksh either doesn't
really know ksh or isn't rying anything too demanding.
> Arrays? They can be "faked" in sh using the jot utility and a
> loop and somewhat artistic variable assignments. sh is more
> "universal" than ksh or csh or zsh. Of course, jot is even less
> universal than ksh.
Are jot arrays sortable?
>
> One thing ksh has over sh, tho', is interactive (or at least
> verbose) debugging.
>
> On the interactive side, tcsh is great ... _if_ you're used to
> emacs --- tcsh uses emacs-y command-line syntax. This is
> actually an important point to using tcsh as a command-line shell
> (the devil you *know* <grin>.)
>
> It's often fun to do a foreach loop on the tcsh command-line to
> "educate" folks who think shell scripts are nothing more than DOS
> batch files.
>
> Personal Opinion:
> Everytime I try writing something in
> PERL it always
> ends up in C anyway.
>
> cheers,
> tom keats
Opinions expressed herein are my own and may not represent those of my employer.
Donn Cave
... [re Beginner's reaction to ``why not'']
| Well, I would feel that an expert has spoken. Maybe I don't under-
| stand everything he said, but this does not make me question his
| competence. Yes, he knows the innards of the csh very well. Now, when
| even with his superior knowledge he comes to this conclusion - should
| I ignore it? Or accept that there are things that I still have to
| learn? Can I accept good advice from someone more advanced than
| myself?
For sure, some people do take it this way and profit from it. But
that posture (``... with his superior knowledge ... '') is not common
in the computing world, where every teenage UNIX beginner wants to
think of him/herself a wizard after the first 4 weeks. Much more
common is the entrenched defensive posture when one's choices are
questioned, which we are certainly seeing here.
If the point is to enlighten, then we want more light, and less heat.
For me, ``why not'' could be improved on in both respects.
My pet peeves with csh:
- Quoted command substitution yields one parameter per line of output,
instead of one parameter for the whole quoted expression.
- Aliases with parameters are bizarre and difficult compared to functions
(i.e., csh for interactive use isn't that attractive either.)
- If you want something that looks like C you sure don't get it here.
(Better look up "rc", a superior programming shell by the way:
ftp://ftp.sys.utoronto.ca/pub/rc/ )
Bruce Barnett
> Bruce Barnett <see.my.add...@domain.com> writes:
>
> >STDOUT and STDERR. In fact, the biggest problem most C shell users
> >have is discarding STDERR, which can be done with
>
> If this is true, most C shell scripts are even worse than I thought.
> Ignoring error messages? Not checking for error codes?
You don't understand. One of the problems C shell users have is
how to purposely discard STDERR information. It's a problem because
there is no obvious way to do this. Therefore they ask this newsgroup.
> >and switch between different file descriptors. How often do you see
> >this question asked? And how often do they want to close a FD?
>
> First question: every month or so?
> Second question: evey second day or so...
Please.
I've never seen a C shell users ask either question in this newsgroup.
Bourne shell users rarely ask it either. Check for <&- and >&- in the
script archives, and see how many use it. Most simply
redirect to /dev/null when they need to.
> >Most people I know run away screaming right about now. He has just
> >scared away 90% of the potential audience.
>
> Seems you know the wrong people.
First you insult the people I know...
> So you simply ignore everything you don't know?
and then you insult me personally. No wonder people don't ask for help
on this newsgroup with experts that have similar attitudes.
> You probably did not check in a software developers environment? Make
> a poll among professionals which shell they use for _scripts_. And
> don't bet on an assumption just based on which interactive shell they
> are using.
Sorry. I only checked at a large Research facility with more than a
1000 PhD's. I guess they aren't professional enough for you.
> C'me on? Which system does _not_ have a ksh or bash?
SunOS 4.X for one. We have thousands of UNIX systems here, and some
systems still have this OS.
Thank you for illustrating my point so well.
Chris Waters
> Chris Waters wrote:
> > Bruce Barnett <see.my.add...@domain.com> writes:
>
> > > There is a BIG difference between
> >
> > > "The C shell isn't the best for shell scripting"
> > > and
> > > "Never use the C shell for writing scripts"
> >
> > Yes, there is. The former is so weak as to be almost criminal! The
> > latter is only a *little* too weak (it still allows recommending csh
> > for interactive use, which is evil).
> >
> > > As I recall, he says the usage of the C shell should be banned.
> >
> > Who says? We in the Committee to Ban CSH are always looking for new
> > members. :-)
>
> Translation: any UNIX command/construct/shell/technique/etc. that
> isn't arcane, torturous, forbidding to novices, counterintuative,
> unavailable through a GUI or doesn't use twisted syntax doesn't
> validate my self-worth or make me feel 'special' for having learned
> it.
Beg pardon? I have no objections to simple and/or GUI-based options.
I have no objections to visual basic or tcl/tk. OTOH, if someone
prefers perl or lisp, I don't object to that either. I don't even get
involved in editor wars -- both emacs and vi are fine programs IMO,
and I can recommend simpler editors for novices.
My opinion is *simply* that csh is evil and should be banned. I don't
allow it on production servers, and I try to discourage people from
installing it on workstations. I'm more tolerant of *NT* than of csh.
That, and that alone is the only thing to infer from my post. The
so-called "translation" is bogus and laughable.
Followups set to a slightly more appropriate group than the one
Rev. Don tried to use.
Matt Evans
This whole thread is obnoxious. I've been flamed numerous times via email
because I like to use tcsh. The basic argument seems to be
"its hard for beginngers to use, and it sucks, dont use it".
I used bash for a *long* time until one day it just simply took too long to load
on my old linux machine. I switched to tcsh and it loaded much faster.
At the time, I didn't have the know how to investigate why bash become
sluggish and I stoped caring a long time ago, as it seems to no longer
exhibit the problem.
Anyhow, I've grown quite comfy with tcsh as an interactive shell, and csh/tcsh
shell programming.
the argument of "it sucks, dont use it" isn't particuarly moving, since it sounds
like something i'd expect from a ravenous droll of AMIGA owners :)
and the argument of "its hard for beginners to use and its inconsistant" isn't
particuarly moving either since in all my csh programming i've been able to
come up with reasonable ways to do everything I need to do, including writing 1 or
2 line sh scripts. It's a preference people. Please stop pretending that
sh/bash/ksh don't have problems and let people get on with their lives.
Get on with your own lives as well.
Followups-To: comp.shell.nazis
--
Matt Evans web: www.loathe.com/~bmajik
School: mev...@cse.unl.edu Work: bma...@ntr.net
"No one will be left to prove that numbers existed,
Maybe soon the children will be born open fisted" -- Dave Mustaine
Gregory Loren Hansen
After all of this, I'm tempted to change my login shell to ksh. But for
what I do with it, I doubt I'd notice the difference.
--
"Besides, it doesn't take much creativity or courage to figure out that
something which reads 'Danger: Flammable' on the label might be fun to
fool about with." -- Joris van Dorp
Tom Keats
[snip]
> typeset allows:
>
> functions to have local variables
> variables to have specific attributes (upper/lowercase, integer,
> left and right justification.
very pretty ...
>
> aliases:
>
> combined with functions, allows you to modify the behaviour of
> "cd", for instance.
>
how often is this useful?
> conditional expressions:
>
> don't require variables to be quoted;
> has time based comparison operators "-nt" and "-ot";
> ownership based comparison operator "-O";
> string collation operators "<" and ">"
> far more powerful than test expressions, combined with
> the expanded
C-written tools can be contrived to be
pipelined in sh
>
> Pattern Matching Notation:
>
> if [[ $var = !(pat1|pat2|...) ]]
>
> which is true as long as $var does not match any of the patterns
> (pat1, pat2, etc) in the expression. Since Patterns are nestable,
> you can not only create expressions with the power of regular
> expressions, but often more powerful. Pattern Matching Notation
> can also be used with Parameter Substitution (${var%%pattern})
> to allow string editing.
pipe in output from SNOBOL4 (which has
superior pattern-matching
capabilities to anything in PERL, ksh,
sed, awk or the various *grep's
- although it is a bit of a slowpoke -
payoff vs tradeoff :) )
> Arithmetic Operations:
>
> using let or by implicit actions. If x is defined as an integer,
> then the following are equivalent:
>
> let x = x + 1
> ((x += 1))
> x=x+1
Isn't one syntax is enough?
hmmm ... Let .... Let ... isn't that a
<ugh> BASIC thing?
(sorry, sorry, i let a little attitude
slip out) <mock sheepish grin>
>
> So, for instance, after using getopts, to shift off the
> operators:
>
> shift OPTIND-1
>
hmmm... is it possible to simulate this
in sh with $*, $#, $whatever
and "shift"?
> Coprocesses:
>
> let's you set up interactive, two way communications with
> another process, for instance, bc.
>
got me, there ...
> Of course, there's a lot, lot more. Anyone who finds they
> can do what they want as easily in Bourne as ksh either doesn't
> really know ksh or isn't rying anything too demanding.
>
OK.
But gee whiz, often its the *tools* that
the scripts
invoke that does the drudge data
processing more than the shell
itself. All the shells really
*generally* do is determine what
stdout goes to what stdin. Korn does
that nicely (on systems
that have it.). I readily concede that
ksh can do many things
more elegantly than sh; but Bourne *is*
(unfortunately?) more
predominant.
As for *demanding* ... shell scripts?
THANK YOU!!!
Actually, it pleases me that someone out
their still realizes
the value (or even meaning of) vertical
development.
Shell scripts *can* be useful and
productive apps, no matter
or in spite of their environment (or
personal prejudices).
And as for trying, i sometimes find
myself cooking-up my own
C-written tools (platform-specific) to
work in sh.
So, i'm not arguing with you. I'm not
agreeing with you.
I'm argureeing with you, and wishing you
a pleasant
holiday season.
cheers
tom keats
Bruce Barnett
> > aliases:
> >
> > combined with functions, allows you to modify the behaviour of
> > "cd", for instance.
> >
>
> how often is this useful?
Well, in csh this is a very useful feature. Typically people create
aliases of cd so that they can change their prompt when they change
their directory.
> pipe in output from SNOBOL4 (which has
> superior pattern-matching
> capabilities to anything in PERL, ksh,
> sed, awk or the various *grep's
> - although it is a bit of a slowpoke -
> payoff vs tradeoff :) )
Griswold, the developer of SNOBOL, extended the concepts to a newer
language called ICON around 1983. If you like SNOBOL, you may wish to
check it out. Years ago I used a open source version to solve a
particular problem. I don't know where the current version is located.
It has set union/difference/intersection operators, lexical
comparisons, finding balancing brackets, and generators.
Generators produces sets if the conditions are true.
The built-in operators (X=Y) are numerous. Here is a sample:
:=: exchanges values, and generates the first value
<-> Like above, but generates the second value
= compares two integers, and generates one if the numbers
are equal
== compares two strings, and generates one of them if equal
=== compares lists, and generates one if they are
identical
==:= compares two strings, assignes the value to one if
they are lexically equal, and generates the first value
===:= Like the above, but compares two lists
To give an idea of the power, the following shuffles a deck of cards:
procedure shuffle(deck)
every !deck :=: ?deck
return deck
end
To build a deck of 52 values, construct a set of 52 letters a-z
and A-Z:
deck := &ucase || &lcase
Rev. Don Kool
Sorry, I didn't notice that you were sticking to such heady
technical issues as a shell being "evil". Now I see your point. I
feel the same way about SUN/SOLARIS.
Yours in Christ,
Gregory Loren Hansen
Gary L. Burnore <gbur...@databasix.com> wrote:
>On 3 Dec 1998 04:33:13 GMT, in article <7454a9$h19$1...@jetsam.uits.indiana.edu>,
>glha...@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote:
>
>>
>>After all of this, I'm tempted to change my login shell to ksh. But for
>>what I do with it, I doubt I'd notice the difference.
>
>fought moving to ksh from csh for a long time. Now I wish I'd switched years
>sooner.
It more depends on what I'm doing with it. So far, the difference between
csh and ksh, to me, has been needing to know two different ways to do
some of the same things. Like setting the display screen for X apps.
B. Chas Parisher
:) After all of this, I'm tempted to change my login shell to ksh. But for
:) what I do with it, I doubt I'd notice the difference.
The biggest reason I changed over to a Bourne compatible shell:
$ for i in * ; do foo $i ; done
--B. Chas Parisher
Mathew A. Hennessy
Gregory Loren Hansen <glha...@copper.ucs.indiana.edu> wrote:
>
>It more depends on what I'm doing with it. So far, the difference between
>csh and ksh, to me, has been needing to know two different ways to do
>some of the same things. Like setting the display screen for X apps.
For interactive use, check out bash or tcsh.. you can still use
any shell you like with a shebang, or if you must (I must, sometimes ;),
just invoke ksh/csh at the command line.
It's just that I like saving keystrokes when I can.. ;)
Mathew A. Hennessy
Bruce Barnett <see.my.add...@domain.com> wrote:
>
>Well, in csh this is a very useful feature. Typically people create
>aliases of cd so that they can change their prompt when they change
>their directory.
ksh has PS1, and bash has some extended support for changing
prompts (for path, history, time IIRC, etc)
>Griswold, the developer of SNOBOL, extended the concepts to a newer
>language called ICON around 1983. If you like SNOBOL, you may wish to
>check it out. Years ago I used a open source version to solve a
>particular problem. I don't know where the current version is located.
Neither of which are going to be as widely available as Perl.. ;)
Remember one of the big points of using shell scripts: portability.. And
you're not about to code some multi-KLOC application in a standard
interpreted shell, are you? ;) ;)
>Bruce <barnett at crd. ge. com> (speaking as myself, and not a GE employee)
--
Peter Samuelson
> I am willing, but my time is short this month. I have already listed
> some of the major problems of the C shell.
> I'll try to fill this out during the holidays, and give some examples
> suitable for beginners.
Well, I don't have much time either but this sounded like fun ... so I
tried my hand at it. This is a rather rough draft. If anyone wants to
edit it into something more professional, maybe post it on a web site
or any other more permanent medium than Usenet, please feel free. (I
*would* appreciate a small ack in it somewhere, but other than that,
consider it public domain.)
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
======================================================================
BRUCE BARNETT'S TOP TWELVE REASONS NOT TO USE CSH
as interpreted by Peter Samuelson
The C Shell (or "csh") has many bugs, limitations and quirks. (To be
fair, all shells have bugs, limitations and quirks -- but several of
the ones in csh are relatively severe.) Here are twelve problems with
csh that, if you use it long enough, you will run into and be annoyed
by.
The Twenex C Shell ("tcsh") is a mutant version of csh to which a lot
of enhancements and bug fixes have been added. tcsh fixes a few of the
issues this document raises (particularly the out-and-out bugs). Even
so, most of this document is relevant to tcsh, since most of the issues
are design limitations, not actual bugs, and tcsh couldn't fix these
without becoming incompatible with csh. In other words, tcsh is not
really any more suitable for programming in than csh.
1. Ad Hoc Parser
A parser is the part of a program that translates input into
whatever form is useful to the internals of the program. In the
case of csh, the parser reads and breaks down the commands you type
(either interactively or in a script) so csh can take action on
them. Unfortunately, the parser in csh was apparently not designed
very cleanly, and thus you find a lot of weird bugs and limitations.
For example, the parser reads one line of input at a time, and
parses the whole line before actually evaluating any of it. This
might sound sensible, but watch this:
% if ( $?xx ) echo $xx
xx: undefined variable.
The `if ( $?xx )' is supposed to mean "do the following only if $xx
is a valid variable" -- so that otherwise you don't get an error
message about using it. But csh returns the error message anyway!
This is because csh went ahead and parsed the whole line before
executing the `if' statement -- and the last half of the line
generated the error. To get around this, you have to use a
multi-line `if' statement, so that the offending `echo' statement
doesn't get read until after the `if' has been run:
% if ( $?xx ) then
> echo $xx
> endif
And that is just an example of where csh's Ad Hoc Parser will bite
you. Often something that looks valid just won't work. (Usually
there will be workarounds, like the above, if you can figure them
out.) Several of the other
2. Multiple-line quoting difficult
In the Bourne shell, and shells derived from it, you can easily
manipulate a string that spans several lines, leaving the line
breaks intact -- just start and end the string with a single quote
mark ('). These can be useful in several situations. For example,
many people embed ten-line `awk' scripts into a shell script this
way.
In csh, multi-line strings are awkward. First, you have to end each
line with `\'. Second, csh has trouble dealing with multi-line
strings in variables. Observe:
% set a='testing a\
? multi-line variable'
% echo $a
testing a multi-line variable
But what if you want to keep the line break in it? You have to use
quotes around the variable name (which should be SOP anyway, by the
way). So try it:
% echo "$a"
Unmatched ".
Actually this is the Ad Hoc Parser at work -- the parser expands
the $a variable, then can't find the closing " mark since it is no
longer on the first line! I am not sure if there are workarounds
to this one.
3. Quoting can be confusing and inconsistent
Both csh and the Bourne family of shells use several different
types of quote marks, and conceptually they use them in similar
ways, but csh has some quirks in this regard. Take single quotes
('), for example. In the Bourne shell, single quotes mean that
everything inside them is quoted absolutely -- all punctuation, all
whitespace (including newlines) -- everything is left untouched
until the matching single quote.
In csh, single quotes mean everything inside them is left untouched
-- except newlines, which must be escaped with backslashes, and
bangs (`!' characters), which also must be escaped with
backslashes. In particular, the fact that `!' will try to do
history substitutions on you even within single quotes can be
annoying. (Workaround exists.)
4. if/while/foreach cannot use redirection
In Bourne-derived shells, a construct like `if-else' or `while' can
be treated as a single pipeline, meaning you can redirect input and
output for the whole construct at once. In csh, you can't.
5. Limited file I/O redirection
In csh you can redirect input and output to and from a pipeline.
If you want to redirect standard input from a file, you use the
syntax `commandname < filename'; if you want to redirect stadard
output to a file, use `commandname > filename'. To redirect
standard output and standard error both, use `commandname >&
filename'.
Unfortunately that is pretty much *all* you can do with file
descriptors. It might not sound too limiting until you hear that
the Bourne shell can open and close whatever file descriptors you
want, at any time, and open them for input or output, whatever you
happen to want.
Say you want to run two commands, pipe their error messages to
separate files, and pipe their normal output through `more'. In
the Bourne shell, this is straightforward:
$ {
$ command1 2> errfile1;
$ command2 2> errfile2;
$ } | more
In csh, if you should ever want to do this, you are basically out
of luck. (Really clumsy workarounds may have been thought of
somewhere.)
6. Limitations in reading line input into a script
Standard Bourne-like shells let you read a line of input at a time
(or even a single character at a time, if you are reading from a
terminal and enjoy kludging around with `stty') from any file or
file descriptor. csh is not nearly as flexible -- all you can do
is read a line at a time from the terminal. (some variants, like
tcsh, at least lift that restriction and let you read from standard
input if it isn't a terminal.)
In case this sounds obscure, think about a shell script that uses
a configuration file. In a Bourne-like shell, you just open the
config file and start reading lines:
exec 5< /etc/config.file # open config file
while read x <&5; do # read each line into $x
...process "$x" as a config option...
done
exec 5<&- # close config file
I don't think that sort of thing is possible in csh at all.
7. Poor management of signals and subprocesses
In the Bourne shell you can install signal handlers that will be
called whenever a particular signal is received -- just like in C.
Every signal can be caught (except KILL and STOP, which Unix does
not let a process catch at all) and dealt with.
In csh, by contrast, you can only control what happens with INT,
TERM and HUP. For an example of when this isn't enough, consider
writing a terminal-locking program in csh (where the user has to
enter a password or something to unlock the terminal). Since it is
not possible to catch or ignore SIGTSTP (generated by your
`suspend' key), a user could defeat your lock by suspending the
shell (with ^Z). (As usual, workarounds exist -- you can use
`stty' to disable the suspend key, in this case.)
Subprocesses are also a little harder to manage in csh than in
Bournish shells. In any shell you can get the process ID number
(PID) of the last background process you started, with $!. But if
you want to wait for a particular background process to finish, you
can't use csh, since its `wait' builtin always waits for *all*
background jobs to finish. The Bourne version of `wait' (or at
least the version in job-control variants of Bourne) lets you
specify a specific PID or job identifier to wait for.
8. Fewer ways to test for missing variables
Perhaps it should be considered a feature that csh does not allow
use of variables that have not been initialized -- but it can be a
pain. The nature of shell scripts (and Unix programs in general)
is that a lot of information can be passed from one program to
another by use of environment variables. To test whether a
variable has been set, in Bourne shell you just test whether it is
or is not an empty string -- end of story.
In csh it is more complicated, since if you did that it would
complain about nonexistent variables. So instead you have to use
the $? operator which explicitly tests for a variable being
defined. Unfortunately, thanks to the Ad Hoc Parser, the following
line can generate an error:
% if ($?var && ($var != 'nil')) then
var: undefined variable.
Ideally the `&&' should prevent the second half of the statement
from being evaluated unless `$var' does indeed exist. However,
the parser reads in the whole line at a time, and complains about
the use of `$var' before it gets around to discovering that it
wasn't supposed to execute that part.
This means that for things like this you really need two separate
`if' statements:
% if ($?var) then
? if ($var != 'nil') then
And yes, the two statements do need to go on two separate lines.
This is widely considered to be an annoyance.
9. Spaces in arguments are problematic
[Can someone else fill this one in? I don't know precisely what the
issues are on this one.]
10. No way to change the field separator
In the Bourne shell, you can set the $IFS variable to a string of
characters that you want to use as field separators for reading
input. csh does not have an equivalent -- you have to use the
default field separator, i.e. tabs and spaces.
11. Bigger and slower than sh
These days it may not matter much if csh is bigger than the Bourne
shell, since modern Unix machines use shared memory so a large
executable file is only taking up memory once. (Note also that
other Bourne-like shells (ksh, bash, zsh) are much bigger than
csh.) But csh is also less efficient than most of those others.
And working around csh's limitations sometimes requires doing
inefficient things like spawning external processes.
12. No functions - aliases are a poor substitute
In the Bourne shell, you can define a function which takes
arguments and returns an integer (rather like an entire shell
script does). In some Bournish shells it can have local
variables. Functions promote better organization of medium- to
large-sized scripts, and allow code reuse, much like functions in
other languages do.
csh does not have functions. It has aliases. csh aliases can
take parameters, but in an arcane and limited manner. (It
harnesses its history mechanism to provide the parameters.)
Aliases also have to be declared in a single statement, which
means it's awkward to define a multi-line alias. That wouldn't be
so bad except that in csh, you can't use things like `while' loops
in a single line -- csh relies on line breaks between keywords.
Yet another effect of the Ad Hoc Parsing. Anyway, creating a csh
alias for anything but the most trivial of tasks is more trouble
than it's worth.
Kevin W. Thomas
Peter Samuelson <psam...@sampo.creighton.edu> wrote:
>[Bruce Barnett]
>> I am willing, but my time is short this month. I have already listed
>> some of the major problems of the C shell.
>[...]
>> I'll try to fill this out during the holidays, and give some examples
>> suitable for beginners.
>
>Well, I don't have much time either but this sounded like fun ... so I
>tried my hand at it. This is a rather rough draft. If anyone wants to
>edit it into something more professional, maybe post it on a web site
>or any other more permanent medium than Usenet, please feel free. (I
>*would* appreciate a small ack in it somewhere, but other than that,
>consider it public domain.)
>
>--
>Peter Samuelson
><sampo.creighton.edu!psamuels>
>
>======================================================================
>
>BRUCE BARNETT'S TOP TWELVE REASONS NOT TO USE CSH
>as interpreted by Peter Samuelson
>
>
>The C Shell (or "csh") has many bugs, limitations and quirks. (To be
>fair, all shells have bugs, limitations and quirks -- but several of
>the ones in csh are relatively severe.) Here are twelve problems with
>csh that, if you use it long enough, you will run into and be annoyed
>by.
Is everyone else as tired of the "csh" bashing as I am? I've used it for
many years, as far back as my PDP-11/44 days (2.9BSD). It works fine and
meets my needs.
Based upon the deleted documentation, I would say that only a small percentage
of the people would ever have to worry about the documented "flaws".
The best advise is to use whatever shell you want to program. If it can't
do what you want, try a different shell, try perl, or write the program
in C.
Kevin W. Thomas
Sun System Administrator & Meteorologist
National Severe Storms Laboratory
Norman, Oklahoma
Email: kwth...@wizard.nssl.noaa.gov
Kevin W. Thomas
>
>forach i (*)
^^^^^^
foreach
> foo $i
>end
Some people in this group say you shouldn't do that because it's csh. :-)
Guy Tal
: Is everyone else as tired of the "csh" bashing as I am?
I am. I placed a kill on that thread, but now it seems it's been given a
new subject...
: The best advise is to use whatever shell you want to program. If it can't
: do what you want, try a different shell, try perl, or write the program
: in C.
I second that. I wouldn't use shell for anything more complex than a
simple repetitive task or grouping a set of commands to save on typing.
For anything more complex, I don't see a reason to bother with shell when
full-featured languages offer a lot more functionality and often better
performance.
If csh works well for you and you're very familiar with it - use it. All
this bashing (no pun intended) is really getting tiresome.
Guy
Philip Brown
>Tom Keats <tom_...@bc.sympatico.ca> writes:
>
>> > aliases:
>> >
>> > combined with functions, allows you to modify the behaviour of
>> > "cd", for instance.
>>
>> how often is this useful?
>
>aliases of cd so that they can change their prompt when they change
>their directory.
someone else mentioned this obliquely; I'll mention it specifically:
under ksh,
PS1='$PWD$ '
Automatically sets your prompt to be the current directory.
That's a lot cleaner than aliasing "cd".
--
[trim the no-bots from my address to reply to me by email!]
--------------------------------------------------
"initiating.. 'getting the hell out of here' maneouver" - Lennier, babylon5
Trevor Clarke
>
>Is everyone else as tired of the "csh" bashing as I am? I've used it for
>many years, as far back as my PDP-11/44 days (2.9BSD). It works fine and
>meets my needs.
>
>Based upon the deleted documentation, I would say that only a small percentage
>of the people would ever have to worry about the documented "flaws".
>
>do what you want, try a different shell, try perl, or write the program
>in C.
>
Agreed, from a non-scripting standpoint I like csh(or sometimes tcsh)better
then Bourne. The on shell scripts I write are simple ones that respawn servers,
etc. anything more complicated, I use python. Example, my .login is as follows:
if({ tty -s } && $?prompt) then
switch (`machine`) # python isn't installed on the SVR4 machines
case 'mips':
case 'pmax':
if (-x 'bin/advlogin.py') then
bin/advlogin.py
endif
breaksw
endsw
endif
--
Trevor R.H. Clarke Computer Science House
Rochester Institute of Technology Scientific Programmer for CIS
ret...@csh.rit.edu trc...@cis.rit.edu
http://www.csh.rit.edu/~retrev/
Philip Brown
>6. Limitations in reading line input into a script
>
> Standard Bourne-like shells let you read a line of input at a time
> exec 5< /etc/config.file # open config file
> while read x <&5; do # read each line into $x
> ...process "$x" as a config option...
> done
> exec 5<&- # close config file
>
> I don't think that sort of thing is possible in csh at all.
Oh come on. If you're writing this, you need to be proficient in both sh and
csh. You can certainly read lines in csh. EG:
set line="fake"
while($line != "")
set line=$<
echo line is $line
end
The "config file" example there, though, is a more interesting problem. I'm
not a csh guru, so can't thing of a good way to do a config file in THAT
manner.
But offhand, the simple way is a way you can also use in sh:
Have the config file be a bunch of variable assignments, eg:
source configfile
where configfile contains:
set opt1=false
set opt2=true
and so on.
>12. No functions - aliases are a poor substitute
This is the biggie for me.
Stefan Monnier
> forach i (*)
> foo $i
> end
Indeed, I got used to csh-style loops long before I learned sh and
they do work. I must say that the ability to write a loop on a single line
comes in very handy, especially since tcsh doesn't provide much history
editing features when it comes to the `foo $i' part of the loop.
Not a reason to switch, but a nice side effect.
One of those things were interactive support is better on bourne style shells.
Stefan
Barry Margolin
Stefan Monnier <monnier+comp/unix/admin/news/@tequila.cs.yale.edu> wrote:
>Indeed, I got used to csh-style loops long before I learned sh and
>they do work. I must say that the ability to write a loop on a single line
>comes in very handy, especially since tcsh doesn't provide much history
>editing features when it comes to the `foo $i' part of the loop.
>
>Not a reason to switch, but a nice side effect.
>One of those things were interactive support is better on bourne style shells.
I do much of my shelling in an Emacs shell buffer, so I get interactive
recall of input no matter what shell I use, and can also recall input to
subprompts. In fact, I also get interactive recall of input to programs
that *aren't* shells.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Don't bother cc'ing followups to me.
Barry Margolin
Kevin W. Thomas <kwth...@wizard.nssl.noaa.gov> wrote:
>Based upon the deleted documentation, I would say that only a small percentage
>of the people would ever have to worry about the documented "flaws".
The inability to redirect stderr separately from stdout comes up quite a
bit in the newsgroups.
And the ad hoc parser, which requires spaces in strange places, probably
gets most beginning csh scripters. Then again, Bourne-style shells also
have some non-intuitive spacing requirements. E.g.
if [$foo==$bar];...
won't work as one might naively expect -- it's hardly intuitive to people
proficient in traditional programming languages that '[' is the name of a
command, and that ']' would be an argument to that command.
Dan Mercer
Tom Keats <tom_...@bc.sympatico.ca> writes:
> Dan Mercer wrote:
>
> [snip]
>
>> typeset allows:
>>
>> functions to have local variables
>> variables to have specific attributes (upper/lowercase, integer,
>> left and right justification.
>
> very pretty ...
>
>>
>>
>> combined with functions, allows you to modify the behaviour of
>> "cd", for instance.
>>
>
> how often is this useful?
A lot of people modify cd to change the prompt or the titlebar on
changing directories. I also keep track of the most recent directories
I visit. A shell function that posts a simple menu using select
allows me to switch directories fairly easily. Also, ksh aliasing
is recursive if the last character in the alias is a space. So my
alias for cd:
cd='pd ' # pd was originally a much simpler Bourne shell
# function that stood for "prompt directory"
allows me to:
alias lpi=/var/spool/lp/interface
and then
cd lpi
cd's me to /var/spool/lp/interface, changes my titlebar, and
adds /var/spool/lp/interface to the top of my directory stack.
I do a:
trap goodbye EXIT
and the goodbye function writes the directory stack to a file
where it's available the next time I login.
>
>> conditional expressions:
>>
>> don't require variables to be quoted;
>> has time based comparison operators "-nt" and "-ot";
>> ownership based comparison operator "-O";
>> string collation operators "<" and ">"
>> far more powerful than test expressions, combined with
>> the expanded
>
> C-written tools can be contrived to be
> pipelined in sh
Still would require quoting and certainly far more overhead
and far less convenience.
>
>>
>> Pattern Matching Notation:
>>
>> if [[ $var = !(pat1|pat2|...) ]]
>>
>> which is true as long as $var does not match any of the patterns
>> (pat1, pat2, etc) in the expression. Since Patterns are nestable,
>> you can not only create expressions with the power of regular
>> expressions, but often more powerful. Pattern Matching Notation
>> can also be used with Parameter Substitution (${var%%pattern})
>> to allow string editing.
>
>
> pipe in output from SNOBOL4 (which has
> superior pattern-matching
> capabilities to anything in PERL, ksh,
> sed, awk or the various *grep's
> - although it is a bit of a slowpoke -
> payoff vs tradeoff :) )
And now you have to know SNOBOL4 (not universally available) plus
fork and exec and get return codes, etc. Yucch!
>
>> Arithmetic Operations:
>>
>> using let or by implicit actions. If x is defined as an integer,
>> then the following are equivalent:
>>
>> let x = x + 1
>> ((x += 1))
>> x=x+1
>
> Isn't one syntax is enough?
> hmmm ... Let .... Let ... isn't that a
> <ugh> BASIC thing?
> (sorry, sorry, i let a little attitude
> slip out) <mock sheepish grin>
>
>>
>> So, for instance, after using getopts, to shift off the
>> operators:
>>
>> shift OPTIND-1
>>
>
> hmmm... is it possible to simulate this
> in sh with $*, $#, $whatever
> and "shift"?
Yes, but at an enormous price in performance and maintainability.
>
>> Coprocesses:
>>
>> let's you set up interactive, two way communications with
>> another process, for instance, bc.
>>
>
> got me, there ...
>
>> Of course, there's a lot, lot more. Anyone who finds they
>> can do what they want as easily in Bourne as ksh either doesn't
>> really know ksh or isn't trying anything too demanding.
>>
>
> OK.
>
> But gee whiz, often its the *tools* that
> the scripts
> invoke that does the drudge data
> processing more than the shell
> itself. All the shells really
> *generally* do is determine what
> stdout goes to what stdin. Korn does
> that nicely (on systems
> that have it.). I readily concede that
> ksh can do many things
> more elegantly than sh; but Bourne *is*
> (unfortunately?) more
> predominant.
Less so than you think. HPUX has abandoned Bourne for Posix.
That can create unexpected behaviour in scripts - for instance,
the Posix shell will read the $ENV file and also aliases some
commands. I've seen Bourne shell scripts go down some strange
paths when run under Posix.
Other vendors are linking /bin/sh to /bin/ksh. Some Unixes
never had real Bourne, or had competing bournish shells
(creating problems like properly interpreting 'echo "===> \c").
Some systems use bash for Bourne. NCR modified Bourne to
use a ~/.shrc file (analoagous to .cshrc).
We have very demanding scripts here that, for instance, track
and application using a database back to the user on a remote
system. The current technology relies heavily upon remsh utilities,
bu future technology will utilize ksh93 and dtksh and scripts running
under inetd. Preliminary indications are that we will gain a tenfold
increase in performance, minimal. Scripts that took minutes to
scour our net for information will now run in seconds. When you
have a hung database you are trying to debug, that's critical.
All our current scripts began their lives as Bourne shell scripts,
and all have seen enormous increases in performance already. In fact,
many of those scripts began their lives as awk scripts simply because
Bourne was too slow. We migrated away from awk when ksh was able
to run as fast, proved easier to support (HP twice trashed awk
so our scripts stopped running and we had to quick switch them to
gawk. Since we only found the problems while doing 3 gig installs
we were a tad put out).
Dan Mercer
>
> As for *demanding* ... shell scripts?
>
> THANK YOU!!!
>
> Actually, it pleases me that someone out
> their still realizes
> the value (or even meaning of) vertical
> development.
>
> Shell scripts *can* be useful and
> productive apps, no matter
> or in spite of their environment (or
> personal prejudices).
>
> And as for trying, i sometimes find
> myself cooking-up my own
> C-written tools (platform-specific) to
> work in sh.
>
> So, i'm not arguing with you. I'm not
> agreeing with you.
> I'm argureeing with you, and wishing you
> a pleasant
> holiday season.
>
> cheers
>
> tom keats
Opinions expressed herein are my own and may not represent those of my employer.
Dan Mercer
phi...@bolthole.no-bots.com (Philip Brown) writes:
> On 03 Dec 1998 09:17:30 -0500, see.my.add...@domain.com wrote:
>>Tom Keats <tom_...@bc.sympatico.ca> writes:
>>
>>> >
>>> > combined with functions, allows you to modify the behaviour of
>>> > "cd", for instance.
>>>
>>> how often is this useful?
>>
>>aliases of cd so that they can change their prompt when they change
>>their directory.
>
> someone else mentioned this obliquely; I'll mention it specifically:
>
> under ksh,
>
> PS1='$PWD$ '
>
>
> Automatically sets your prompt to be the current directory.
> That's a lot cleaner than aliasing "cd".
>
Some of us like nice clean prompts like '$ ' and, since we work in
X, prefer to change the titlebar. Doing that in the prompt screws
up the history mechanism and is a big performance penalty added
every time you hit enter. When you work from home over a modem,
as I do regularly, that penalty is severe. Besides, there's
so much else aliasing cd buys you. For instance:
$ alias cd='cd ' # allow recursive aliasing
$ alias lpi='/var/spool/lp/interface'
$ echo $PWD
/home/dam
$ cd lpi
$ echo $PWD
/var/spool/lp/interface
My cd alias which aliases to a function call also stacks the directories
visited in an ARRAY var. A second function call, lcd, lists the
stack using select so that I can select which directory to return to.
Dan Mercer
Juergen Ilse
In alt.unix.wizards Bruce Barnett <see.my.add...@domain.com> wrote:
>Wolfgang Denk <w...@denx.muc.de> writes:
>> C'me on? Which system does _not_ have a ksh or bash?
>SunOS 4.X for one. We have thousands of UNIX systems here, and some
>systems still have this OS.
Simply get the bash-sources, and compile it for yourself (it compiles
out of the box on SunOS4.x). The sources are free, so what is the prob-
lem? If you don't want to use only shells that come with the system for
your shell-scripts, use /bin/sh. /bin/sh is not the best choice as inter-
active shell, but there are no real reasons to use csh for scripting (just
my opinion).
You say, there are systems, that do not have ksh or bash, there are also
(older) systems, that don't have csh either, but the good old bourne-shell
is available on nearly every unix-system...
ciao,
Juergen Ilse (il...@asys-h.de)
Juergen Ilse
In alt.unix.wizards Mathew A. Hennessy <henn...@cloud9.net> wrote:
>In article <73vh5a$mgd$1...@reader1.reader.news.ozemail.net>,
>Ken Wallis <ke...@empower.aust.com> wrote:
>>Mathew A. Hennessy wrote in message
>>> I'm quite fond of bash myself, and install it on all systems I
>>>access, but I suppose learning ksh is like learning vi.. ;)
Why??? I use "set -o emacs" when i use ksh interactively (has nothing to
do with the braindead vi-style command-line-editing) ;-)
If you want to use the cursor-keys on Terminals, that use the same ESC
sequences as a vt100 for them, you may use some sort of aliases to get
them work as expected. For pdksh, you can use the "bind" command to
modify the keyboard-bindings in the command-line-editor. And if you want
something like "joe" or "pico" as command-line-Editor, just set your
"$EDITOR" and use the "fc" command... ;-)
> Yes, but bash has a few neat features which I prefer
>interactively.. My habits:
> o command line scripts ('find / -print|while read FILE'- style)
> are in bash, and I rarely conflict with ksh-semantics.
I don't know, why that should be impossible in ksh:
find . -name '*.txt' -print | while read file;do echo $file; done
works perfectly with ksh on solaris, and i think also on other unixes.
> o widely-distributed scripts, or trivial scripts are in /bin/ksh
...or in /bin/sh (if i don't really need ksh-features)...
The advantage is, that sh-scripts are also useable in ksh, bash and
(maybe) zsh, ksh-script are often not useable in sh, sometimes not
in bash...
> o anything larger than simple file manipulation is Perl
...or awk, or tcl, or... I Don't like perl, but that is only my very
own opinion...
> Granted, there may be (and have been) bits which are not quite
>compatible, the trouble is offset (for me, anyways) by the countless
>keystrokes saved thanks to bash's tab-completion ;)
...which is available (not in the same but in a similar way) with ESC-ESC
in ksh (ksh does the completion only, if there is only one possibility,
it doesn't show you all possibilities as bash does).
ciao,
Juergen Ilse (il...@asys-h.de)
Ken Wallis
>>>Mathew A. Hennessy wrote:
>>>> I'm quite fond of bash myself, and install it on all systems I
>>>>access, but I suppose learning ksh is like learning vi.. ;)
>Why??? I use "set -o emacs" when i use ksh interactively (has nothing to
>do with the braindead vi-style command-line-editing) ;-)
This thread has got into trouble with a number of readers who have objected
to the amount of "csh bashing" which it is perceived to have included. If
it is going to become "emacs vs vi" then that will be a WAR and it won't be
pretty!
Let's hope that everyone can remain calm and that no blood has to be shed
over this careless indiscretion. ;^)
Best Regards,
Ken Wallis
Empower Data Solutions Pty Limited, ACN 079 955 196
Envision, enable, enhance... empower
Thomas L|fgren
BB> Griswold, the developer of SNOBOL, extended the concepts to a
BB> newer language called ICON around 1983. If you like SNOBOL,
BB> you may wish to check it out. Years ago I used a open source
BB> version to solve a particular problem. I don't know where the
BB> current version is located.
http://www.cs.arizona.edu/icon/
It's a very nice string handling language, but I think its use is
rather limited outside of that. Still, it's worth checking out.
Tom
--
Wherever I lay my .emacs, that's my ${HOME}
Rev. Don Kool
> Gary L. Burnore <gbur...@databasix.com> wrote:
> >ba...@netcom.com (B. Chas Parisher) wrote:
> >>Gregory Loren Hansen sez:
> >>:) After all of this, I'm tempted to change my login shell to ksh. But for
> >>:) what I do with it, I doubt I'd notice the difference.
> >>
> >>The biggest reason I changed over to a Bourne compatible shell:
> >>
> >>$ for i in * ; do foo $i ; done
> >
> >In csh,
> >
> >forach i (*)
> ^^^^^^
> foreach
> > foo $i
> >end
>
> Some people in this group say you shouldn't do that because it's csh. :-)
Unfortunately that seems to be their most compelling reason. :-(
Rev. Don Kool
> Juergen Ilse wrote:
> >>>Mathew A. Hennessy wrote:
> >>>> I'm quite fond of bash myself, and install it on all systems I
> >>>>access, but I suppose learning ksh is like learning vi.. ;)
>
> >Why??? I use "set -o emacs" when i use ksh interactively (has nothing to
> >do with the braindead vi-style command-line-editing) ;-)
>
> This thread has got into trouble with a number of readers who have objected
> to the amount of "csh bashing" which it is perceived to have included. If
> it is going to become "emacs vs vi" then that will be a WAR and it won't be
> pretty!
I'm sure the Bourne shell faithful will come out in favor of "ed"
over either "emacs" or "vi". After all, you're sometimes in
situations where "vi" and "emacs" aren't available. Why learn a
second editor when "ed" works just fine? :-)
Rev. Don Kool
Peter Samuelson <psam...@sampo.creighton.edu> wrote:
> >[Bruce Barnett]
> >> I am willing, but my time is short this month. I have already listed
> >> some of the major problems of the C shell.
> >[...]
> >> I'll try to fill this out during the holidays, and give some examples
> >> suitable for beginners.
> >
> >Well, I don't have much time either but this sounded like fun ... so I
> >tried my hand at it. This is a rather rough draft. If anyone wants to
> >edit it into something more professional, maybe post it on a web site
> >or any other more permanent medium than Usenet, please feel free. (I
> >*would* appreciate a small ack in it somewhere, but other than that,
> >consider it public domain.)
> >
> >--
> >Peter Samuelson
> ><sampo.creighton.edu!psamuels>
> >
> >======================================================================
> >
> >BRUCE BARNETT'S TOP TWELVE REASONS NOT TO USE CSH
> >as interpreted by Peter Samuelson
> >
> >
> >The C Shell (or "csh") has many bugs, limitations and quirks. (To be
> >fair, all shells have bugs, limitations and quirks -- but several of
> >the ones in csh are relatively severe.) Here are twelve problems with
> >csh that, if you use it long enough, you will run into and be annoyed
> >by.
>
> Is everyone else as tired of the "csh" bashing as I am? I've used it for
> many years, as far back as my PDP-11/44 days (2.9BSD). It works fine and
> meets my needs.
>
> Based upon the deleted documentation, I would say that only a small percentage
> of the people would ever have to worry about the documented "flaws".
>
> The best advise is to use whatever shell you want to program. If it can't
> do what you want, try a different shell, try perl, or write the program
> in C.
Sounds about right to me.
Yours in Christ,
Bruce Barnett
> Simply get the bash-sources, and compile it for yourself (it compiles
> out of the box on SunOS4.x).
Please - don't assume that everyone is of the same level. I've
been using USENET for 15 years. Of course I could compile anything
available. But some people have no idea of how make(1) works, or how
to install an application. I also know many sites that refuse to support
public domain software because of the headaches it provides (and I
understand, because I've done that for a decade.)
These are the ones that timidly approach USENET, and post a simple
question. After a barrage of flames when they DARE to ask about the C
shell, they leave - convinced the c.u.s users are obnoxious.
I've spoken to people who feel that any message that offers a
suggestion about the posting (i.e. didn't provide enough
information, posted to an inapproriate newsgroup, signature too long,
didn't edit enough, etc.) to be a flame. You and I know this is
merely a helpful sugestion, but to new users, this is a flame.
But when people start posting anti-C-shell messages to these new users, it
is as if an atom bomb was lobbed at their account!
> You say, there are systems, that do not have ksh or bash, there are also
> (older) systems, that don't have csh either, but the good old bourne-shell
> is available on nearly every unix-system...
I'm sorry but I don't see how that relates to the argument.
--
Bruce Barnett
>I must say that the ability to write a loop on a single line
> comes in very handy, especially since tcsh doesn't provide much history
> editing features when it comes to the `foo $i' part of the loop.
>
> Not a reason to switch, but a nice side effect.
This is a good example of the problems of CSH's ad-hoc parser.
If I wanted to repeat this using the !foreach command,
it would only get the first line.
Bruce Barnett
> If
> it is going to become "emacs vs vi" then that will be a WAR and it won't be
> pretty!
Oh my God. I hope no one mentions TECO. Oops!
:-)
Bruce Barnett
> If csh works well for you and you're very familiar with it - use it. All
> this bashing (no pun intended) is really getting tiresome.
I to, have used csh for years. One of the first jobs I had at
this building (12 years ago) was maintaining a 20-page CSH program. I
read Tom's document at the time, and dismissed it because of the
tone. I knew there were problems, but I could work around them.
I too was tired of the bashing.
But the more I used csh, the more problems I found. I'd add
one line, and get a core dump. I'd do something that I thought was
reasonable, and I'd get a syntax error. I'd try to add something
advanced, and I'd find out that I could not do it. Once or twice is
fine, but after having dozens of problems, I finally decided to quit
using it for shell scripts.
Since I have, I've been able to develop more advanced scripts.
I've been using PERL for a decade, but I still need shell scripts. To
give an example, I was writing a benchmarking program that would start
up several processes, time them, and clean up afterwards. I needed to
launch several processes and wait for them to finish. If I
interrupted the main process, I had to kill all of them. This was easy
to do using /bin/sh, but csh could not do this easily. I don't think I
would have tried if I only used csh for scripting.
Other examples is taking an interactive script, and converting
it to a batch script. Perhaps you want to hide error messages from the
user of the script, or clean up temporary files and processes when
done. This is harder to do in the C shell.
I think a document that not only explains in a simple fashion
the flaws about the C shell, and warns about the pitfalls that users
will find out, and the work-arounds, and also provides a way to guide
to convert csh scripts into sh or ksh scripts would be very helpful to
csh users. But the current document isn't suitable. It didn't convince
me years ago, because the first thing it did was alienate me when I
read it. That is why I think we need a new FAQ.
One of the things I'd like to see in is this a phrase like
this:
We realize that many people are busy, and that it takes time
to learn a new tool or language. The C shell may seem satisfatory for
new users, and we understand that.
However, you should know that the more you use the C shell, the
more likely you will have problems with it. It has some major quirks
in it that might sneak up on you someday and cause problems. As the
old maps say:
There be monsters ahead. Beware!
This list describes some of the problems of the C shell. We
suggest you read this document and become aware of the potential
problems you may face someday. We have described work-arounds for
those C shell problems you will face, along with equivalent Bourne
shell code of common C shell constructs to help you make the
transition to a new shell easier.
<...to be continued...>
Bruce Barnett
> Oh come on. If you're writing this, you need to be proficient in both sh and
> csh. You can certainly read lines in csh. EG:
>
> set line="fake"
> while($line != "")
> set line=$<
> echo line is $line
> end
There are three problems here. The first is that it should be
while("$line" != "")
and not
while($line != "")
Otherwise a blank line will cause a syntax error. Minor problem.
Second, this loop terminates when a blank line is read, not at the end of file.
Third, there is no way to use $< and specify that you want /dev/tty
instead of STDIN. So you can't read from standard input, and then ask
the user for confirmation. $< ALWAYS reads from standard input.
Mattias Hembruch
Philip Brown <phi...@bolthole.no-bots.com> wrote:
>On 03 Dec 1998 09:17:30 -0500, see.my.add...@domain.com wrote:
>>Tom Keats <tom_...@bc.sympatico.ca> writes:
>>
>>> > aliases:
>>> >
>>> > combined with functions, allows you to modify the behaviour of
>>> > "cd", for instance.
>>>
>>> how often is this useful?
>>
>>Well, in csh this is a very useful feature. Typically people create
>>aliases of cd so that they can change their prompt when they change
>>their directory.
>
>someone else mentioned this obliquely; I'll mention it specifically:
>
>under ksh,
>
>PS1='$PWD$ '
>
>
>Automatically sets your prompt to be the current directory.
>That's a lot cleaner than aliasing "cd".
Yeah, and in tcsh you:
set prompt="`hostname`:%/> "
to get hostname:PWD>
Six of one, half dozen of another..
Mattias
--
Mattias Hembruch, BASc, MASc (mghe...@ece.uwaterloo.ca) E2-3343, ext 6165,
Software Support, Electrical and Computer Engineering,
University of Waterloo, Waterloo, Ontario
Philip Brown
>phi...@bolthole.no-bots.com (Philip Brown) writes:
>
>> Oh come on. If you're writing this, you need to be proficient in both sh and
>> csh. You can certainly read lines in csh. EG:
>>
>> set line="fake"
>> while($line != "")
>> set line=$<
>> echo line is $line
>> end
>
>
>There are three problems here.
well, I DID SAY I wasn't a csh expert :-)
>Second, this loop terminates when a blank line is read, not at the end of
>file.
well, the problem there is that I don't know how to do that in csh. Is there a
way?
Philip Brown
>
>Yeah, and in tcsh you:
>set prompt="`hostname`:%/> "
Ah, no, if you care about portability, you'd use
set prompt="`uname -n`":%/> "
uname is POSIX. hostname is not.
Juergen Ilse
In alt.unix.wizards Bruce Barnett <see.my.add...@domain.com> wrote:
>Juergen Ilse <il...@asys-h.de> writes:
>> You say, there are systems, that do not have ksh or bash, there are also
>> (older) systems, that don't have csh either, but the good old bourne-shell
>> is available on nearly every unix-system...
>I'm sorry but I don't see how that relates to the argument.
Some people (you too?) said, that their preferred shell is csh, because
ksh or bash is not available on every system. There are also systems
without csh. If you don't use ksh or bash, because it is not available
on some systems, you may also refuse to use csh (for the same reason)
and use only bourne-shell (what i do, if i have have neither bash nor
ksh available)...
ciao,
Juergen Ilse (il...@asys-h.de)
Juergen Ilse
if csh scripting contains all possibilities of sh/ksh/bash scripting,
how can i do something like this small sh-script in csh?
------------------------------------------------------------------------
#!/bin/sh
# split big binary files in parts of 1.4 mb to get it home on floppys
# note, that on some systems, split can not handle binary files well...
# loop over all command-line parameters
for f in "$@"; do
# initalize counter
count=0
# loop while output of dd is something like "1+0 blocks input"
# and write a message, what file is currently written on stderr.
while [ "`echo writing ${f}.$count >&2 && \
dd if=$f of=${f}.$count bs= 2847b count=1 skip=$count 2>&1 \
| head -1 | cut -c1`" = 1 ]; do
# increment count
count=`expr $count + 1`
done
# write how many parts of the file were written (and how many floppys
# i need to carry these files home)... ;-)
echo `expr $count +1` file(s) written... >&2
done
------------------------------------------------------------------------
One of the systems, i needed such a script, because split did not
support binary files in the way i needed it, was interactive unix 3.2,
another example is SunOS4.1.3...
Again, id on't want someone, who has learned to do scripting with csh
to kick csh, but i think, it would be a good idea, to tell new users,
that sometimes sh/ksh/bash is the better solution, and it is maybe
not worth to learn 2 different shells...
ciao,
Juergen Ilse (il...@asys-h.de)
Kuntal M. Daftary
> if csh scripting contains all possibilities of sh/ksh/bash scripting,
> how can i do something like this small sh-script in csh?
ok. csh cant do everything that sh can. but why bash csh for that ?
sh cant do everything that perl can. so extrapolating your logic, we
should bash sh also by comparing it to perl. sh cannot do everything
that csh can as a user's shell. but i dont see RFCs written against
sh in that case.
> Again, id on't want someone, who has learned to do scripting with csh
> to kick csh, but i think, it would be a good idea, to tell new users,
> that sometimes sh/ksh/bash is the better solution, and it is maybe
> not worth to learn 2 different shells...
if you are going to tell the new users about all the better options in
the unix world, it is going to be a long list.
Kuntal Daftary
Kuntal M. Daftary
> >Yeah, and in tcsh you:
> >set prompt="`hostname`:%/> "
> Ah, no, if you care about portability, you'd use
> set prompt="`uname -n`":%/> "
> uname is POSIX. hostname is not.
actually with tcsh, following will also do:
set prompt="%m:%/>"
Kuntal Daftary
Tom Keats
>
> Tom Keats <tom_...@bc.sympatico.ca> writes:
>
> > > aliases:
> > >
> > > combined with functions, allows you to modify the behaviour of
> > > "cd", for instance.
> > >
> >
> > how often is this useful?
>
> Well, in csh this is a very useful feature. Typically people create
> aliases of cd so that they can change their prompt when they change
> their directory.
>
> > superior pattern-matching
> > capabilities to anything in PERL, ksh,
> > sed, awk or the various *grep's
> > - although it is a bit of a slowpoke -
> > payoff vs tradeoff :) )
>
> language called ICON around 1983. If you like SNOBOL, you may wish to
> check it out. Years ago I used a open source version to solve a
> particular problem. I don't know where the current version is located.
ftp.cs.arizona.edu or even
www.cs.arizona\ftp-sites
Phil Budne has been working on a *nix
MAINBOL-ish version and putting
it up there. Free. Asking for bug
reports. Compiles cleanly
on every *BSD i've used. As we
canadians say, "beauty, eh?"
Icon is there too (as well as on FreeBSD
distro CD's).
I've tried Icon, but SNOBOL4 still has
that lovely unstructured,
weakly-typed thing about it :) and
the Budne version has some
nice SpitBol extensions.
As a matter of fact, i've got the
"Orange Book" (and even read it
and occoasionally7 refer to it <grin>).
For anyone interested in high/mid-level
programming, i recommend
it. I also note that the best
downloadable documentation comes
with the DOS (vanilla) version <sigh>
from CatsPaw. It comes with
surprising features that pre-date C (but
it was developed almost
contemporarily, in the same AT&T
environment).
Anybody who isn't "locked-into" a
"theology" should give it a try.
cheers,
tom
Tom Keats
>
> In article <slrn76dor8....@shell3.ba.best.com>,
> Philip Brown <phi...@bolthole.no-bots.com> wrote:
> >>Tom Keats <tom_...@bc.sympatico.ca> writes:
> >>
> >>> > aliases:
> >>> >
> >>> > combined with functions, allows you to modify the behaviour of
> >>> > "cd", for instance.
> >>>
> >>> how often is this useful?
> >>
> >>Well, in csh this is a very useful feature. Typically people create
> >>aliases of cd so that they can change their prompt when they change
> >>their directory.
> >
> >
> >under ksh,
> >
> >PS1='$PWD$ '
> >
> >
> >Automatically sets your prompt to be the current directory.
> >That's a lot cleaner than aliasing "cd".
>
> set prompt="`hostname`:%/> "
>
>
> Six of one, half dozen of another..
>
<true confessions> sometimes
lose sight of "who i am", and my root
$HOME is the same as my
ordinary $HOME, i do this:
set prompt=("`whoami`@[my domain name]
% ")
so if i'm working as root, my prompt
says "root@blahblah % ";
otherwise, "tomkeats@blahblah % ".
I also don't think prompts that tell you
your cwd are such a good thing.
What if you're in:
/usr/X11/lib/X11/some_weird_thing/lib/some_weird_subdirectory/shared
...
hell, that's more prompt than command!
:)
I don't think typing "pwd" ever broke
anybody's fingers ...
cheers,
tom
Tom Keats
oops, should be host name
i was a little lyxdexic there :)
>
> cheers,
> tom