In the previous two instalments (17 & 18) of this series we learned how to represent patters with regular expressions, or, to be more specific, with POSIX Extended Regular Expression (or EREs). We used the
egrep command to test our regular expressions, but we didn’t discus the command itself in detail. Now that we understand regular expressions, it’s time to take a closer look at both
egrep, and it’s older brother
grep, both commands for filtering and searching text.
This blog post is a companion document to two Chit Chat Across the Pond segments I will be recording with Allison Sheridan on the NosillaCast over the next two weeks. The first of the two shows is now out, and and can be found here. One the second show is out I’ll add that link in too.
In episode 474 when Allison was chatting with Donal Burr about Apple’s new Swift programming language said she didn’t understand what a compiler was, so I thought it might be fun to try address that! But rather than focus in on just that one very specific question, I thought it would be more useful to take a high-level look at computer programming in general, so that some of the conversations around various developer platforms will make more sense to the majority of NosillaCast listeners, who are non-programers.
I’m betting most people won’t be interested in this, but if anyone’s curious how this programmer goes about building up a perl module from scratch, you can watch along on as I build XKPasswd 2.0 over on GITHub: github.com/bbusschots/xkpasswd.pm.
I’m re-implementing XKPasswd from scratch. The resulting functionality will be mostly the same, but with some additions. The reason for starting over is two-fold. Firstly, the first implementation of XKPasswd was very much a prototype, and as with any prototype, I learned some valuable lessons, and there are lots of things I’d do differently if I was doing it again. Secondly, the first version of XKPasswd is almost three years old now, and since then, my Perl skills have increased a lot. Probably the single biggest difference between the me of 2014 and the me of 2011 is that I read Perl Best Practices, and started to run all my Perl code through Perl Critic. Another big difference is that, thanks to JQuery, I’ve fallen in love with Code References in all the languages I use that support them, including Perl.
Since this is a re-write, I’m really focusing on building a solid foundation, so I’m starting with the utility functions that will let me build up functionality gradually, and I’m writing the user documentation in parallel with the code. Before every commit to GITHub, everything that’s done so far is getting documented with POD, and, the code has to pass Perl Critic with no warnings.
In the previous instalment we introduced the concept of Regular Expressions, and started to learn the POSIX ERE regular expression language, noting that POSIX ERE is a sub-set of the very commonly used Per Compatible Regular Expression (PCRE) language.
In this instalment we’ll learn more POSIX ERE syntax, and have a look at some examples of REs in GUI apps.
Quite a few months ago I was joking with Guy Serle of the My Mac Podcast, and the topic somehow turned to flag semaphore. I think I’d sent the guy an iTunes review in mores code for a joke, and then Guy challenged me to do it in flag semaphore. I figured it would be easy to find a converter on the net, but, for the first time in a long time, the internet let me down! When I couldn’t find a converter I registered the domain www.semaphorify.info with every intention of getting a converter up and running in a few days. Then, real life got in the way, and the domain sat there for months, until yesterday, when I unexpectedly had a free afternoon, and I finally got my converter written!
You can now go to the site and convert text to flag semaphore, play a crude animation of the signal, and even share a link to the signal. E.g. this link takes you straight to the conversion of “I love semaphores” to semaphore.
This instalment is the start of a series of instalments relating to searching from the command line. Searching is all about patterns, and that means getting to grips with Regular Expressions (also called RegExps, RegExes or REs for short). Regular Expressions are languages for representing patterns, and are used throughout IT, not just on the command line. While this series focuses on the Terminal, an understanding of regular expressions will be helpful in many other places, from programming languages to GUI apps like programming editors, search utilities or file re-namers. It’s going to take us two instalments to properly describe regular expressions, but when we’re done we’ll have gained a very useful skill.
I sometimes take some stick for having a very defensive coding style. When ever I find myself making an assumption I throw in code to test it. “This function will only ever be called with a positive number”, OK, then add a test to throw an exception should a negative number be passed. You don’t want bad data ricocheting through your code because goodness knows what damage it will do! Similarly, my style is to always use explicit syntax, and, to avoid syntax shortcuts – sure, the ternary operator takes up less space on the screen, but there’s a price to pay for that terseness – it makes your code harder to read and hence to debug and maintain.
However, one of my very biggest bug-bears is the failure to brace control statements like conditionals and loops when they’re operating on a single line of code. This is the trap Apple fell into so spectacularly this week.
In the previous instalment we introduced the concepts of streams, and looked at how every process has references to three streams as part of their environment –
STDERR. We went on to introduce the concept of operators that manipulate these streams, and we focused on the so-called ‘pipe’ operator which connects
STDOUT in one process to
STDIN in another, allowing commands to be chained together to perform more complex tasks. We mentioned the existence of operators for connecting streams to files, and the possibility of streams being merged together, but didn’t go into any detail. Well, that’s what we’ll be doing in this instalment.
Right back in the very first instalment we described the Unix philosophy as being Lego-like, that is, having lots of simply commands that do one thing well, and then assembling them together to do something really powerful. So far, we’ve only been working with a single command at a time, but that changes with this instalment. We’ll be introducing the concept of streams, which can be used to connect commands and files together.
In the previous instalment we looked at how to make permanent changes to our environment. We made a permanent change to the
PATH environment variable to demonstrate how it’s done (by editing
~/.bash_profile on a Mac, or
~/.bashrc on Linux). In this instalment we’ll look at two other kinds of environment changes you may wish to make by editing these files – specifically, aliases, and custom prompts.