Gammu: a command line tool for talking to GSM phones

A phone tool older than the smartphones it manages

Gammu is a library and command line utility for mobile phones, released under GNU GPL version 2 and written in C.

The history in the readme explains the shape of the project. It was initiated by Marcin Wiacek and other people, and the code was originally based on Gnokii, and later on the MyGnokii project. Gammu was itself formerly called MyGnokii2, up to version 0.58. Today the project is led by Michal Cihar with help from many contributors.

That lineage matters for anyone evaluating it in 2026, because it says what the tool actually targets. This is a tool for talking to a phone over a serial or USB modem interface, in the GSM tradition, not a library for the mobile operating systems that came later. The subjects are feature phones, USB modems, and embedded modules, and the interface is a command line with a configuration file rather than an app.

The project site is wammu.eu/gammu, the source is on GitHub at gammu/gammu, and the readme points at both. Feedback and bug reports go through the GitHub project page, and there is a donation page at wammu.eu/donate for anyone who wants to support the work.

The repository holds four programs, not one

The top level of the tree is the quickest way to understand the scope of the project.

`libgammu` is the core library, with `include` holding its public headers. The `gammu` directory is the command line utility that most people use, `gammu-detect` is a separate helper for identifying connected devices, and `smsd` is a distinct component that runs as a daemon for handling SMS traffic, which is the piece you leave running on a server rather than the piece you type commands into.

Around those sit `helper`, which is shared support code, `admin`, `utils`, `installer`, `contrib` and `tests`, plus `docs` for the manual, `locale` for translations, and `description-pak` for the desktop integration files that let the tool appear in a Linux menu.

The build and packaging side is equally traditional for a project of this age. There is a `configure` script at the root next to a `CMakeLists.txt`, a `Makefile` that wraps the CMake build, a `gammu.spec` file for RPM packaging, a `ChangeLog`, a `COPYING` file for the licence text, and `INSTALL` files in more than twenty languages, from Czech to Ukrainian, each named with its language code such as `INSTALL.de` and `INSTALL.fr`.

That last detail is a good sign about the project's priorities. A tool that still ships localised installation instructions in twenty languages is a tool whose user base includes people for whom the command line is not in their first language.

Configure first, then make

The build is CMake, but the entry point is the familiar configure script, and the Makefile exists to drive the CMake build rather than to replace it. The Makefile header says it wraps the CMake build as used by configure and provides some operations that can be done on source.

The build directory is fixed as `build-configure`, and the rule that creates it is a guard rather than a convenience:

$(BUILD_DIR):
	@echo 'You should run configure before running make!'
	@exit 1

So running make in a fresh checkout stops with a message telling you to run configure first, instead of failing with a confusing missing directory error. It is a small piece of user care in a build system that has been carrying this convention for a long time.

From there the targets delegate into the build directory. The useful ones for a developer are the test target, which passes an argument through to the test runner:

test: $(BUILD_DIR)
	$(MAKE) -C $(BUILD_DIR) test ARGS=--output-on-failure

There are also targets for `package` and `package_source`, for `apidoc` and `interndoc`, for `translations`, for `cppcheck` as a static analysis pass, and for `Nightly` and `NightlyMemoryCheck`, which are the continuous integration entry points. A `tags` target generates a ctags index across the C and C++ sources, and `distclean` removes the build directories and the tags file.

The manual is a build target

Gammu's documentation is unusually well organised for a utility of this kind, and it is built rather than written in a wiki.

The manual lives in `docs/manual`, and the readme says you can build the HTML version of it with `make manual-html`, which is viewable online at docs.gammu.org. The Makefile shows the range of output formats the project supports:

manual-html: $(BUILD_DIR)
	$(MAKE) -C $(BUILD_DIR) manual-html

There are parallel targets for `manual-ps`, `manual-latex`, `manual-man`, `manual-htmlhelp` and `manual-pdf`, so the same source produces a PDF, a LaTeX document, a man page, a standalone HTML help file and a PostScript version. A man page in particular is what makes a command line tool feel native on a Unix system, because it is what `man gammu` will show.

The internal documentation targets, `apidoc` and `interndoc`, produce reference material for the library, which matters because `libgammu` is a public interface and not just an implementation detail.

Translations are handled through Weblate, with a translation status badge in the readme, and the `translations` make target is how the catalogues are refreshed. Between the translated manual, the translated installation instructions and the man page, Gammu is a project that has clearly spent a long time being used by people other than its authors.

smds is the piece that runs unattended

The `smsd` directory holds a separate component from the command line client, and its existence tells you how the project is used in practice.

A tool that manages a phone interactively is a tool you run when you have a problem. A tool that manages a phone unattended is a tool you deploy: on a server, on a kiosk, in a lab, or on a machine that talks to a modem over a fixed serial port and needs to react to incoming messages without anyone pressing a key. The `smsd` directory is where that half of Gammu lives, and the name of the top level binary in the Makefile, `gammu`, sitting next to it, shows the split clearly.

The readme itself is short and does not describe the daemon in detail, which means the documentation for it sits in the manual rather than in the README. That is where you should look before deploying it, particularly for the configuration file format and for how the daemon decides which messages to act on.

The `admin` and `utils` directories belong to the same picture: they are the small pieces of operational tooling around the two main programs, and they are typically the sort of code that a project keeps for a long time without touching.

Lint, coverage and packaging in one repository

The quality tooling tells you how the project is maintained, and it is modern in the places where it matters.

The Python configuration at the root runs ruff with `output-format = "github"` and a rule selection of `ALL`, followed by a long ignore list. The list itself is a good summary of the project's character: `S101` for asserts, `D203` and `D211` for docstring formatting, `E501` for line length, `PLR0913` for too many arguments, `BLE001` for blind excepts, and a long tail of others. A project that turns on every ruff rule and then explicitly suppresses a hundred of them has decided exactly where it wants to be strict.

There is a `codecov.yml` for coverage reporting, a `.pre-commit-config.yaml` for local checks, a `CONTRIBUTING` file and a `CODEOWNERS` file, and the tests live in their own directory with a test target wired into the Makefile.

Packaging is handled by `gammu.spec` for RPM based systems and by the `description-pak` and `installer` directories for the desktop integration, while `configure` and `CMakeLists.txt` cover the build itself. The `utils` and `contrib` directories hold the smaller pieces that do not fit elsewhere.

Two directories deserve a mention for a project this old. `locale` holds the translated message catalogues, and `.weblate` configures the translation platform, so the translation workflow is integrated with the source tree rather than kept on a separate server.

A steady release line and a wide support surface

The release history shows a project that still ships. Version 1.44.1 was tagged on 2026-08-19, 1.45.0 on 2026-09-16 and 1.45.1 on 2026-10-19, and the last push was on 2026-10-19, the same day. The default branch is `master`, and the repository is not archived.

The version numbering tells you how far the project has come, since the readme mentions that it was called MyGnokii2 up to version 0.58, and it is now past 1.45. That is a project with a quarter of a century of continuity behind the same name, in a niche that most vendors abandoned long ago.

The support surface is the other thing that makes it unusual. The project has to talk to a very long tail of hardware, from phones to modems to embedded modules, and each of those has its own quirks in AT commands, in cable behaviour and in memory formats. That knowledge is the real asset in the repository, and it is largely encoded in the driver code and in the ChangeLog rather than in prose.

For that reason, when you hit a device specific problem, the ChangeLog is often more useful than the manual, because it records which devices were fixed in which release. The manual at docs.gammu.org is the place to start, and the GitHub issue tracker is the place to end up if the behaviour is not documented.

Editorial conclusion

Gammu suits anyone who needs to script against a GSM modem, whether that is an old feature phone, an embedded module or a laboratory device, and it suits people who prefer a command line to a vendor application. It is a poor fit for modern smartphones that expose no serial interface, since the whole design assumes a modem you can talk to over a cable, and a poor fit if you need a maintained upstream for your operating system's package repository, because the build is a manual configure and make flow. Before you adopt it, read the manual for your modem in the `docs/manual` directory, check that your distribution's package is current, and remember that the source of truth for a device quirk is usually the ChangeLog rather than the documentation.

Frequently asked questions

Official sources

1. gammu/gammu on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases