Sure you’ve read the books on writing fancy code. But who needs commenting or clarity when you’ve unleashed the power of bash? First of a two-part series on the Red Hat Magazine.
How I Learned to Stop Worrying and Love the Command Line
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
> The goal is to become more efficient, solve
> problems that otherwise would be very time
> consuming, and maybe, just maybe, impress
> people while we’re at it.
“Efficiency” is a factor of how easy it is to understand and maintain the code you write, full stop.
You simply spend more time reading and fixing a piece of code than the computer ever spends *executing* it, and even *if* you should come across a piece of code that has to be “efficient”, don’t for a second believe efficiency and clarity are mutually exclusive.
Remember me to strangle that guy should he ever walk through the door of my office to work on the same project as me.
I’d say every > 1 employee company would require every script to be written clear and documented properly. Makes me wonder how things are run at Red Hat’s..
Besides that i can’t quite see where bash comes in. Seems to me all the proposed tricks will work just as fine in a normal bourne shell (/bin/sh) as well.
Or is the use of bash standardised for scripts these days in the linux world ? I’m using BSD for a while now so i got quite out of touch on these things but i prefer a minimalistic aproach where possible..
The author was not talking about scripting or writing programs – he was talking about one-off one-line commands to acheive a quick goal, at the command line, as a sysadmin. Readability does not matter in such a situation, because you type the command and move on.
The few examples of multi-line scripts he did give led on quickly to how you could do the same thing in one line (ie. at the command-line).
Of course, as you point out, writing shell scripts is a completely different kettle of fish and necessitates readability and good comments. I did not feel that this was the focus of the article at all though.
I thought this was a reasonable introduction to the power of the shell, and as far as I could see it was appropriate to sh and ksh as well as bash (although bash is far nicer to use at the command line IMHO, which is where the focus of the article was).
I look forward to the second article.
Since the article brought it up and for some reason I was thinking about Perl when I read the article title, I was curious if distros are slowly moving over to Python for the glue language of distros? I know Ubuntu (my home distro) has Python as a semi-official development language.
Over on slashdot.com, the topic of OSS is raging yet once again about in part the maintainability of code and how OSS helps, and where in the scaling of a project OSS becomes a problem. And this brings to me a subtopic of interest, code commenting. I’ll say it here too, if we all had the luxury of time to get to know a technology, use it as a tool and art, the code would speak for itself needing little to no documentation. The security of a job is long gone in the 80s, we all jump ship for the golden promises of pitchmen (and women), so we have only ourselves to blame for our inability to read our own code, let alone those around us… We simply don’t have the luxury any more, and that choice is our own not society’s. Its a tough one to make, yet nevertheless one that anyone complaining about code reuse or readability needs to decide. Perpetuate the problem, or stop and say enough while mastering the art of readability and reuse.
rm -rf *
Todd writes:
“we have only ourselves to blame for our inability to read our own code” “We simply don’t have the luxury any more, and that choice is our own not society’s.”
I say Bull. If I don’t comment much, or well, its because my company underbid a project and I have 200 hours to do 500 hours worth of work. I (and my boss) am not concerned about code reuse, comments, or anything like that. They want a product as soon as possible, that’s all. Not my choice.
Gentoo’s killer app, emerge, uses Python.
Don’t forget to >emerge app-emacs/pymacs
so that you can call your python from within elisp.
—quote—
They want a product as soon as possible, that’s all. Not my choice.
—end quote—
It’s your choice. You always have a choice, and in this case you’ve chosen to work in a situation where your performance is at times less optimal than others. You’re losing out on great experience by settling for sub-optimal experience. This is not a bad thing, as long as you’re working hard to achieve the stronger experience, and not lacking in the sub-optimal performance for the mere sake of meeting sub-optimal criteria.
I’m not getting onto anyone required to work in a situation like this. You have to weigh for yourself what’s good and what needs improvement, even when crunched for time. However, mediocrity is never an option, lest unemployment lines greet you with a most unpleasant appeal.
“If you want it bad, you get it BAD.”
“…who needs commenting or clarity…”
Typical linux hacker/developer.
Things like it talks about in the article is why the CLI is powerful
he is so right about
foo=$(command)
being better than
foo=`command`
it’s better readable, easier to troubleshoot (some guys mistake ` for ‘) and it even survives msword better (yeah, who wants to use msword for bash programming? but sometimes you want to document something for the windows guys in outer space)
Instead, I add such things to my script (or alias) library, since I’ve found that a lot of those “use once and throw away” items can make very good templates for more generalized tools, or are sometimes useful again when I’m working on something much larger.
The end result is a fairly modular set of scripts and shell aliases which are built in layers from other scripts and aliases. Quite flexible.
(I’ve been creating and collecting such things in my specific environment since 1991, so I’ve had time to create a semi-extensive infrastructure).
>windows guys in outer space
<Your Mars lander joke here>
‘ll say it here too, if we all had the luxury of time to get to know a technology, use it as a tool and art, the code would speak for itself needing little to no documentation.
Unfortunately not. Code is implementation, and in its myriad details obscures the ideas behind it. To use an metaphor: you fail to see the forest for the trees. And even if code were good at conveying ideas, it would still take longer to read and understand the code than to read a comment.
If I don’t comment much, or well, its because my company underbid a project and I have 200 hours to do 500 hours worth of work.
Nonsense. Writing/updating comments takes only seconds – I do it almost automatically – but it saves you valuable minutes later during debugging. And I am speaking from experience.
Hello
Maybe one can use “echo *.txt” instead of “find . -name ‘*.txt’ -maxdepth 1”
In this particular case it seems the same. Am i right?
he is so right about
foo=$(command)
being better than
foo=`command`
it’s better readable, easier to troubleshoot (some guys mistake ` for ‘) and it even survives msword better (yeah, who wants to use msword for bash programming? but sometimes you want to document something for the windows guys in outer space)
Back ticks are more portable than the bracket notation.
— quote —
Don’t forget to >emerge app-emacs/pymacs so that you can call your python from within elisp.
— /quote —
At first glance, from the corner of my eye, I misread this as “call your python while asleep.” And I thought, leave it to an emacs guy to figure out how to hack while asleep!
😉
Why not? <your nightmare language here> could not possibly have come from the conscious, or even those with conscience.
> Maybe one can use “echo *.txt” instead of “find . -name ‘*.txt’ -maxdepth 1”
> In this particular case it seems the same. Am i right?
No. The whole reason he’s using find is because it’ll work in cases where the shell’s globbing (changing *.txt into the list of filenames it matches) would exceed the maximum length of a command line (which would cause, obviously enough, it to fail.)
echo *.txt and ls *.txt both rely on the shell to do the globbing (and in fact, have no control over it; it’s done before they get the arguements.) echo would, in fact, be slightly worse than ls, as it’s two characters longer.
The advantage of find is that you quote the arguement to it, so that the shell doesn’t expand it – and it then proceeds to go through and find the files which matches itself. A process can use a rather large amount of memory if necessary; a commandline is fixed to a relatively short maximum length (somewhat over a hundred thousand characters on my current system; it sounds huge, but every once in a while, it’s not enough).
“echo *.txt” simply echoes the string ‘*.txt’. That’s it.
>> “echo *.txt” simply echoes the string ‘*.txt’. That’s it.
You forget that the shell expands the asterisk to a list of files in the cwd.