Annoucing bish-bosh: A POSIX shell script client for MQTT 3.1.1 that runs on almost anything

Skip to first unread message

Raphael Cohn

Jan 20, 2015, 6:21:26 AM1/20/15
Today I'm announcing the prerelease of bish-bosh.

bish-bosh is a MIT-licensed shell script client for MQTT 3.1.1 that runs without installation on any POSIX system on any POSIX shell: Linux, Mac OS X, Cygwin, AIX, FreeBSD, OpenBSD and NetBSD are all known to work, as are the DASH, GNU Bash and BusyBox shells. There are usually no dependencies at all if you're using BusyBox. For everything else, it's a very minimal set of helper programs that even the most basic of POSIX-compatible systems should have. Installation can be as simple as cp bish-bosh /path/to. It'll run on your router, high-end server, your smart phone, laptop or even an unlocked BT fibre modem. It supports QoS 0 - 2, retransmission on re-connect, will messages, retain, ping, err, nearly everything really, bar a few very minor edge cases (

bish-bosh is available on GitHub:
Releases are at
There's an extensive at

It's a command interpreter that can be used to script MQTT sessions, or built into bigger standalone programs. For example:-

#!/usr/bin/env bish-bosh

# We've got a message
    # bish-bosh handles QoS 1 and 2 for us

    # bish-bosh wires stdout to be data to send, so we need to redirect to stderr
    printf '%s' "Received a message on topic ${topicName} which was ${messageLength} byte(s) long and is in the file ${messageFilePath}" 1>&2

    # clean up
    rm "${messageFilePath}"

 Partly, it was written because I like software that can be used without installation, anywhere. And partly, as MQTT Co-Chair, I really wanted to show the wider audience aware of MQTT that it's a such a simple, robust protocol we've all had a hand in making that it can be implemented in almost anything and run almost anywhere.
I'm open to widespread re-use - if folks want to incorporate in Mosquitto packages or Paho, for example, please do - just respect the license, and, if you can, give acknowledgment. I really want folks to contribute and make bish-bosh better, so here are some requests:-

* Would a broker variant be useful to you? It'd certainly be cool, and ultra-portable
* Does anyone have a modern HP-UX set up, or access to all supported HP-UX versions, to see what breaks (HP-UX is suitably weird)?
* Does anyone want to try this out with Open-Wrt or Tomato?
* Can someone check for Gentoo and Arch Linux compatbility?
* I can't install DragonFlyBSD on my hypervisor (Parallels) - can anyone check if it works there?
* Likewise, I can't get MINIX 3 to talk to a network
* Is anyway out there an expert with Solaris 10 or 11? Can you see if there's a way we can make this work without the workarounds?
* Does anyone care about yash?
* Would someone like to add it to the list?

I'm minded to post a link to Hacker News later. If you like bish-bosh, then please star it on GitHub or vote it up on Hacker News if I do post ('Show HN:'). It's good not just for bish-bosh, but to raise awareness of MQTT. Half of all good applications should use message queuing; most don't, simply because their developers are simply unaware.



Jan 21, 2015, 12:48:22 PM1/21/15
Wow this is awesome! Thank you very much for doing all this work and the really comprehensive documentation. I work with OpenWRT a lot and would really love to try it out on it. This is really perfect for it. I really love how it's all based on command-line so it can be easily piped around with other programs. Especially with Lua which is one of the few scripting languages on OpenWRT but it's a really nice and small language.
One idea I had was to make a daemon exposing a sysfs layer with something like /var/mqtt/topic/blah that could be read or written to, but it might be more trouble than it's worth; esp for configuring QoS for each message and all that. Piping around text is just fine and simpler.

I was also thinking to add another back-end to use the axTLS library and its HTTP client because of how heavy OpenSSL and LibreSSL are on OpenWRT. But this limitation is mostly on COTS systems like the TP-Link MR3040 (one of my favourites) and its measly 4MB of flash. Most of the other Atheros AR9331 modules available these days come standard with 8MB or 16MB of flash memory which can much more easily fit the heavier TLS/SSL libraries. And those are the ones I'd end up integrating to my clients' hardware anyway. But if anyone is very interested in the axTLS part, I could take a look.

Raphael Cohn

Jan 22, 2015, 8:19:05 AM1/22/15
Yes please!

Actually, messages can also be shell scripts themselves (Just source each message. Hmm.)

Essentially, writing a new TLS backend is nothing more than implementing a couple of functions - take a look at some of the others, eg

BTW, there's a bug when running on OpenWRT (the fattened binary fails because of a bug in my version of bash that generated it) - should have a new release for the weekend, or just rsync over the git repo instead (having init'd all the subodules) for now.

Raphael Cohn
Chief Architect, stormmq
Co-Chair, OASIS MQTT Standard
Secretary, OASIS AMQP Standard

UK Office:
Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, United Kingdom
Telephone: +44 845 3712 567

Registered office:
16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom
StormMQ Limited is Registered in England and Wales under Company Number 07175657

To learn more about MQTT please visit
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To post to this group, send email to
Visit this group at
For more options, visit

Reply all
Reply to author
0 new messages