tero

My favourite would be 'sudo apt-get autoupgrade'. It does not exist, but would upgrade everything, right now, no questions asked.

I wonder why 'sudo unattended-upgrade -v' does not do an unattended upgrade when run.

ps. Thanks for linking my article, speckx.

Those pta example files you linked, marttt, really make the case for this software. It looks simple, transparent, auditable, versionable and unixy.

Dpifke, beancounter looks nice, big and well tought out. I bookmarked the docs/ to have a more troughout look at it later.

Update: Had a more detailed look on Beancount.

Based on the man page, calendar(3) would not suit my use well. It's quite different from calendar.txt. But I'm happy to hear that you use it.

I installed it just to read the man page: """

           LANG=C
           Easter=Ostern

           #include <calendar.usholiday>
           #include <calendar.birthday>

           6/15\tJune 15 (if ambiguous, will default to month/day).
           Jun. 15\tJune 15.
           15 June\tJune 15.
           Thursday\tEvery Thursday.
           June\tEvery June 1st.
           15 *\t15th of every month.

           May Sun+2\tsecond Sunday in May (Muttertag)
           04/SunLast\tlast Sunday in April,
           \tsummer time in Europe
           Easter\tEaster
           Ostern-2\tGood Friday (2 days before Easter)
           Paskha\tOrthodox Easter

"""

So many tempting options...

Can you recommend a tool and open your accounting workflow, marttt?

Are there any pain points, like filling tax forms or handling travel paperwork?

It's unfair to computers how well paper planners worked. Among with todo.txt, paper calendars were an inspiration and a benchmark for writing calendar.txt.

I especially like your 'mgrep', please do write it!

I have considered similar tools that make use of MarkDown syntax, I feel that there are many tools waiting to be written here.

As you guessed, roland35, I do track my calendar.txt in git.

One main benefit from git is also to work as an insurance against (user) errors, and make the whole process much more transparent. When I have used calendars with automatic synchronization, I would have enjoyed a "change log" to make sure that my timezones and meetings are not mistakenly modified by software.

For your dentist example, I would probably just use 'grep' or find in my text editor. After all, six months of days is very little text.

Interesting ideas for formalization and metadata, jeroendh. Some comments on those:

Calendar.txt is indeed a personal calendar. So feel free to violate the spec as much as you need or want to. My main use for calendar.txt is editing with text editor, and thus, I have not given emphasis to automatic modification.

Time notation is ISO-8601 date and week number. In my view, ISO-8601 is an international standard and not tied to a specific country. I find it convenient to read and sort.

I use local time for physical events. For international calls, I just write down the timezone "13:00Z" or "11:00EET" (update: or mark it in my local time).

At-sign "@" for context was chosen to match todo.txt, as I also use that. As the calendar is personal, it does not need to be fully machine readble. But for your example on email addresses, you could still do it: @WORK email [email protected]. The context starts with an at "@", email does not.

Full stop "." is easy to type on a cell phone. It's true that a rare char would be more suitable for automatic parsing.

Thanks for the ideas!