Hacker News new | past | comments | ask | show | jobs | submit login
Bash-Fu (bash-fu.com)
57 points by mrleinad on March 24, 2011 | hide | past | favorite | 21 comments



You know, I work at the command line all day, and I'm always happy to learn a new trick. But for writing actual scripts, I'd much rather write in Ruby. I don't want to have to use awkward syntax like case statements ending with "esac."

Yes, using Ruby introduces a dependency beyond Unix. But I already use lots of libraries (Rails, Rspec, etc) and tools (ImageMagick, Ghostscript), so I don't see that as a problem, just part of the job.


Indeed, I've long ago adopted the convention to do any remotely advanced scripting in a "real" scripting/programming language (myself, I use Python for this).

Bash scripting is good for running a few commands in a sequence, but in my experience gets unmaintainable and unreadable very quickly, especially if you try to do sane error handling/logging, or operations on non-text data.


Agreed. Although I should add that it's still great to call out to the standard Unix toolset when it's the easiest way to get something done. The accepted answer here illustrates that: http://stackoverflow.com/questions/4714043/what-is-the-best-...


A quick...

    require 'fileutils'
    include FileUtils
...and you can almost pretend you are writing bash.

http://ruby-doc.org/stdlib/libdoc/fileutils/rdoc/index.html


FileUtils is a step back as far as I'm concerned. In fact, all the file-stuff is both ill-documented and anti-ruby-readability.


What does this minimalistic page offer except links to (already) rather well-known Bash resources? Am I missing something?


PS

I can't edit my post anymore, but I remembered that there is a similarly named site for command line tricks:

http://www.commandlinefu.com


The bash-fu is weak within that site.


I'll use command lines like that when I just need to get something done (after verifying that there are no files named "foo.sym"), but to write a script that uses a hard-coded filename that could stomp on other files is pretty bad. If you have a symlink foo and a file foo.sym, you've just erased foo.sym. The script also leaves all the .sym symlinks behind; it's not clear that this is the desired behavior.

If you're going to make a site and call it bash-fu, shouldn't you make sure your bash is at least good?


I was also really bothered that the script failed to handle filenames that may contain spaces correctly.


Good catch.


Exercise: make repl_links.sh work also when filenames contain blanks.



What's up with the difficult colors? I'm using Chrome 10 beta on OS X 10.6.

http://i.imgur.com/ya8WI.png


That's strange. It looks fine on FF4 using Snow Leopard.

http://d.pr/LXvR


I think it was a reference to the color scheme in the screen shot, not to the site itself. I find choices like dark blue and brown against black to be hard to read.


You've probably got a low-quality LCD with a bad color calibration, then, or else just a really bad contrast ratio or lots of glare. That color scheme doesn't seem to me to have any colors that would clash, even to colorblind and partially-colorblind people. Sure, it's a relatively low-contrast color scheme, but I think it would be generally harder to read if the contrast were really high. You shouldn't use much in the way of full-intensity colors when you have a black background.


It looks like it is a modified version of normal emacs highlighting for shell scripts to me; the colors are different from the defaults on my computer but not wildly so.


It's merely an accurate representation of the difficulty involved in writing bash scripts, as compared to just about everything else.


More like POSIX shell fu - the example doesn't actually use any Bash-specific features.


Seeing #!/bin/bash is one of my pet peeves.

If it's a straight shell script, use "#!/bin/sh" please. If the script actually requires bash features, I'd appreciate "#!/usr/bin/env bash" because if I choose to install bash, it probably won't be in /bin.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: