Understanding regular expressions can be hard and for a lot of people it seems too hard.
It’s not that hard and the benefits can be huge. Not to mention once learnt you will be astonished at where they can come in handy, it’s not just in
sed commands in your scripts. I often use it in my favourite text editor, BBEdit.
At the moment I’m working on extending
jss_tools so that it has coverage of the JSS data for mobile devices.
This requires building some large arrays containing the XML paths to the data and the dictionary keys used to store the data and building those arrays could be a tiresome task.
Instead I dump the XML into a file and then copy the bits of it I want into another text file before using the power of search and replace to turn that list into the array.
At my current employer we use JAMF Pro to manage a medium sized fleet of Macs and that means talking to the back end JSS if we want data.
The tool to talk to your JSS from Python is Crag Shea’s
python_jss. The big problem you then hit is that it returns XML. In the case of a computer record in tje JSS tha’s 2500 lines of ugly XML. I couldn’t find a parser that would correctly parse it so have to fall back to using Elementree to pick it apart piece by piece.
That leads to ugly code that’s hard to follow.
So I decided to write
jss_tools, a set of functions that takes the XML and converts it to Python data structures and converts the XML data strings to Python types.
I’ve long used a bash function to allow me to read man pages in Preview
# function to send man page to preview
man -t $* | open -f -a /Applications/Preview.app/
-t sends the output of man through groff and converts it to PostScript so we can then pipe it to Preview which happily displays it.
This doesn’t work well for any other command as you need to do some fiddling to get groff to do the conversion for you. Happily
enscript, which can be installed with Homebrew, is much easier to use than groff. For a single command this function works well.
$* | enscript -q -p - -f Menlo-Regular10 -F Menlo-Bold10 -b "$*|%W|Page $%" | open -f -a /Applications/Preview.app
Once again this year I will be teaching a “bash Beginners” workshop at the AUC’s World conference.
I’ve started re-working and improving the workshop and I’ve decided to spend at least some time on regular expressions in
awk as they are so often the hard bits of shell programming. Sorry about that cough, must have been some terrible syntax caught in my throat.
Do you know how hard it is to find a good regular expression experiment and demonstration tool that is compatible with those venerable tools? Well nigh impossible. Perl, Ruby and cough PHP compatible you can find but not for those two.
The first thing I discovered is that when you go to install iTerm2’s shell integration it checks to see what shell you are using by reading the variable $SHELL, which is your accounts default shell, not necessarily the shell you are running.
Since my corporate Active Directory account sets my default shell to
/bin/ksh (don’t ask, just don’t ask) this caused me a problem. In iTerm my default profile is set to run the command
/bin/bash rather than my default shell. So to get shell integration installing properly I now set
SHELL='/bin/bash' at the bottom of my bash profile.
So I’m now using Ulysses for writing. Not coding, for that I’m still with BBEdit, but writing text of any sort. It seems quite an attractive editor, it supports MarkDown and things seem to work well.
I’m writing this as a test of it as a blogging platform. Of course the first thing to do is see what text looks like when I export it to WordPress from within Ulysses. Here, for example is some emphasised texrt and here is some strong test Let’s try a list
- We have the first item in an unordered list
- Now we have the second
That was the whole list.
- An ordered list
- So can you pick up items and reorder them
- We will see
If you delete or reorder it doesn’t update the numbers in your document but it is correct on export.
So how about we throw in
I don't like Ulysses needs a marker at the beginning of every code line.
I found this in my email archives. I hope you can enjoy it as much as I do.
One of my friends (he was one of my most pleasant customers at Sydney Uni) many years ago wrote me an email asking me a tech question. It was February 2008 and we were both upset by the New England Patriot’s loss in Super Bowl LXII that ruined a perfect season.