Also, as my unenlightened colleagues insist on using ridiculous tools like MS Word to author papers in, it's useful to have Zotero installed for the ability to link a BibTeX file to a WYSIWYG word processor when collaborating. Zotero helps you play well with others.
I don't think Zotero is perfect by any stretch, but I'm glad that at least it allowed academia to reject both Endnote and Mendeley. Anything that punches Elsevier in the face gets a tick in my book.
I like me some cli, but if I was to do something similar it would be with csl-json and jq/nushell. I cannot see the advantage of grepping a bibtex file, let alone having to manually manage the related articles.
A friend and I have been working (slowly, over the past few years, since we are both academics) on an abstraction layer over BibTeX called Autobib: https://github.com/autobib/autobib
Broadly speaking, Autobib is a CLI around SQLite database of BibTeX records. But in addition to plain BibTeX, Autobib is aware of 'external data providers' (like DOI, MathSciNet, OpenLibrary, arXiv, zbMath, etc.) and will automatically retrieve data bibliographic data from these data providers. The provenance of the data is stored alongside the record itself, and this can be used to retrieve updates, prevent duplication of data, etc.
The killer feature is: if you have a file (say `file.tex`) and the keys are in a format which Autobib can automatically recognize (say, you use citation keys like `doi:my/weird/doi`, and there is support for custom formats and aliases) you can run `autobib source file.tex` and it will write to standard output a sorted BibTeX bibliography for your file. This lets you trivially maintain a per-project bibliography which you can check into source control locally and which exactly corresponds to the paper itself.
But otherwise, Autobib is "just a wrapper over a BibTeX bibliography"! When you edit an existing record, you are just editing a BibTeX record. There is integrated search, directly on the BibTeX fields themselves.
There are some extra features, like support for attachments, fuzzy search, undo-tree support, headless edit, auto-normalization, soft deletion, replacement, merging, etc. The database format is relatively simple and open (currently not particularly well documented, but this will change when it stabilizes) to allow introspection by other tools.
The tool also strives to play nicely with other tools (structured output, composable, etc.)
The rest of the interface is ok.
The reason I like Zotero is because I can use it offline, have my all documents synced (the backup feature is one of the best things) when needed and I can organize my papers according to project/paper I'm working on. Actually one thing I do wish Zotero would add is tab groups which will allow me have papers open but grouped by project. It's based on Firefox which does support this so I hope it's a matter of time.
Zotero integrates well with various online services. This I think is Zotero's most valuable feature. The simple fact is that not everything exports BibTeX. Can you get a library catalog to export BibTeX? Perhaps in CS, most publications provide good BibTeX, but a lot of journals I (a mechanical engineer) deal with don't provide BibTeX at all to my knowledge. But I can simply press a button in Firefox and import the bibliographic data embedded in the web page into Zotero. (No, Google Scholar is not a good solution here because it's frequently inaccurate and incomplete.)
I'm a technical guy who can handle BibTeX fine, but I still prefer the Zotero UI over using BibTeX files in a text editor and shell, even if I'm only generating BibTeX files.
The author discusses using non-standard fields like keywords to store extra data. I would recommend that to store additional context about the document. Zotero can store even more than that, including web pages, files, and additional notes. I like that Zotero saves a snapshot of the journal article web page in most instances. Journals sometimes do go offline, so it can be nice to have the web page. I often have detailed notes about particular documents in notes in Zotero. Yes, you can do that with BibTeX, but I could see the extra fields cluttering the BibTeX file. (Contrary to what the author states, the note field probably should not be used as they describe because it's printed in some/most? bibliography styles.)
The search in Zotero is more powerful than grep. Try returning bibliographic entries where one field contains X and another field contains Y. I think you can probably come up with a grep solution for that, but it's so convoluted that it's probably never used in practice. You could use a BibTeX searching program like biblook to get around this problem.
Don't get me wrong. Zotero is far from perfect. It can be slow, and at this point I would prefer a TUI reference manager. But overall, it's the best option I've tried.
These frontends are necessary however because researchers in non-computer related fields are not trained/proficient at command line tools. Many of them need help installing software. Many of them don’t use raw text files much either. They use MS word files instead etc.
If this kind of feature could be replaced by txt files I probably would be using it, but, no...
I think this has an unnecessary risk of hallucinated bibliographic data. For anyone doing something similar in the future, it would be more reliable to make a LLM generate a list of DOIs and have Zotero import the DOIs.
Like another poster here, trusting an LLM with my reference database -- the ultimate source of truth -- is not a step I'd be willing to take. All it takes is a single hallucinated reference, and your career would be forever tainted. It's not worth the risk.
Sadly, Zotero seems to have removed this killer import feature in later versions, which is the reason I keep using version 6. It feels like later versions have been a route to dumbing-down the interface, prioritising simplicity (and an ultra-low-contrast interface) at the expense of functionality. (If you can still drag-n-drop PDFs straight in with the new versions, someone please let me know?)
It's not my cup of vodka, to be sure.
Each one can choose their own tools of course, but we often see llms shown as solutions to something presented as unsolvable before, while it already was pretty amenable to normal tools.
I see that as a symptom of being intellectually lazy, or not knowing the value in mastering a tool via deliberate use over time.
Once one invests the required time to use a tool properly, they can reap way more benefits from said tool when compared to jumping tools at minute's notice.
2026-06-09
It's fairly well established by this point that I like minimal computing. Despite usually working on notoriously resource-intensive AI projects, there's nothing I like more than getting the most out of my machine in the simplest, cleanest way possible.
As an academic, it's natural to keep track of dozens, if not hundreds, of sources at any one time; pulling from various papers, presentations, and publications in order to build your case. Typically this will all be handled by a bibliography manager with the invariable default choice being Zotero. A fine option by any stretch by its sheer unanimity did prompt me to at least see what else was out there. I tried Jabref, I tried Cobib, I tried Tellico, all to varying levels of success.
It was in switching between all these different platforms that a pattern emerged: I'd export my references to BibTeX and then import that into the new platform; I'd then want to try something new and so would export to BibTeX and re-import again.
It became increasingly clear that all these different options were just glorified front-ends for BibTeX.
BibTeX, the file-format/processor bundled with just about any LaTeX distribution. The format responsible for labelling all your titles, authors, years, sources, any information you might need about a piece of work.
There appears to be this idea that BibTeX is something that should be overlooked wherever possible; used only as an intermediary between your real reference manager and a finished output. It's been my experience that any work is done in a proper reference manager, exported to BibTeX, and then added to the final piece - never actually interacted with directly. That's fine; going from a world of colour-coded lists, drop down filters, and other neat features, to the below can feel a bit brutal to say the least:
@book{abramowitz+stegun, author = "Milton {Abramowitz} and Irene A. {Stegun}", title = "Handbook of Mathematical Functions with Formulas, Graphs, and Mathematical Tables", publisher = "Dover", year = 1964, address = "New York City", edition = "ninth Dover printing, tenth GPO printing" }
But, in the quest to min/max complexity/capability I figured I'd give it a shot. I exported everything to BibTeX, uninstalled whichever reference manager I was using, and just went from there. I expected this to be a fun diversion, a chance to peek under the hood before returning to the safety and comfort of Tellico or Zotero. But that didn't happen. A single BibTeX file has now been my sole reference manager for almost two years.
This hasn't been a slog either, of mindlessly scrolling to through thousands of lines to find the entry I'm after; BibTeX is designed to be easy to navigate, and this is all thanks to its "field types", the data that describes an entry. There's the obvious stuff like 'title', 'author', 'date' etc. but having a look at the full list will reveal there's an option for just about any requirement you might have.
What really makes this approach feasible however is the 'keywords' field which allows you to add extra information of your own choosing about an entry. For me, that tends to be what project the piece relates to, the main topics it covers, whether I've read it yet or not. Rather than a single thousand line file of entries, you can attach keywords to various entries and then just grep your way around to fetch anything of interest. For example, every entry that I've read that relates to cybersecurity:
grep -E "keywords.*have_read|cyber_security" file.bib
If you're particularly committed to just one file, there's also the 'note' field where you can record more detailed information about an entry such as its main findings, methods, and other points of interest.
As with any tool I try to use, I'm always after something that plays well with others in the UNIX-way. I can send the file over here and perform some operation on it, then over there and do another operation. I'm not tied down to the developers of one platform trying to come up with every functionality I might want; I can just stack together operations to do what I'm after as new needs appear. For example, count and list every outlet by the number of times it's referenced:
grep -o journal.* file.bib | uniq -c | sort
BibTeX is surprisingly portable as well. Previously I'd jump around platforms and repeatedly encounter issues where the migration didn't quite work with some entries not transferring all the information attached to them. BibTeX is just plain text; not a sort-of-plain-text-sort-of-SQL-database-sort-of format that many reference managers seem to use. I can attach every reference to an email without much thought. I can add it to version control and track changes over time. I can not worry that anyone else who relies on the file won't be able to access it - it's plain text, it'll be viewable somehow.
As with anything TeX-related, the learning-curve can be steep but, again with anything TeX-related, the rewards tend to compound. LaTeX is pervasive in academia and so developing a good understanding of not just the language but the surrounding tools can go some way in making you not only more productive but also in building a software toolkit that can last across a career.