Hacker News Reader

Comment by e1ven | Hacker News Reader

Oh, Man, I can't agree. I LOVE using bash for quick scripting, because I can use the same commands I use when I run them in the shell.

Doing a quick

  for i in `seq 1 15`; do ssh www$i.website.com "reboot"; done

is VERY convenient. It's fast, quick to write, and extends existing shell knowledge.

This would be very useful in all sorts of sysadmin places.

Imaging that I wrote a quick server, in Python/Rails/Node/whathaveyou, that accepted input, then returned a formatted JSON array with server info.

Now, I can do

  $SERVERLIST = `curl http://my-server/list-of-servers`
  for i in ```$SERVERLIST.webservers.list()```; do ssh $i "reboot"; done
  for i in ```$SERVERLIST.dbservers.list()```; do ssh $i "uptime" >> serverload.txt; done

View on HN

Doing a quick [...] is VERY convenient.

I agree! If you do this a lot then you might be interested in GNU parallel. It's super handy!

    seq 1 15 | parallel ssh www{}.website.com reboot

http://www.gnu.org/s/parallel/

I've found that Perl works even better for this.

my @allfiles = `ls /somedir/`; for my $file (@allfiles) { chomp $file; ... }

Is a wonderful thing. It's not pretty Perl, but it's still better than Bash, IMO.

I think his point is that he can do the above directly from the command line.

Dude.

    my @allfiles = glob '/somedir/*';

Now you properly report errors and you don't have to chomp.

I write tons of little mostly throwaway scripts in bash/sed/awk/etc. But I never had a bash script that grew to reasonable complexity that I wish I hadn't just started in Python.

Each tool has a purpose -- I don't think mucking around with json is particularly suitable for bash...

Have a look at fabric - it makes things like that pretty simple. Also agreeing bash is not a language for serious coding.

You (and everyone else who feels this way) need to take a look at the startup scripts for your favorite Linux distro.

If you mean the repetitive spaghetti of pseudo text processing in init.d, then yes I've seen it. Everything tries to do the same stuff in a different way, there's lack of one framework, error checking is present only in random places and any script can hang because there's no real timeout handling. They're also different in almost every distribution and some are incompatible between sh/bash and very few people can tell the difference. The whole idea is one level too low and we're finally growing up to use something simpler.

That's one of my "favourite" examples of using scripting where it's not needed. Have a look at what's actually keeping critical systems working -> inittab, supervisord, etc. Lately upstart also migrated from scripts to something more declarative.

Edit: forgot the bit where everyone "parses" the output of commands like `ifconfig` and pretends they will never change, or will never fail, or will return the information in the same format. How many scripts relied on grepping ifconfig output for "inet" before "inet6" broke the startup?

Ultimately the point was that shell scripting shouldn't be used for "serious" programming. Yet it has been used for decades to accomplish and automate some of the most important tasks on UNIX/Linux systems. I happen to know and work in several "serious" programming languages, and yet I can knock out a functional, reliable, and understandable shell script in a fraction of the time it would take many people to do the same in X.

Since it's tracking on HN, I'll also point this out: http://www.leancrew.com/all-this/2011/12/more-shell-less-egg...

That mess of redundant code, bad practices and unfit toolset would only prove our point further.

You mean the scripts that start thousands of processes before my computer is even ready to use? Especially things like sed, awk and perl just to do some text processing?

Reply on news.ycombinator.com