NAME
biff -- be notified if mail arrives and who it is from
[…]
HISTORY
The biff command appeared in 4.0BSD. It was named after the dog of
Heidi Stettner. He died in August 1993, at 15.
Eric Cooper, a student contemporary to Foderero and
Stettner, reports that the dog would bark at the mail
carrier,[4][5] making it a natural choice for the name
of a mail notification system. Stettner herself
contradicts this.[3][6]
Heidi would bring her dog with her to class and to her office. He was a very friendly dog, and a lot of the students enjoyed throwing a ball for him down the corridor to fetch. He even had his picture on the bulletin board with the graduate students: the legend read that he was working on his Ph.Dog. John decided to name the program after the dog: Biff. According to Heidi, John and Bill Joy then spent a lot of time trying to compose an explanation for biff - they came up with "Be notified if mail arrived." Biff, who died in August 1993, at 15, once got a B in a compiler class. According to Heidi, the story of Biff barking at the mailman is a scurrilous canard.
One of my favourite bits of trivia from that excellent book, but hardly anyone I bump into these days knows anything about that kind of multi-user Unix experience/environment these days. I barely caught any of it myself.
The name comes from the fact that Biff is a character in Back to the Future, and it rhymes with Jiff[1]. Jiff is the datetime library that Biff uses.
"Make like a tree and get out of here!" https://www.youtube.com/shorts/9Jabplo2pZU
So if I do an "apt install biff" on Debian (or Ubuntu) what will happen?
* https://packages.debian.org/search?keywords=biff
If I type in "biff" on a Debian CLI, what should I expect the behaviour of the program that is executed to be? Will it be something about mail or time?
collisions, lol
% apt-cache search biff
biff - a mail notification tool
gnubiff - mail notification program for GNOME (and others)
wmbiff - Dockable app that displays information about mailboxes
xlbiff - mail notification pop-up with configurable message scans
I think fewer people now care about mail notifications in a terminal session than about wrangling datetimes on the command line.
The use case is: "I want to see a list of all files in a repository, sorted in ascending order of when it was most recently changed according to source control. I also want to highlight the time with color, make it be in local time and format it in my own bespoke way using strftime." Here's the full command (run from the root of https://github.com/BurntSushi/ripgrep):
$ git ls-files |
bttf tag exec git log -n1 --format='%aI' |
bttf time in system |
bttf time sort |
bttf time fmt -f '%a %Y-%m-%d %H:%M:%S' |
bttf untag -f '{tag}|t{data}'
...
Thu 2025-10-30 13:30:14 crates/ignore/Cargo.toml
Sat 2025-11-29 14:11:38 crates/core/flags/lowargs.rs
Wed 2025-12-17 11:38:12 tests/misc.rs
Wed 2025-12-17 11:38:12 tests/util.rs
Thu 2026-02-12 20:39:46 crates/ignore/src/default_types.rs
Fri 2026-02-20 16:06:29 crates/core/flags/config.rs
Fri 2026-02-27 11:25:19 GUIDE.md
Fri 2026-02-27 11:25:19 crates/core/flags/defs.rs
Mon 2026-05-25 23:56:53 CONTRIBUTING.md
Tue 2026-05-26 08:32:43 AI_POLICY.md
$ git ls-files |
bttf tag exec git log -n1 --format='%aI' |
bttf time in system |
bttf time cmp ge 2026-01-01 |
bttf time cmp lt 2026-04-01 |
bttf time sort |
bttf time fmt -f '%a %Y-%m-%d %H:%M:%S' |
bttf untag -f '{tag}|t{data}'
Thu 2026-02-12 20:39:46 crates/ignore/src/default_types.rs
Fri 2026-02-20 16:06:29 crates/core/flags/config.rs
Fri 2026-02-27 11:25:19 GUIDE.md
Fri 2026-02-27 11:25:19 crates/core/flags/defs.rs
Instead of running `git log -n1` on every file, I think you can walk through the commits backwards, skipping any files that have been seen. Something like this (these two commands could be followed by bttf commands):
git log --pretty=format:"DATE:%aI" --name-only |
awk '/^DATE:/ {date=substr($0, 6); next} $0!="" && !seen[$0]++ {print date, $0}'
git ls-files |
awk '
# Read all existing files from git ls-files into an array
NR==FNR { lsfiles[$0]; next }
# Process the git log stream
/^DATE:/ { date=substr($0, 6); next }
$0!="" && ($0 in lsfiles) && !seen[$0]++ { print date, $0 }
' - <(git log --pretty=format:"DATE:%aI" --name-only)I'll have to noodle on this one. `bttf tag exec` works with arbitrary commands that can print any kind of date. But your approach require a different access pattern. I can either specialize the use case in bttf (blech) or I can figure out how to generalize your approach.
I think the key issue here is probably that it isn't line oriented. bttf composes well, but only when you have a one-to-one relationship between date and data. (Or a many-to-one is also supported, but it's many dates to one datum, not one date to many datums.) So maybe that relational model is worth figuring out how to streamline. Then I think this use case would work better.
Also, thank you! This is exactly the kind of reply I was hoping for! :D
In terms of machine time? I'd guess so, but I'd also guess calling it for each of `git ls-files` is not the fastest way to get the most recent commit of all the files in a typical scenario (large repo, recent time of interest, most files not changed that recently). And especially if you're okay assuming the most recent commit by parentage is the one you want (even if parentage doesn't match chronological order); then filtering with `git log --name-only --since` (no path argument) seems better. A `git log` post-processing script could also stop early if it's seen a commit for each the files of interest (again, assuming you don't want to return a later date that is attached to an ancestor commit).
Anyway, cool tool, and it's rare that I would actually care about the machine efficiency of this pipeline enough to bother with the approach I just described.
And yeah perf probably doesn't matter much. But, like, running my approach on the Rust compile repo takes at least minute on my beefly (if a little dated) machine. But lukasgelbmann's approach only takes about 11 seconds. That's a big improvement.
Yeah though, perf here may not matter much. It's just an example use of bttf that is less than instant. (And it's not really bttf. It's my examples access pattern of git.)
Fun fact: ripgrep started as something to dog-food the regex crate (with a focus on performance). I didn't originally build it to release to end users funnily enough. To be clear, I'm not implying bttf will follow the same path. I honestly probably agree with you at this point. I wouldn't have 1 year ago though.
My big hypothesis is that tokens are going to get much more expensive. Either that or OpenAI/anthropic are going bankrupt. I’m almost excited to find out, I have to admit.
Your remark just reminded me of this, I went a bit off topic, I admit.
I think Gemma 4 is also a good example of a capable small model.
I mention these not only because they're cheap but because they can run on consumer devices. The "every year bigger and more capable SOTA model" trend is mirrored by "the every year smaller and more capable open source model" trend.
2026 M05 28, Thu 17:27:46
Ahh, the month of M05
$ BIFF_LOCALE=en-US biff
Thu, May 28, 2026, 6:38:09 AM EDT
$ BIFF_LOCALE=watwat BIFF_LOG=warn biff
2026-05-28T06:39:08.876336708-04:00[America/New_York]|WARN|src/main.rs:76: reading `BIFF_LOCALE` failed, using unknown locale `und`: failed to parse `BIFF_LOCALE` environment variable: The given language subtag is invalid
2026 M05 28, Thu 06:39:08
$ BIFF_LOCALE=watwat biff time fmt -f '%c' '1 month'
2026 M06 28, Sun 06:39:50> The new name, bttf, is a backronym for "biff, time to format!"
It credits this comment:
https://news.ycombinator.com/item?id=48307552
However, "back to the future" might be more memorable. I'm surprised they didn't see it.
Jiff (the underlying Rust crate) gets this from Temporal in TC39, which is the first time JS standards have led anything datetime-shaped. Hopefully the rest of the ecosystem catches up — Python's `zoneinfo` only landed in 3.9 and `datetime.timezone` still has sharp edges.
Using +4 or +5 explicitly instead of a time zone when DST is relevant is bad juju. Then your arithmetic can become silently wrong in subtle ways when it cross a DST boundary.
$ bttf time seq monthly -w 2-tue -u 1y | bttf time fmt -f '%c'
Tue, Jun 9, 2026, 11:15:11 AM EDT
Tue, Jul 14, 2026, 11:15:11 AM EDT
Tue, Aug 11, 2026, 11:15:11 AM EDT
Tue, Sep 8, 2026, 11:15:11 AM EDT
Tue, Oct 13, 2026, 11:15:11 AM EDT
Tue, Nov 10, 2026, 11:15:11 AM EST
Tue, Dec 8, 2026, 11:15:11 AM EST
Tue, Jan 12, 2027, 11:15:11 AM EST
Tue, Feb 9, 2027, 11:15:11 AM EST
Tue, Mar 9, 2027, 11:15:11 AM EST
Tue, Apr 13, 2027, 11:15:11 AM EDT
Tue, May 11, 2027, 11:15:11 AM EDT
Implementing the RFC 5545 recurrence rules was quite a lot of fun: https://github.com/BurntSushi/biff/blob/4c75d5cf6e09310e74ca...
I'm quite proud of it, because if you look at the implementation, it's almost entirely about dealing with the specification rules. All of the datetime bullshit (including handling time zones) is all deferred to Jiff.
Plus, the tests are nearly 4,000 lines. While the implementation is 2,000 lines.
The comparison with GNU date is also likely informative.
same with macports
so it is pretty much not existing, cause I am not getting some binaries and drop them into some folder for some command line tool