Had one coworker who left without any notice, just sent us a note saying "got a new job, won't be in". Sucked for the rest of us, we had to cover for him for a while.
I try not to burn bridges. I'm on my fourth consecutive job with the same group of people. (Two rounds of layoffs and one acquisition for punctuation.)
Anyone who wants to find me can, easily. So far, that's been more an advantage than a disadvantage. My manager's on LI; so's the next manager above that in my chain, and the VP above that. And they're all on my contacts list. When I applied for this job, I don't think it hurt me at all that they could quickly see that several of the staff knew me already. (As it happens, the guy making the hiring pitch already knew this, but that was blind luck.) I went to check this, and had a ping from a former coworker. Good deal; now I have one more sysadmin on my list of sysadmins I can contact if I hear about job openings...
I've had my own domains since the early 90s, and kept the contact information accurate. I've had my name and address up on the web since we were running NCSA httpd on an Amiga UNIX box, and so far, it's been all benefits, no harm. People who search for me on DejaNews (oh, are they calling it Google Groups now?) can find ~40,000 posts.
So people know what they're getting into if they want to offer me a job, and that means my time isn't wasted and theirs isn't either. Great.
That may be. I find Ruby much better than perl; perl always struck me as inherently ugly. Perl tolerates careful programming and writing for clarity; Ruby encourages it.
Python felt a bit too constrictive to me, if you'll pardon the pun. And I didn't like the indentation (although I grant the underlying intent, I just don't think it pays off enough).
Exactly -- you can't just "write for ksh", and even if you do, it's not universal.
You can do pretty well writing for a common subset of ksh88/pdksh, but I'd rather do the extra few minutes' work and write for plain old POSIX shell by default.
Autoconf is godawful crap, no doubt about it. But people still use it. You know why?
*IT WORKS*. It works on Linux. It works on Solaris. It works on BSD. It works on Tru64. It works on Cygwin. It works all over the place. A decently written autoconf script works for cross-compiling. It doesn't require a particular language to be installed.
I've used SCons-based projects. It was a nuisance to get it set up and working. Sure, it does some stuff nicely -- but I couldn't just grab it and use it on any possible target. (As I pointed out in my article about Second Life, this is an example of a good tradeoff for an internal tool...)
Engineering isn't always about picking the prettiest thing; it's sometimes about making tradeoffs, and figuring out what works in the environments under consideration...
Yes, you're quite right that this says a lot about poor user interface choices in some utilities.
Thinking about it more: One of the key applications of portability involves scripts which are never ported.
It's that I don't use only one machine. I use a Mac desktop, a BSD server, and some Linux servers. Even if I'm just typing "for i in..." on the command line, I don't want to try to remember three or four different sets of commands to work across these environments. I want to write things that work the same everywhere -- not just so I can run them multiple places, but so it doesn't matter which machine I'm on when I'm typing.
One of the points might be that there's a fairly specialized task which takes a person six hours to do, but which is NEARLY all done automatically -- just a bit of hand twiddling.
Lemme give an example that isn't portable. One of the things I do fairly frequently is take about six large toolchains distributed to me as binaries and source tarballs, and turn them into patches against upstream versions, reorganize them, delete some unused files, create configuration files that refer to the binaries, generate md5sums, and so on.
This is a task which, if I sit down at 10AM and start typing, is usually done by about 4PM. Testing takes a bit longer, and usually uncovers SOME kind of typo or thing I forgot to do.
Enter the shell script.
I tell the script where the files are, and I walk away. An hour later I have the results. Testing is also automated (another script). But testing is also uneventful, because the script never forgets a step, makes a typo, or otherwise screws up.
By the second time I did this, the script had saved me time. By the third, it had saved me close to a full working day. By now it's closer to a week of my time that wasn't spent messing with this stuff.
Portability isn't entirely crucial here, you might think? Well, not ENTIRELY crucial, except that when they had me start doing this on a new box running a different variety of Linux, the total time I spent revising the script was 0 minutes.
I wrote a wrapper around cdrecord to clean up the UI, automatically handle things like creating an isofs from directories, and so on.
It's not 100% portable; every new system, I change the path to cdrecord, the device spec for the CD drive, and the command used to eject a CD.
Everything ELSE stays the same, and I don't need to remember how to use mkisofs, or anything like it. Directories, bzipped images, whatever; it gets burned correctly. I win.
If the script were not written in otherwise-portable shell, it might not work on the broad variety of boxes I've wanted to use it on.
I've done scripts to handle tasks like "open this file" (not as flexible or smart as the OS X one, but quite good about various compressed tarballs and archives). Surprisingly portable.
I have a script for the idiom of "for every file named or provided as standard input, run it through this filter in place". Repeating commands at intervals, for a given number of times, until they fail... Tons of little utilities like this that save me time.
If you want complete applications with no dependencies, that's harder to find. That said... Have you ever used autoconf to configure something? That's a fair bit of portable shell right there...
And what "flush()" do you expect to see in a shell script?
You're thinking at a level that generally doesn't apply well to shell scripts. Scripts rarely deal with questions such as "has this been actually written to disk" -- because that's at the wrong level. If you need that information, you shouldn't be writing in shell anyway.
I compare C and shell all the time. Sometimes the answer surprises me. e.g., until I knew about printf(1), I sometimes went to C if I needed to pretty-print output. Now sometimes I don't.
I will happily mix and match multiple languages; one of my first shipping products was written in shell, perl, and C. Each did some things well that the others didn't...
I tend not to use Ruby for things that I want to be portable, because not everything has Ruby around yet. I tend to avoid Python because it just never "clicked" for me. I use perl for self-contained programs, but I don't like it very much for code that has to run other commands or manipulate files.
To this day, I've never found any of the competing languages to be as expressive as shell for things that are essentially sequences of Unix commands. If a task is something I would normally perform sitting at a prompt typing, I tend to find shell to be the language closest to the problem space.
I think "One does not write a web server in Bash" is like "One does not simply walk into Mordor." You're practically daring short people with hairy feet to attempt it.
Honestly, I just never got into python. I like perl (and hate it), and I like Ruby (and love it), but Python never "clicked" for me. Python and Tcl are the "scripting languages I just don't enjoy working in".
But... I also don't have it on everything I use. And I could get it, but that's another distraction from Getting The Job Done. So I do a ton of work in shell. Especially work that's entirely built around running other commands.
Sounds probably-correct to me -- it's definitely a derivative work or a performance. Those are both separate rights.
Speaking as an author, I would like to point out that CERN almost certainly has equipment capable of measuring the interval during which I cared whether someone, somewhere, was using a computer to "read" my book -- but I don't. All I have is conventional stopwatches.
Wouldn't it have been cool if someone had written a book on the common ground of the major shells covering how to use them as a single highly-accessible and universally-available language?:)
Well, I suppose because the contents are different. We're answering different questions.
I would never dream of discouraging people from looking at and using the various free guides out there. The autoconf manual is full of useful information about portability, too.
There's more than one article or book because there's more than one topic. "Shell Scripting" is not a single topic; "portable shell" is very different from "advanced bash". It solves different problems, and is useful for different circumstances.
Now, off the top of your head, what happens to variables set in the last component of a pipeline in ksh? Do you know whether it's the same on systems where "/bin/ksh" is actually pdksh?... Oh, and just for reference, about half the Linux systems our IT department installs don't have ksh. No, I don't know why. (I only know because I can't log into them because my default login shell is/bin/ksh...)
Slashdot Mirror
Had one coworker who left without any notice, just sent us a note saying "got a new job, won't be in". Sucked for the rest of us, we had to cover for him for a while.
I try not to burn bridges. I'm on my fourth consecutive job with the same group of people. (Two rounds of layoffs and one acquisition for punctuation.)
If you want to develop scripts, definitely use one of the Bourne derivatives; the POSIX subset's pretty livable.
For command-line interaction, whatever you're used to is probably fine.
Anyone who wants to find me can, easily. So far, that's been more an advantage than a disadvantage. My manager's on LI; so's the next manager above that in my chain, and the VP above that. And they're all on my contacts list. When I applied for this job, I don't think it hurt me at all that they could quickly see that several of the staff knew me already. (As it happens, the guy making the hiring pitch already knew this, but that was blind luck.) I went to check this, and had a ping from a former coworker. Good deal; now I have one more sysadmin on my list of sysadmins I can contact if I hear about job openings...
I've had my own domains since the early 90s, and kept the contact information accurate. I've had my name and address up on the web since we were running NCSA httpd on an Amiga UNIX box, and so far, it's been all benefits, no harm. People who search for me on DejaNews (oh, are they calling it Google Groups now?) can find ~40,000 posts.
So people know what they're getting into if they want to offer me a job, and that means my time isn't wasted and theirs isn't either. Great.
I think it's very likely that it reaches 99% of humans who have internet access.
Quick survey:
* Mac laptop: Yes
* Ubuntu desktop: Yes
* Eee running Ubuntu: Yes
* Sidekick: No
* Wii: Yes, I think?
So out of five browsing devices I have, four have flash -- but *I* can view flash content, even though some of my devices can't.
Large is relative. Compared to tr, grep, and sort, all sorts of things are "large".
Thanks for the feedback. Hope you enjoy the book!
"source" is a cshism, which happens to be handled by bash. The portable shell spelling is ".".
That may be. I find Ruby much better than perl; perl always struck me as inherently ugly. Perl tolerates careful programming and writing for clarity; Ruby encourages it.
Python felt a bit too constrictive to me, if you'll pardon the pun. And I didn't like the indentation (although I grant the underlying intent, I just don't think it pays off enough).
Exactly -- you can't just "write for ksh", and even if you do, it's not universal.
You can do pretty well writing for a common subset of ksh88/pdksh, but I'd rather do the extra few minutes' work and write for plain old POSIX shell by default.
sed -n -e '/<title>/ {
s/.*<title>\(.*\)<\/title>.*/\1/p
q
}' < musicbrainz.xml
Forgot that "plain old text" isn't. (To verify I had it right, of course, I pasted it into a file with the original and then ran
!sort | uniq)
sed -n -e '// {
s/.*\(.*\).*/\1/p
}' musicbrainz.txt
Of course, I think yours is skipping the first one; maybe it's an album title? I leave fixing that as an exercise to for the reader. :)
And then the whole script goes wildly crazy because it ends up in an unanticipated state? Sounds delicious.
There's times to abort in the face of error... and times not to.
You miss the point.
Autoconf is godawful crap, no doubt about it. But people still use it. You know why?
*IT WORKS*. It works on Linux. It works on Solaris. It works on BSD. It works on Tru64. It works on Cygwin. It works all over the place. A decently written autoconf script works for cross-compiling. It doesn't require a particular language to be installed.
I've used SCons-based projects. It was a nuisance to get it set up and working. Sure, it does some stuff nicely -- but I couldn't just grab it and use it on any possible target. (As I pointed out in my article about Second Life, this is an example of a good tradeoff for an internal tool...)
Engineering isn't always about picking the prettiest thing; it's sometimes about making tradeoffs, and figuring out what works in the environments under consideration...
Yes, you're quite right that this says a lot about poor user interface choices in some utilities.
Thinking about it more: One of the key applications of portability involves scripts which are never ported.
It's that I don't use only one machine. I use a Mac desktop, a BSD server, and some Linux servers. Even if I'm just typing "for i in..." on the command line, I don't want to try to remember three or four different sets of commands to work across these environments. I want to write things that work the same everywhere -- not just so I can run them multiple places, but so it doesn't matter which machine I'm on when I'm typing.
One of the points might be that there's a fairly specialized task which takes a person six hours to do, but which is NEARLY all done automatically -- just a bit of hand twiddling.
Lemme give an example that isn't portable. One of the things I do fairly frequently is take about six large toolchains distributed to me as binaries and source tarballs, and turn them into patches against upstream versions, reorganize them, delete some unused files, create configuration files that refer to the binaries, generate md5sums, and so on.
This is a task which, if I sit down at 10AM and start typing, is usually done by about 4PM. Testing takes a bit longer, and usually uncovers SOME kind of typo or thing I forgot to do.
Enter the shell script.
I tell the script where the files are, and I walk away. An hour later I have the results. Testing is also automated (another script). But testing is also uneventful, because the script never forgets a step, makes a typo, or otherwise screws up.
By the second time I did this, the script had saved me time. By the third, it had saved me close to a full working day. By now it's closer to a week of my time that wasn't spent messing with this stuff.
Portability isn't entirely crucial here, you might think? Well, not ENTIRELY crucial, except that when they had me start doing this on a new box running a different variety of Linux, the total time I spent revising the script was 0 minutes.
Portability isn't boolean.
I wrote a wrapper around cdrecord to clean up the UI, automatically handle things like creating an isofs from directories, and so on.
It's not 100% portable; every new system, I change the path to cdrecord, the device spec for the CD drive, and the command used to eject a CD.
Everything ELSE stays the same, and I don't need to remember how to use mkisofs, or anything like it. Directories, bzipped images, whatever; it gets burned correctly. I win.
If the script were not written in otherwise-portable shell, it might not work on the broad variety of boxes I've wanted to use it on.
I've done scripts to handle tasks like "open this file" (not as flexible or smart as the OS X one, but quite good about various compressed tarballs and archives). Surprisingly portable.
I have a script for the idiom of "for every file named or provided as standard input, run it through this filter in place". Repeating commands at intervals, for a given number of times, until they fail... Tons of little utilities like this that save me time.
If you want complete applications with no dependencies, that's harder to find. That said... Have you ever used autoconf to configure something? That's a fair bit of portable shell right there...
And what "flush()" do you expect to see in a shell script?
You're thinking at a level that generally doesn't apply well to shell scripts. Scripts rarely deal with questions such as "has this been actually written to disk" -- because that's at the wrong level. If you need that information, you shouldn't be writing in shell anyway.
But normally you don't...
I compare C and shell all the time. Sometimes the answer surprises me. e.g., until I knew about printf(1), I sometimes went to C if I needed to pretty-print output. Now sometimes I don't.
I will happily mix and match multiple languages; one of my first shipping products was written in shell, perl, and C. Each did some things well that the others didn't...
I tend not to use Ruby for things that I want to be portable, because not everything has Ruby around yet. I tend to avoid Python because it just never "clicked" for me. I use perl for self-contained programs, but I don't like it very much for code that has to run other commands or manipulate files.
To this day, I've never found any of the competing languages to be as expressive as shell for things that are essentially sequences of Unix commands. If a task is something I would normally perform sitting at a prompt typing, I tend to find shell to be the language closest to the problem space.
I think "One does not write a web server in Bash" is like "One does not simply walk into Mordor." You're practically daring short people with hairy feet to attempt it.
But your point is basically good. :)
Honestly, I just never got into python. I like perl (and hate it), and I like Ruby (and love it), but Python never "clicked" for me. Python and Tcl are the "scripting languages I just don't enjoy working in".
But... I also don't have it on everything I use. And I could get it, but that's another distraction from Getting The Job Done. So I do a ton of work in shell. Especially work that's entirely built around running other commands.
Look up the word "defamation". There is actually something of a right not to be talked badly about in some very specific cases.
Sounds probably-correct to me -- it's definitely a derivative work or a performance. Those are both separate rights.
Speaking as an author, I would like to point out that CERN almost certainly has equipment capable of measuring the interval during which I cared whether someone, somewhere, was using a computer to "read" my book -- but I don't. All I have is conventional stopwatches.
Wow. That's a really brilliant question.
Wouldn't it have been cool if someone had written a book on the common ground of the major shells covering how to use them as a single highly-accessible and universally-available language? :)
Well, I suppose because the contents are different. We're answering different questions.
I would never dream of discouraging people from looking at and using the various free guides out there. The autoconf manual is full of useful information about portability, too.
There's more than one article or book because there's more than one topic. "Shell Scripting" is not a single topic; "portable shell" is very different from "advanced bash". It solves different problems, and is useful for different circumstances.
Sounds great.
Now, off the top of your head, what happens to variables set in the last component of a pipeline in ksh? Do you know whether it's the same on systems where "/bin/ksh" is actually pdksh? ... Oh, and just for reference, about half the Linux systems our IT department installs don't have ksh. No, I don't know why. (I only know because I can't log into them because my default login shell is /bin/ksh...)