Bash-Fu(bash-fu.com)
bash-fu.com
Bash-Fu
http://bash-fu.com/
7 comments
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.
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...
http://ruby-doc.org/stdlib/libdoc/fileutils/rdoc/index.html
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
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
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?
If you're going to make a site and call it bash-fu, shouldn't you make sure your bash is at least good?
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
http://i.imgur.com/ya8WI.png
That's strange. It looks fine on FF4 using Snow Leopard.
http://d.pr/LXvR
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.
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.
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.