Teemoji: Like tee but with emojis(github.com)
github.com
Teemoji: Like tee but with emojis
https://github.com/willswire/teemoji
58 comments
Hey HN! I've been playing around with Apple's CoreML framework for some personal projects, and wanted to see how it might work in a CLI context. This is really just something fun I did over the weekend for sh*ts and giggles. I hope you enjoy!
An AI-powered dev tool? I expect to see this in the next YC batch
for real give this person tens of millions of dollars ASAP
It may have taken 56 years, but this comprehensively resolves the question about whether shell is better than GUI in favor of shell. Thanks to the endless composability of shell, just this one program finally fixes the biggest flaws in text file handling in Unix, but the GUI equivalent would be quite complicated and composes poorly. This vindicates all of the original developers of UNIX once and for all.
That's not fixing the biggest flaw, it's just addressing a small set of specific use cases.
If anything, it's a bandaid that highlights the biggest flaw of UNIX philosophy: everything is passed as unstructured text. Because of it, half of shell programming is just piecing together ad-hoc, buggy parsers that interpret the input, possibly rearrange it, and then dump it down the pipeline as unstructured text, so the next step can do it all over again. And then, of course, every CLI program has to do that too.
This program is using a machine learning model to parse its input; while this may be the only reasonable way to go about guessing emojis from arbitrary text, I can easily see people doing the same to parse outputs of Linux CLI tools at runtime, because it looks much more pleasant and might be even more reliable than writing input parsers by hand. Let's pause here to consider the absurdity of that situation.
If anything, it's a bandaid that highlights the biggest flaw of UNIX philosophy: everything is passed as unstructured text. Because of it, half of shell programming is just piecing together ad-hoc, buggy parsers that interpret the input, possibly rearrange it, and then dump it down the pipeline as unstructured text, so the next step can do it all over again. And then, of course, every CLI program has to do that too.
This program is using a machine learning model to parse its input; while this may be the only reasonable way to go about guessing emojis from arbitrary text, I can easily see people doing the same to parse outputs of Linux CLI tools at runtime, because it looks much more pleasant and might be even more reliable than writing input parsers by hand. Let's pause here to consider the absurdity of that situation.
> might be even more reliable
simply impossible. when a input parser breaks, it breaks. with a LLM, it breaks... sometimes, for different reasons. Let alone the enourmous computing power needed compared to simple input parsers.
simply impossible. when a input parser breaks, it breaks. with a LLM, it breaks... sometimes, for different reasons. Let alone the enourmous computing power needed compared to simple input parsers.
Mmmm... perhaps a </sarcasm> was called for there. Clearly it isn't the biggest flaw of any system that it fails to properly label everything with emojis automatically. Indeed, I think I fear the day when I see an editor pop up on Hacker News and it is listed as a feature that it doesn't use machine learning to automatically splatter whatever open standard GenMojis turns into everywhere into its input, because of what it implies about everything else....
And yet it is precisely that unstructured text which allows programs to be infinitely composable, whether they were written 30 years ago, today, or are yet to be written. This is what allows programs like teemoji to work with any other program, without directly supporting it.
Besides, what format should the data be structured in? In the 1960s and 70s, it might've been GML. In the 80s, maybe SGML. In the 90s, XML, and later maybe JSON, or... shudder YAML? Or, no, it obviously should've been some binary format.
OK, so let's say everyone agrees on a single format for several decades. Should all programs written for all those shells that support it also support the data format? Even if that's handled by shells and not the programs, there will surely be bugs and incompatibilities in each shell implementation, leading to fragmentation.
Furthermore, will the data format support versioning? Will it be backwards compatible? Will all programs or shells need to support this? Will users have to mix and match, and experience all sorts of compatibility issues?
So, clearly, unstructured text is the only "format" that is both flexible and future proof enough, at the expense of convenience for the user to glue programs together. I'd rather have that than have to depend on the structured format du jour that will have to be continuously maintained and supported by all programs in the ecosystem.
Besides, there are projects like Nushell and Murex that wrap the input and output of existing programs or write their own to support piping structured data. I'm not a big fan of them, but it points out that unstructured data is not some UNIX flaw, but a deliberate design decision which is IMO partly what enabled it to proliferate in the first place.
Maintaining a shell that supports piping structured data can only be done by a single entity that oversees the entire ecosystem, like Microsoft does with PowerShell, or the above mentioned projects. That is the antithesis of the UNIX philosophy where disparate tools can be written by anyone, yet somehow still be made to interoperate by the user. It's also a gargantuan project that realistically not even mega corporations can successfully maintain without limiting the user or introducing bugs. Plus it will always be a bottleneck for adding new tools to the ecosystem. For these reasons I don't foresee any of the structured data shells to be nearly as popular as UNIX shells have been and will continue to be 30 years from now.
Besides, what format should the data be structured in? In the 1960s and 70s, it might've been GML. In the 80s, maybe SGML. In the 90s, XML, and later maybe JSON, or... shudder YAML? Or, no, it obviously should've been some binary format.
OK, so let's say everyone agrees on a single format for several decades. Should all programs written for all those shells that support it also support the data format? Even if that's handled by shells and not the programs, there will surely be bugs and incompatibilities in each shell implementation, leading to fragmentation.
Furthermore, will the data format support versioning? Will it be backwards compatible? Will all programs or shells need to support this? Will users have to mix and match, and experience all sorts of compatibility issues?
So, clearly, unstructured text is the only "format" that is both flexible and future proof enough, at the expense of convenience for the user to glue programs together. I'd rather have that than have to depend on the structured format du jour that will have to be continuously maintained and supported by all programs in the ecosystem.
Besides, there are projects like Nushell and Murex that wrap the input and output of existing programs or write their own to support piping structured data. I'm not a big fan of them, but it points out that unstructured data is not some UNIX flaw, but a deliberate design decision which is IMO partly what enabled it to proliferate in the first place.
Maintaining a shell that supports piping structured data can only be done by a single entity that oversees the entire ecosystem, like Microsoft does with PowerShell, or the above mentioned projects. That is the antithesis of the UNIX philosophy where disparate tools can be written by anyone, yet somehow still be made to interoperate by the user. It's also a gargantuan project that realistically not even mega corporations can successfully maintain without limiting the user or introducing bugs. Plus it will always be a bottleneck for adding new tools to the ecosystem. For these reasons I don't foresee any of the structured data shells to be nearly as popular as UNIX shells have been and will continue to be 30 years from now.
I feel you’ve gone on a tangent there. Particularly your unrelated comment about using of using ML because people are too lazy to write parsers.
That all said, I don’t really disagree with any of your individual points. But teemoji is clearly not meant to be considered a serious tool so I wouldn’t be too critical of UNIX that this tool exists.
That all said, I don’t really disagree with any of your individual points. But teemoji is clearly not meant to be considered a serious tool so I wouldn’t be too critical of UNIX that this tool exists.
I'm not critical of UNIX for this tool specifically, and I think it would be useful even if UNIX did things differently - a "pick best fitting emoji for arbitrary line of text" is a well-defined task, and I hit scenarios where I'd wish I had such tool surprisingly often.
I don't use PowerShell often at all, but this IMO is one thing it gets right, by piping .NET objects and implicitly piping to `Out-Default` at the end.
Of course this is another standard that tools would have to be incredibly careful to keep track of, but JSON is decently mature and a bunch of modern tools can operate in it, so at least there's slow progress away from the plaintext quagmire.
Of course this is another standard that tools would have to be incredibly careful to keep track of, but JSON is decently mature and a bunch of modern tools can operate in it, so at least there's slow progress away from the plaintext quagmire.
This made me grin and I love that it did. Sometimes our profession can be a little short on whimsy and I think projects like this are actually really important! I’m looking forward to using this :)
my major and minor complaints are, in order:
tee does something very specific, it makes an unmodified copy into a file (one branch of the plumbing tee-joint) as it passes the stream to stdout (the other branch); as opposed to sed or awk or even grep, et al, which modify the stream. How in hell is this inspired by tee which does not modify its inputs?
and who capitalizes Tee?
tee does something very specific, it makes an unmodified copy into a file (one branch of the plumbing tee-joint) as it passes the stream to stdout (the other branch); as opposed to sed or awk or even grep, et al, which modify the stream. How in hell is this inspired by tee which does not modify its inputs?
and who capitalizes Tee?
Agreed. `tee` without any flags is essentially a no-op and doesn’t have much use, whereas teemoji does. This feels more like `nl` in the sense that it outputs its STDIN with something prepended. But with the additional support for splitting the stream, in which case its STDOUT is unmodified like tee.
I still absolutely love this project. It’s inspired me to play around with CoreML.
I still absolutely love this project. It’s inspired me to play around with CoreML.
Yeah, I feel like this should have been implemented solely as a single-in/single-out stream modifier. Then if you want to output to both a file and stdout, you can `command | emojify | tee`, or `command | tee | emojify` if you want to keep the file clean. Or if you want to emojify without splitting the stream (which I suspect would be the most common use case) you don't have to worry about the tee aspect at all.
Because it writes to a file like tee.
Does it produces the infamous emoji if a certain expletive occurs in the input?
By the way, I use that emoji to test whether astral planes are handled correctly.
I need to recover from the cognitive dissonance now...
By the way, I use that emoji to test whether astral planes are handled correctly.
I need to recover from the cognitive dissonance now...
/usr/local/bin/teemoji: line 2: /usr/local/Cellar/teemoji/0.0.4/libexec/teemoji: Bad CPU type in executable
:sadface:
:sadface:
intel?
Awesome! Pretty impressive that the model only weighs ~200Kb
The following is a "Get off my lawn!" comment:
When I was in kindergarten there were tasks where you'd get a paragraph of text where you had to fill in blanks, and next to those blanks were pictograms of whatever noun was expected.
Whenever I see people overuse emojis, for example "Yesterday we flew [plane emoji] to Japan [Flag of Japan] and took the train [bullet train emoji] and saw Mt. Fuji [emoji of Mt. Fuji]", I always think, "This person is still in kindergarten."...
When I was in kindergarten there were tasks where you'd get a paragraph of text where you had to fill in blanks, and next to those blanks were pictograms of whatever noun was expected.
Whenever I see people overuse emojis, for example "Yesterday we flew [plane emoji] to Japan [Flag of Japan] and took the train [bullet train emoji] and saw Mt. Fuji [emoji of Mt. Fuji]", I always think, "This person is still in kindergarten."...
You mean, like the fastapi documentation used to be?
https://github.com/fastapi/fastapi/issues/3273
https://github.com/fastapi/fastapi/issues/3273
that's hilarious - love seeing funny github issues and the drama that ensues
Gotta love some good GitHub drama!
That's funny! I've made a "tool"[1] that "automatically" adds emojis to text.
It is even worse for your example! It adds two train emojis for some reason.
"Yesterday we flew [plane emoji] to Japan [Flag of Japan] and took[train emoji] the train[train profile emoji] and saw Mt. Fuji [emoji of Mt. Fuji]"
I did a ShowHN because I thought it was a good idea but it flopped. Maybe I should pivot my idea toward kindergarteners!
[1]:https://emojithis.com/
I did a ShowHN because I thought it was a good idea but it flopped. Maybe I should pivot my idea toward kindergarteners!
[1]:https://emojithis.com/
Fun idea! Maybe re-target as a "de-Boomer my text" app...
it sounds like a person who does not know their emojis: Japan is the only country to have its geography available as an emoji, so why wouldn't you use it in this case instead of the flag?
https://emojipedia.org/map-of-japan
https://emojipedia.org/map-of-japan
Because when writing you use proper nouns.
You do, but others don't, and I can't imagine anyone getting confused by a phrase like "I went on a [plane emoji] yesterday!" so it's not a barrier to communication. So where's the issue?
Because its harder to read. The example another comment linked to is a good demonstration https://github.com/fastapi/fastapi/issues/3273
Occasional emoji are not so bad but people who spam huge numbers of them aren't aware of what a mess they make for screen readers.
I often wonder about how things affect screen readers. I have no way of knowing, really, what the problems are for people who rely on them. I am told lots of things are good practice, and and I can make some guesses about other things, but a lot of it is not what most people do.....
Customers of my employer demand accessibility so we use https://www.nvaccess.org/ for screen reader testing which is a free download
Thanks, and I would love something like this, but its Windows only.
There is one built into MacOS
https://www.apple.com/voiceover/info/guide/_1121.html
On Linux there is
https://help.gnome.org/users/orca/stable/index.html.en
I have no idea how good that one is, but VoiceOver is pretty good.
https://www.apple.com/voiceover/info/guide/_1121.html
On Linux there is
https://help.gnome.org/users/orca/stable/index.html.en
I have no idea how good that one is, but VoiceOver is pretty good.
Your Japan comment is a bit strange considering that the Japanese writing system itself uses Kanji which are effectively the OG emoji (well really Chinese is the true OG and emoji are more of a modern take on kanji/Chinese pictographs).
That said, why is a Japanese sentence written using one set of pictographs respectable and proper, but another set of pictographs means the writer is in kindergarten?
That said, why is a Japanese sentence written using one set of pictographs respectable and proper, but another set of pictographs means the writer is in kindergarten?
One is a writing system that depicts concepts with classy strokes and has thousands of years of history; the other is a bunch of redundant Fisher-Price looking drawings without semantics added to Unicode by a corporate committee.
Chinese writing is the OG wrt Japanese kanji, but it is preceded (independently) by Egyptian hieroglyphs, which, if you want to compare OG-emojis, I submit for your evaluation 𓂸 and 𓂺 as being better eggplants than an eggplant
This is so cute and funny and interesting. Thanks for making and sharing.
I was doing `echo cat | teemoji` tests and it would work, but ironically 'echo happy face | teemoji` and the like didn't work so well for many other obvious single-word emojis. But it did a "checkered flag" for "I got the job done".
I was doing `echo cat | teemoji` tests and it would work, but ironically 'echo happy face | teemoji` and the like didn't work so well for many other obvious single-word emojis. But it did a "checkered flag" for "I got the job done".
Glad you enjoy it! There are some inconsistencies/surprises for what emoji gets suggested my the model. I’m hoping to generate some better training data and refine the outputs in the next release.
I wish I could get this on Linux </3 Any ideas how to get there (without reaching out to network apis, like openai)? I assume since it's built on Apple's CoreML framework it's not possible?
No, but there are ways you could approach it with various tradeoffs.
You could start with something naive using pattern matching, common formats, common words, etc. and apply the most relevant emoji. It'd be fast and small but not as flexible and no cool ML in there to enjoy. It'd probably be how I'd go about it though - you could actually use AI at the dev stage to get the dataset for this pretty tight I reckon..
Or.. you could use a tiny embedding model (which might even be fast on CPU alone), assign emojis to the best appropriate regions, then pick the 'closest' emojis for embeddings of fresh text. Potentially inaccurate but could be fast-ish.
Or.. all the way up to using something like TensorFlow and training a classifier, but it'd probably take a fair bit of space and not be super fast if it fell back to CPU. Would be a fun experiment! (I haven't done this on Linux before so I might be wrong in 2025.)
One big benefit of Core ML is it Just Works™ if you meet the hardware and OS requirements. On Linux you'd potentially need to fall back to CPU or have a lot of various dependencies to lean on (maybe ONNX takes care of all this nowadays?)
You could start with something naive using pattern matching, common formats, common words, etc. and apply the most relevant emoji. It'd be fast and small but not as flexible and no cool ML in there to enjoy. It'd probably be how I'd go about it though - you could actually use AI at the dev stage to get the dataset for this pretty tight I reckon..
Or.. you could use a tiny embedding model (which might even be fast on CPU alone), assign emojis to the best appropriate regions, then pick the 'closest' emojis for embeddings of fresh text. Potentially inaccurate but could be fast-ish.
Or.. all the way up to using something like TensorFlow and training a classifier, but it'd probably take a fair bit of space and not be super fast if it fell back to CPU. Would be a fun experiment! (I haven't done this on Linux before so I might be wrong in 2025.)
One big benefit of Core ML is it Just Works™ if you meet the hardware and OS requirements. On Linux you'd potentially need to fall back to CPU or have a lot of various dependencies to lean on (maybe ONNX takes care of all this nowadays?)
I’ll have to look into this; it’s something I’d love to add support for if possible!
I am pretty sure you can get the same result using ollama. Like “cat emojiprompt.txt input.txt | ollama run llama3 | tee output.txt”
I created a cross-platform version using this approach https://github.com/sanbor/emoji
It's very slow in comparison because it uses llama3.2 model but it's a very common model and the emojis generated are more related to the lines.
Next feature would be to add an emoji model to this tool to make it faster.
It's very slow in comparison because it uses llama3.2 model but it's a very common model and the emojis generated are more related to the lines.
Next feature would be to add an emoji model to this tool to make it faster.
The training data is in the resources, so you could use that to train a model locally and invoke it.
I feel like this defeat the goal of emojis and icons: highlight important informations for our brain to process. This is just an overwhelming amount of emojis for me, but I guess it has its usecases
My RSS reader has an autoposter to post to Mastodon where I always try to choose an appropriate emoji for a post
https://mastodon.social/@UP8
I've been thinking about training a model, maybe a T5 to automate the task. I've tried asking Microsoft's Copilot to do it, and it is ok but makes decisions that I wouldn't make. I argued with it a lot and couldn't get it to draw ⁰₀⁰₀⁰ as an imitation Olympics logo and had to do it myself.
https://mastodon.social/@UP8
I've been thinking about training a model, maybe a T5 to automate the task. I've tried asking Microsoft's Copilot to do it, and it is ok but makes decisions that I wouldn't make. I argued with it a lot and couldn't get it to draw ⁰₀⁰₀⁰ as an imitation Olympics logo and had to do it myself.
[deleted]
This is really cute! thanks for sharing :)
if I may offer a small nitpick for feedback, I am seeing wrench emojis on empty lines which create a lot of noise.
If you are interested in PRs (and making the change) I might try to take a look at the code and see if it's possible for me to contribute this to it.
if I may offer a small nitpick for feedback, I am seeing wrench emojis on empty lines which create a lot of noise.
If you are interested in PRs (and making the change) I might try to take a look at the code and see if it's possible for me to contribute this to it.
You saw cat -v considered harmful and thought ... hold my beer!