- sh (I really don't use bash features in scripting)
- awk
- perl
- sed, if that counts as language.
It's funny that a course that I took in university almost 29 years ago, for learning the use of Unix scripting tools, is one of the most useful learning experiences in my daily work today - even if my job is not really a programmer. But very often I see colleagues (project managers, architects etc) struggle with processing information in ways that involve a lot of repetition and manularity. Scripting solves those things.
(For some things also Excel and VB perhaps counts as an "old" programming language; it is also often quite useful. And I probably will end up doing something in C again this year.)
Any suggestions for a bash scripting tutorial to help me better connect the dots? Over the years I've learned some nifty one-liners, but I'm not really familiar enough with the patterns and art of of command-line thinking to solve my own problems in bash. Most of the bash resources I've found online are just loosely organized collections of magic spells. I'd really like to get better at it though.
The resource that has been instrumental for me to move up from beginner-that-generally-can-work-out-things-with-a-lot-of-random-tries, to someone who often has things right on the first try, and if not, have a clue of what is going on , has been the following book:
Classic Shell Scripting
Arnold Robbins, Nelson H.F. Beebe
Recommend it to anyone with a basic understanding and a will to learn more. It also really doubles as a rich information resource. Cannot recommend it enough if books are your thing.
I would recommend two things: 1. Read the "bash" man page about once a year, and 2. Learn Perl or Python or something for the harder tasks.
It's helpful to learn some more about bash, and there's some good stuff in there. But shell scripts above a few dozen lines tops are a bad idea, and even those "few dozen" lines need a surprising amount of armoring with "set -e" and such.
I don't think this is because bash is bad. I've come to the conclusion that there's a fundamental tension between interactive use and safe programmatic use, and anything really good at the one is not going to be good at the other. In particular, interactive users more-or-less want the shell to accept inputs that are a bit sloppy, because they can interactively recover from the vast bulk of misinterpretations immediately, whereas a program becomes very risky with the same level of sloppiness because it will quite likely just keep going, doing very bad crazy stuff. (Which is why all my shell scripts tend to start with "set -e", which amounts to "If you get confused... STOP, instead of trashing an arbitrary amount of state.")
And again let me emphasize #1. By splitting my world up into interactive use and programmatic use, I've made my peace with shell, and I don't hate it or anything. I use a lot of the features interactively. For instance, I do a lot of little loops on the command line. Often I'll build them up with some "echo"s done to make sure that it's about to do what I think it will do. There's a lot of great ways to save time in interactive bash (or zsh or whatever), and the best part is, in interactive use you can be as crazy efficient as you want and there are no software engineering implications. Writing bash scripts with every crazy sophisticated trick in the books starts raising software engineering issues fast, and worst of all, some of them are quite invisible ("what if you run this in a directory with a file with a space in it? a newline? a file called '-rf'?"), to say nothing of whether the next person working on the script will know what all the fancy operations do. And I've got a decent-sized collection of 5-line bash scripts lying around doing various things. I just don't let them get much longer.
One of the most useful things to do is just load up an index in your head of what bash can do, then know you can look it up if you ever want it.
(Substitute your choice of shell for bash throughout.)
[Shameless plug] Not too long ago, I wrote a small book that tries to address those kinds of questions, i.e. how to use Bash to solve problems instead of 1-liners. You may find it useful: http://adventuresindatascience.com
Too true. When I was 13 or so, I read the DOS 5.0 manual from cover to cover. If I recall, a lot of it was about batch files (autoexec.bat and stuff). Batch was really my first "programming" experience.
Then when I was 22, after a good computer science education, my first job was working at EA, and the build system involved a bunch of batch files. That knowledge from nearly a decade before came in handy! The CS stuff didn't come up until later.
I find that clear notetaking is amazing in guiding discussions. Being the one who sends out the meeting summary with next actions and clarifying remarks or being able to refer back to meeting notes gives me an amazing power in making decisions or resolving disputes. Just because I'm the one who's writing stuff down, I'm somehow given the authority to say "this is what we decided at the meeting".
It varies. I'm often tinkering, which is a problem, I know. I've used a notebook, a Surface pen and One Note, a text file, scribbles on the agenda for the meeting (if there was one). It depends if it's a teleconference or not, whether my laptop battery is charged, if I can find a nice pencil, etc. etc. as well.
The summaries always go out as emails, of course, and if I paper note-take, I try to take a picture and upload it to onenote or sharepoint.
We use a record feature in Zoom for our teleconferences that we want to save, but notes are always better because you can review conclusions without the noise of skipping through discussions. It'd be amazing if there was an application that recorded meetings then summarized them.
I am not who you were asking, but I exclusively use pen and paper during meetings. I try to keep my laptop closed and transcribe action items to a personal trello board after the meeting is done.
The trello part is more recent, but I have notebooks going back to my first internship in 2012(which I know isn't that long for most here). It's pretty interesting to see old notes I took and the problems I had at the time.
I've found that the more attention I pay to my notes, the better I recall the topic at hand even without referring to the notes I've taken.
As a result I exclusively use pen-and-paper for meetings. I also started using fountain pens about two years ago and the discipline required to write well, especially with vintage flexible nib pens, helps keep me focused on note-taking.
I'm not a native English speaker. I could throw in that the best thing regarding learning I did (in addition to buying a home computer) was to get J.R.R. Tolkien's The Hobbit (which came with the adventure game) which in turn led me to read LOTR and then other books in English, and generally become much more fluent.
Later on, wasting time reading NNTP news at the uni was also actually a good investment for learning the language in a way that is useful at work.
For my kids, the games have again been the same thing, along with Harry Potter books.
That's interesting. Whenever my dad wants to become more comfortable with a new language, he reads the translated editions of Harry Potter, too! He's read "Harry Potter and the Philosopher's Stone" in Dutch, French, Arabic, Mandarin, and Spanish, lol.
And the ten minutes striking up a conversation with that strange kid in homeroom sometimes matters more than every other part of high school combined
Wow, that is pretty weird. That was true for me in college. I was at home after graduating in January 2002, at the bottom of the dot com bust. It was hard to find a job then.
I took this world music course in college, and I remember I talked to this guy who was also a computer science major, and he told me he was going to EA. Probably 6 months later, I e-mailed him out of the blue, and that got me the internship which led to my first job.
So instead of all the computer science stuff, I should have just relied on connections from the world music course and on my DOS batch file knowledge from age 13 :)
Very true with perl, although for me it came a bit too late: Larry Wall published first version of Perl at the time of that course, so it obviously wasn't in the content, and I did the stuff with sh, sed and awk, and perl has unfortunately always been a bit of an afterthought for me (I have to look at a manual in some simple things where with awk I don't).
Seriously! I learned so much about scripting and networks in my high school programming classes because a group of us just wanted to play Quake 3 and CS 1.6 instead of doing assignments, and we needed to get around whatever software they had in place to monitor whether you were slacking off.
I'm not proud of it (and I'm not going to share the code) but I wrote a CMS for a medium-traffic site entirely in bash and standard unix tools like awk/grep.
It should be an absolute clusterfuck but it's been surprisingly reliable and performant, to the point where I have no desire to replace it.
If you can't show the code, can you give any info about the overall design of it? I can't even think how you'd structure a "large" application in shell scripts.
This is how many web apps in 1999 ran. As long as you treat your inputs carefully and properly handle file locking, there's nothing inherently bad about that approach.
- awk
- perl
- sed, if that counts as language.
It's funny that a course that I took in university almost 29 years ago, for learning the use of Unix scripting tools, is one of the most useful learning experiences in my daily work today - even if my job is not really a programmer. But very often I see colleagues (project managers, architects etc) struggle with processing information in ways that involve a lot of repetition and manularity. Scripting solves those things.
(For some things also Excel and VB perhaps counts as an "old" programming language; it is also often quite useful. And I probably will end up doing something in C again this year.)