Move files to the trash with a Swift script

Swift 3

I really don’t like using the ‘rm’ shell command – one misplaced character and you can do some serious damage. But when working in the Finder I don’t think twice about deleting files, because I know I can always get them back from the trash. So here is a Swift shell script which does exactly that – it moves files to the trash instead of deleting them permanently.

The syntax is very simple – all parameters refer to file system items which should be moved to the trash:

Read More

Splitting text read piece by piece

Swift version 2.1.

In the previous post we implemented lazy splitting of collections, very useful for say splitting large texts into lines. But in SwiftShell I need the same functionality for text which is acquired piecemeal, like the output of a long-running shell command read sequentially, when needed. Because shell commands which are piped together in the terminal should get to work right away, and not just hang around waiting for the previous command to finish. Like this:


Both scripts start at the same time. The left one uses the functionality implemented below, while the right one reads the entire input into a string first, and therefore has to wait for the ‘linemaker’ command to finish before doing any actual work.

Read More

Splitting text and collections lazily in Swift

Swift version 2.1

There are already methods for splitting collections in the Swift Standard Library, but they do all the work immediately and return the results in an array. When dealing with large strings, or streams of text, I find it better to do the work lazily, when needed. The overall performance is not necessarily better, but it is smoother, as you get the first results immediately instead of having to wait a little while and then get everything at once. And memory usage is lower, no need to store everything in an array first.

Read More

SwiftShell 2.0 Readme

I finally got around to updating the SwiftShell 2.0 readme with some actual usage instructions:


An OS X Framework for command line scripting in Swift.


Put this at the beginning of each script file:

Run commands

Print output

Runs a shell command just like you would in the terminal. If the command returns with a non-zero exit code it will throw a ShellError.

The name may seem a bit cumbersome, but it explains exactly what it does. SwiftShell never prints anything without explicitly being told to.

Read More

How to use Swift for shell scripting

To be honest I’m not very good at shell scripting. It’s very useful for automation so I would like to be, but I just don’t like the syntax. For instance, this is how you check if a variable is greater than 100:

And here’s how to check if the file referred to in the first argument is readable and not empty:

Enough said.

So I would much rather use Swift, as the syntax is nice, very nice indeed. But the things that bash shell scripts actually are good at, like running shell commands and accessing the shell environment, are not that straightforward in Swift. Here’s how you can perform the various tasks using only the Swift Standard Library and Foundation:

Read More

Redesigning an API – Swift 2.0 style

SwiftShell (an OS X framework for shell scripting in Swift) is currently using the |> operator to combine shell commands, streams and functions, and |>> to print the results:

But Swift 2.0 is here, and it’s clear the way forward is protocols, method chaining and error handling. And being more explicit about what is going on. So for SwiftShell 2 I’m planning something like this:

Read More

Swift: mixing default values and variadic parameters.


As of Xcode 7 beta 6, Swift no longer requires variadic parameters to be last in the function definition. Also argument labels are no longer required when combined with parameters with default values. So this all works fine now:

The rest of this post is deprecated.

Read More

Making a Numeric Type in Swift

Fabián Cañas demonstrates something similar to mixins in Swift (for operators):

By defining types (and protocols) around capabilities, and writing functions that target those capabilities, we end up with cleaner and remarkably reusable code when compared to implementing functionality targeting a specific type. The bulk of our final implementation has nothing to do with distances, time intervals, apples, oranges, or anything else. It reads more like a set of statements of fact that any future programmer could adopt if they so chose.

Swift: Associated Types

Russ Bishop has a clarifying post about Swift protocols and generics:

Type parameters force everyone to know the types involved and specify them repeatedly (when you compose with them it can also lead to an explosion in the number of type parameters). They’re part of the public interface. The code that uses the concrete thing (class/struct/enum) makes the decision about what types to select.

By contrast an associated type is part of the implementation detail. It’s hidden, just like a class can hide its internal ivars. The abstract type member is for the concrete thing (class/struct/enum) to provide later. You select the actual type when you adopt the protocol, not when you instantiate the class/struct. It leaves control over which types to select in a different set of hands.

But I do think he is too harsh on the functional programming hipster kids.

Writing a parser combinator in Swift

This post is part of a series on FootlessParser, a parser combinator written in Swift.

Before Swift my only contact with functional programming was a couple of half-hearted attempts at reading Erlang, all of them resulting in me running away screaming, clutching my aching head. But learning functional concepts in Swift proved far easier, probably because the syntax is closer to what I was used to. So I read Functional Programming in Swift and everything was well and good until one of the last chapters, “Parser Combinators”, and the headache was back. Luckily I managed to stay quiet and in place this time. I downloaded the code for the chapter, turned it into a framework and hacked away until I had implemented a CSV parser, but I still didn’t really understand it.

The parser library from the book has 6 swift files and more than 50 functions (including operators), all but 10 consisting of only one line. Stepping through the code in the debugger lead to a call stack a mile long which never seemed to reach a function that did some actual work and then returned, instead it appeared to be just functions all the way down. I don’t mean this as criticism of the chapter in particular or functional programming in general, it is more a description of my lack of understanding at that point. So to improve on that and understand functional programming and parser combinators better I am implementing one myself; FootlessParser.

The name comes from the scientific name for Swifts, “Apodidae”, from Greek “apous” meaning “without feet”. The word also has alternate meanings, depending on how the parser turns out it will either be apt or self-deprecating, in any case two of my favourite things.

I will write about the development here. There doesn’t seem to be any complete parser combinator frameworks in Swift out there, hopefully this will be useful to others as well.

BTW I really do recommend the book for anyone interested in functional programming and Swift, it is well written (and offers a real challenge in the last chapters).