# calcurse: a calendar that lives entirely in the terminal

> calcurse is a C program for managing appointments, events and todos in a terminal, distributed as a BSD-2-Clause package and built with autotools on top of ncurses and gettext. It has been maintained for over a decade, and its default branch is named pu.

**lfos/calcurse** — A text-based calendar and scheduling application

- Repository: https://github.com/lfos/calcurse
- Website: https://calcurse.org
- Stars: 1,313 · Forks: 129
- Language: C
- License: BSD-2-Clause
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/lfos-calcurse

## A calendar as a terminal program

calcurse is described in one line as a text-based calendar and scheduling application, and the screenshot in the README is an animated demo of it running in a terminal. The audience it serves is not stated explicitly, but the shape of the software answers that question. A text-mode calendar that keeps its appointments, events and todos in files on disk, draws an interface with ncurses and speaks gettext for translations, is a tool for people who live in a shell, run it on a small machine over SSH, and want their schedule to be a text file they can grep, diff and back up. There is no account, no vendor and no service, which is the whole appeal and also the whole limit. The project is hosted under the lfos organisation, its homepage is calcurse.org, and the licence is BSD-2-Clause with the terms in the COPYING file. The repository publishes no GitHub releases, so the versioning story is in the CHANGES.md file and in the distribution packages, and the build has a CI workflow for building and testing plus a separate workflow that lints Python, which is a hint that part of the project's tooling is Python even though the program itself is C.

## Installation is a package manager away, on most distributions

The primary installation story is the one most Linux users will meet. calcurse is available on a number of Linux distributions, and the README links a repology badge showing the packaging status across distributions and versions, which is the standard way to see which releases have been packaged where. That is the right path for most people, because the dependency set below is not trivial. Building from source requires the following build dependencies: gcc, autoconf-archive, automake, autopoint, asciidoc which is only needed for building documentation and can be skipped with --disable-docs, gettext with development files, and ncurses with development files. The README adds a caveat that if your distribution segments development files from core packages, that is, the *-devel or *-dev packages, you may need to install those as well. That caveat is the whole story of building small C programs on modern distributions: the compiler is rarely the hard part, the headers are. If a distribution package exists for your system, use it, because it has already resolved that problem.

## The source build, and the one step a git checkout needs

If you do build it, the sequence is the familiar autotools one. From a release tarball:

```bash
./configure
make
make install
```

and the note that make install needs to be run as root. If you are working on a git checkout rather than a tarball there is one extra step, and the README is clear about it: you need to run ./autogen.sh before ./configure. That is the standard bootstrap for a project that ships a generated configure script in its tarballs but not in its repository, and skipping it is the single most common failure for someone who clones and runs configure straight away. The source overview in the README then explains the layout, which is worth reading because it names a few directories that are not obvious. src holds the actual calcurse source files. test holds the test suite and test cases. doc holds detailed documentation in plain text and HTML. po holds the translations and i18n-related files. build-aux holds auxiliary files for the build process. scripts holds additional official scripts, such as calcurse-upgrade. And contrib holds useful tools such as hooks or the CalDAV synchronization script.

## contrib/ and scripts/ are where the calendar grows

The two directories that reveal how calcurse is used in practice are contrib/ and scripts/, and they are deliberately not part of the core. contrib/ collects useful tools such as hooks or the CalDAV synchronization script, which is the answer to the obvious objection that a text-mode calendar cannot talk to your other devices. The approach is characteristic of the project: rather than build a synchronisation client into the program, the project ships a script that other people can adapt, and the user wires it up. scripts/ holds additional official scripts, and calcurse-upgrade is the one named, which is the migration path when the on-disk format changes between versions. That separation is the design principle of the whole project. The program is a terminal application, the data is files, and the integrations are things you run alongside it. The doc/ directory holds detailed documentation in plain text and HTML, which is convenient for a project whose users are on a machine with no browser, and po/ holds the translations, with the gettext dependency in the build list because of it.

## A project with a named history and a documented patch process

The authorship section is the most human part of the README. calcurse was created by Frederic Culot in 2004. Since 2011 the project has been maintained by Lukas Fleischer, and many core features added to calcurse since 2017 were designed and implemented by Lars Henriksen. Beyond those three, the project points to the Git commit log and to the Thanks section in the manual for the wider list of people who have contributed by reporting bugs, sending fixes or suggesting improvements. The patch process is documented rather than improvised. Patches, bug reports and other requests are welcome, and you can submit them to one of the mailing lists, with the details in the patch submission guidelines in doc/submitting-patches.txt, or via GitHub. Both routes exist because a project of this age has users who read their mail and users who do not, and the guidelines file is where a first-time contributor finds out what a patch is expected to contain. The project also asks for donations, which it says help it continue developing calcurse as open source software and are used to cover recurring costs such as servers, with a one-time payment option at calcurse.org/donate/ and an invitation to contact them for other forms. The .mailmap file in the tree is a small sign of the same care, since it keeps author attributions stable as a project outlives the people who commit.

## The branch named pu, and why there are no releases

One structural detail deserves a note because it will confuse anyone who clones the repository. The default branch is pu, and the repository publishes no GitHub releases. Since no releases are published, a user who clones and builds the default branch is not building a tagged release, and the CHANGES.md file at the root, not a tag list, is the record of what changed. This is a project that distributes through the Linux distributions, which is also why the absence of GitHub releases is not a red flag. Packagers take a release tarball, and the tarball is what the make install instructions are written for. The last push to the repository was on 2026-08-05, so the working branch is being maintained, and the timeline of the project as described in the README, created in 2004, maintained since 2011, with substantial feature work since 2017, is consistent with a codebase that is still moving.

## Where calcurse is the wrong tool

The limits follow from the format. First, there is no shared calendar. A calcurse installation is a set of files on one machine, and the CalDAV script in contrib/ is an adapter you have to set up, not a turnkey sync, so a team that needs a shared family or work calendar is looking at the wrong tool. Second, the terminal is the interface, and that is a real constraint for reminders: the program draws a calendar and a todo list in a terminal, so anything that needs to interrupt you while the terminal is closed, on a phone, or on another machine is outside what it does. Third, the surface area of a curses interface is small by nature, and a user who wants to search across years of appointments graphically, or who wants a web calendar, will not find it here. The honest alternative in that case is a graphical CalDAV client backed by a server, which is a heavier dependency chain but gives you a real shared calendar and a browser. The other alternative is the truly minimal one, a plain text file of appointments with a reminder job, which for one person's schedule is often enough and costs nothing to maintain. calcurse sits between the two, and it earns its place when you want a calendar with structure, lists and filters that you can drive entirely from a keyboard in a terminal.

## Conclusion

Adopt calcurse if you want a calendar that runs over SSH on a small machine, keeps its data in plain files, and does not need a graphical client or an account with a calendar vendor. Do not adopt it if you need shared calendars, mobile sync, or reminders that reach you while the terminal is closed. Before you install it, read doc/ for the file format, note that the default branch is pu and carries unreleased work, and plan for the fact that distribution packages are the supported path while the source build needs the full autotools toolchain plus ncurses and gettext development files.

## FAQ

### What is calcurse?

It is a text-based calendar and scheduling application written in C, licensed under the BSD-2-Clause licence and hosted under the lfos organisation. It manages appointments, events and todos in a terminal interface built on ncurses.

### How do I install calcurse?

The primary route is your Linux distribution's package, since calcurse is packaged across a number of distributions. To build from a release tarball you install the build dependencies and run `./configure`, `make` and `make install`, where the install step needs root. From a git checkout you must run `./autogen.sh` before `./configure`.

### What does calcurse need to build?

gcc, autoconf-archive, automake, autopoint, gettext with development files and ncurses with development files. asciidoc is only needed for the documentation and can be skipped with --disable-docs, and on distributions that split development files you may also need the corresponding devel or dev packages.

### Does calcurse sync with other calendar services?

The repository does not include synchronisation in the program itself. The contrib/ directory holds useful tools such as hooks or the CalDAV synchronization script, and scripts/ holds additional official scripts including calcurse-upgrade for migrating data between versions.

### Who maintains calcurse?

calcurse was created by Frederic Culot in 2004, has been maintained by Lukas Fleischer since 2011, and many core features added since 2017 were designed and implemented by Lars Henriksen. Patches and reports go to the project mailing lists or to GitHub, and donations cover recurring costs such as servers. The last push to the repository was on 2026-08-05.

## Sources

- [Issues](https://github.com/lfos/calcurse/issues)
- [lfos/calcurse on GitHub](https://github.com/lfos/calcurse)
- [License: BSD-2-Clause](https://github.com/lfos/calcurse/blob/pu/LICENSE)
- [Project website](https://calcurse.org)
- [README](https://github.com/lfos/calcurse/blob/pu/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lfos-calcurse