[svlug] Evil Backquotes (was Re: how to copy a bunch of "." files?)

Tin Le tin at le.org
Wed May 17 11:55:06 PDT 2000


-----BEGIN PGP SIGNED MESSAGE-----


I am going to stop this discussion as it is getting into religious
territory.  I've found that is a waste of time :-)  We each have our
preferences and neither one is going to change the other' mind on it.

> > The "csh" that is shipping on Linux is really just a symlink to
> > tcsh.

> Bzzt, thanks for playing.  Both csh and tcsh are available for Linux.
> If your distribution doesn't offer you a choice of either or both,
> then your distribution is more limited and inflexible than mine.

I guess so :-).  It's just not that big of a deal to me, there's bigger
fish to fry.

A distro is just to save me time in configuring a system.  By the time
I am done, its layout does not look like any existing distro anyway.  I've
ripped out all the junk I don't care for.

> > And tcsh is not that bad.

> I vehemently disagree, but now we're down to matters of personal
> taste, which is a silly thing to argue about.  Personally, I think
> tcsh is one of the most evil programs to come along in decades.  But I
> freely admit that I have strong prejudices on the matter.  :-)

Umm, more like religious fervor? ;_)

> >  At least it is being maintained and bugfixed.

> The same is true of csh (at least within Debian).

Good to know.  Back in 1989, I submitted many bugs in csh to our bug
tracking system where I was working on a project porting SVR4 to MIPS.
I searched on the net and could not find anyone maintaining it (at
that time).  We fixed a lot of the bugs ourself, but kept finding
them popping up everytime we refreshed SVR4 source.  We submitted the
fixes to Bell Labs, but it did not seem to make a difference.  All our
fixes (for csh and other parts of SVR4) seem to have gone into /dev/null
:-(

> > The only thing I can see wrong with it is when people write csh shell
> > scripts.

> Yes, and this is the heart of the matter.  As long as people continue
> to promote csh to newbies, newbies will foolishly write csh scripts,
> because they've had to learn the basics of csh programming in order to
> maintain their own .login and .cshrc files.

People must be doing something strange, because there is no need to
"learn" csh programming to maintain .login and .cshrc files.  I setup
default dot files on all my system, and all people have to do is edit
vars in them.

If people are spending a lot of time customizing .login and .cshrc, then
they don't have enough work! :-)

> This is why I recommend that newbies avoid csh at all costs -- it will
> just make their life so much simpler to stick with a shell that they
> can actually use for scripting.

It depend on the user population.  A large number of users on systems
that I used to admin are afraid of command lines, so it does not matter
what the underlying shell is.

> > I had to untrained a number of my sysadmins on that bad habit.

> Haven't we all?  :-)

Ah well, it's worse with people coming over from the MS world... I am glad
I don't have to deal with that anymore.

> > One guy almost brought down our web servers because of his scripts.  I
> > turned him over to Perl and the problem was solved.

> Yes, I've had even worse experiences (no "almost" involved), which is
> why I feel so strongly on the topic.

It's good and bad.  I would rather not have any servers going down, but
nothing teaches better than experience.  It really brought across to all
my admins why csh shell scripts is bad.  They never do it again.

It was the perfect opportunity to educate them...

> Perl (or python) is almost always preferable for scripting.  But
> there's a learning curve involved.  The natural inclination for
> newbies is to experiment with the shell they're using.  Usually
> starting with the startup scripts, then moving on to more complex
> stuff.  If newbies were discouraged from using csh (or tcsh), then we
> wouldn't have anywhere near as many disasters caused by foolish
> attempts to use csh scripts.

I disagreed.  All of these are nothing more than tools.  You can shoot
yourself in the foot just as well with Perl, Python, whatever flavor
of the month lang on the net.

Again, from experience, I had a webmaster that brought down a server
because of his Perl scripts.

"...I don't know what happened.  It run fine on my system..."

Of course, on a single user system it runs fine, but not on a high traffic
web server!

> > But $() is not available in sh [...]

> It is in all the versions of sh I've seen that support backticks, and
> in a few that don't (HP).  I believe that POSIX mandates $() for sh,
> but not backticks.  (Probably worth checking on this.)

I know it's not in /bin/sh that is in Solaris 2.6.  I don't know about newer
Solaris, can anyone confirm?  There are still many sites running Solaris 2.6.

> > I guess because I am such a portability oriented person and because '$()'
> > was a feature that was not that much more useful (to me), I never tested
> > how widely $() is supported.

> This is probably the problem.  You've been assuming that $() isn't
> supported because you haven't been looking for it.  When, in fact,
> it seems to be a more portable solution than the one you settled on.

Not at all.  I do not use a new feature for the sake of using it.
There has to be a very strong reason for me to use something that could
potentially break existing code and/or does not work on previous system.
I am coming from a developer background and I always try to look for
portability and support of existing user base.

Code that I wrote 10-15 years ago should still compile and run today on
existing systems.  And will in the future.

> Or, if you've seen systems that support backticks but not $(), then
> the conclusion I'm forced to is that neither is very portable.  I
> admit I haven't tried every *NIX out there, just four or five.

I have not seen a system that does not support backticks for more than
15 years.  I do see systems now where /bin/sh does not support $().

> Oh sure, but people get so up in arms when you evangelize about the
> big issues.  I stay away from editor wars, from BSD vs SYSV flamewars,
> from MS vs *NIX vs Apple wars, and all those other wars that generate
> huge threads of noise and heat but little light.  I stick to the small
> quiet corners where I might, just possibly, be able to do a little
> good for the world.  :-)

Yeah, but backticks? ;-) sheesh!

> > If Linux can have less security problems reported in the media, it would
> > be easier for me to sell it to my clients :-).

> Perhaps you'd have better luck selling BSD?  Remaining flexible is one
> of the keys to a long and successful career!  ;-)

> I like Linux better as a desktop system, but I think I trust the BSDs
> a little more for serving.

I actually push whatever systems that work the best in a particular
situation for that client.  I lean toward Linux, but I am not fanatical
about it.  I've admin NT server farms, Exchange (blech!) and will keep
on doing it as required.  The thing to keep in mind is that there is no
single solution that works for everyone.

Life is too short to get hot and bother by all this stuffs :-).

Tin Le
- -- 
http://tin.le.org
Internet Security and Firewall Consulting
Tin Le - tin at le.org


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i

iQCVAgUBOSLrBxiIIbPkDHhBAQHeLAP/XbXkqts7VqrRyNDuAbC9SzIfDwyPfAwb
Y8TAU5bh0PSyI0uQLoFLki7yeJenfpcuOpqzNu2M1a0owfpe8OgO7XNWimL8qdCM
UW6BecGFs2qInGQvbvdUXJJJ5EkZC5CQz0jmpkgJFhhvjk2vcs3+/+/6YojB+aJH
PCyYgFZtuJI=
=XM4P
-----END PGP SIGNATURE-----






More information about the svlug mailing list