Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 4 Jun 2010 18:09:34 -0600
From:      Chad Perrin <perrin@apotheon.com>
To:        freebsd-questions <freebsd-questions@freebsd.org>
Subject:   Re: bash instead of csh (completely)
Message-ID:  <20100605000934.GB20023@guilt.hydra>
In-Reply-To: <AANLkTikOwSjEOEKa8Tm03hY9r5lQ3lJ-gL0lSGc-o1Ql@mail.gmail.com>
References:  <AANLkTinPTpGn-Mo3Fi4zf4b3kXYDGRnh6Bmajaphiuvp@mail.gmail.com> <AANLkTinZeECqzLQaPOZydqkK4NaVm6SyCqoG4nxAR_pi@mail.gmail.com> <AANLkTikOwSjEOEKa8Tm03hY9r5lQ3lJ-gL0lSGc-o1Ql@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--TRYliJ5NKNqkz5bu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 04, 2010 at 04:03:42PM -0400, Jerry B. Altzman wrote:
> On Fri, Jun 4, 2010 at 14:59, Chris Rees <utisoft@gmail.com> wrote:
>=20
> > Why would you want to do that?
> >
> To get rid of csh?
> http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/

As pointed out already (at least twice), that is about csh *programming*.
What this means is that nothing in that screed says that having csh
installed on your system is "bad".  If you actually buy everything that
Mr. Christiansen says about how csh is "bad" for programming (and I don't
buy everything he says there, though I do agree with him on a lot of
other topics, particularly where Perl is concerned), you still have no
reason based on that screed to avoid using csh (or tcsh) as your
interactive shell.

Furthermore, there are reasons you shouldn't use bash for scripting.  It
is rather dependency-heavy, for a shell, and if you're going to write
shell scripts you should really try to write them to be as simple, and as
widely understandable and portable, as possible.  This basically means sh
(the Bourne shell) rather than csh, tcsh, bash, zsh, ksh, et cetera.
Even the sh-emulation that bash provides, and that many Linux systems use
instead of a "real" sh, is less than perfect in that regard -- but it's
close enough for government work, I suppose.

I'm about to get very opinionated, so feel free to stick your fingers in
your ears if you don't like what I have to say:

If you get to the point where your programming efforts are so
sophisticated that you can't make do with sh, you should be using a
"real" programming language, rather than a shell that happens to allow
scripting.  This means that by the time sh (with grep, awk, et cetera)
isn't good enough, you should really consider using something like Perl
or Ruby.  By the time sh isn't really sufficient, you're talking about
"real" programming, by which point the lack of clarity of the syntax of
the typical shell languages can become a real thorn in your side when it
comes to maintenance.

Maybe it's just me, but just as I don't see any particular need for MS
Access as a DBMS when it's overlapped by spreadsheets and SQLite on one
end and by a variety of more "serious" DBMSes like PostgreSQL on the
other end, I don't really see much point for bash as a scripting language
when it's significantly overlapped by sh on one end and Perl, Ruby, et
cetera on the other end.  I suppose your mileage may vary.

Anyway . . . ultimately, my point is that I love tcsh as an interactive
shell, and never use it for "programming".  I find it odd that people
want to do programming in a typical Unix shell other than simple
scripting in sh when there are such better options available.

Perl is even more ubiquitous than bash.  Why not just use that for
scripting if you want more than sh?

--=20
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

--TRYliJ5NKNqkz5bu
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)

iEYEARECAAYFAkwJlb4ACgkQ9mn/Pj01uKW7BwCfW/NAEpzIBrI1zXPso84rW7fk
U7YAoJ+rZt28jgF8JBa4+9nYAj/uPv0e
=N4Gg
-----END PGP SIGNATURE-----

--TRYliJ5NKNqkz5bu--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100605000934.GB20023>