Chris X Edwards

Today I got a little frustrated with what I consider to be a small shortcoming in the Bash shell. I’m not criticizing Bash in any way because true to its spirit, I was able to use Bash to create the solution that eliminates the problem permanently for me. It’s an interesting and illustrative example of the thinking involved and it might actually be a practical solution you can use.

The problem comes from tab completion. People ignorant of command line methodology usually mistakenly suppose I must keep a lot of things in my head — like file system layouts. No. I’m not that clever. On the contrary, what we Bash power users tend to do is spam the tab key while we blunder around our filesystem by brute force using tab completion. This works fine almost always, but there is one case that is ever so slightly annoying.

Sometimes you are bumbling around your directory tree looking for a particular file — not a directory (path location) — but a non-directory file. Tab completion certainly is good at this and you can quickly find files if you have a rough idea of where they might be. If I wanted to delete a particular file, I could start off with the rm command and tab my way to it and hit enter and it would be done. Great.

But what if the command is cd (Change Directory)? What if you want to find a particular file and then change to the directory it turns up in?

If you tab complete to, something like this…

…and press enter, you’ll get an error saying this is not a directory (not a d that one can c to).

(Overly technical side note: I’m discovering that Debian bullseye, with Bash-5.1.4, won’t even let you tab complete to a file when you have the line starting with cd. Something to do with "Programmable Completion" and the complete builtin - look those up in man bash and have a look at /etc/bash_completion. But on newer Debian bookworm, with Bash-5.2.15, the behavior has changed! I totally can tab to files with cd as the command. This is probably why this is bugging me only just now.)

Ok, no big deal, right? You just hit the up arrow (experts use command history as much as tab completion!), queue up the malformed attempt and then spam the backspace key to get rid of the file name. (Or if you can remember fussy Emacs key bindings better than I can: Alt-b to go back a word, and Alt-d to delete a word or Ctl-k to delete to the end of the line; I’m sure there are other ways).

The more serious version of this problem is when you have a long and/or obnoxious file name. I personally never put spaces in file names just to avoid this kind of nuisance, but other people are not so accommodating. Imagine I just tab completed my way to this gem from CDDB (line breaks for clarity).

That command would fail. And that is the problem.

And this is the solution I came up with.

If you put this Bash function in your Bash environment somehow (e.g. just cut and paste it right in, or put it in your ~/.bashrc, etc) you can use it the way we want. You can tab complete to a file and it will change your directory to the directory containing that file.

I strategically called it fcd for *f*ile *c*hange *d*irectory and this allows us to use our old familiar cd without much thinking. If you get to the situation shown above where you are trying to cd to something and you tab complete to a file, you can just press enter and get the error. Then you can hit up arrow to bring the previous command back, press Ctl-a to move the cursor to edit the beginning of that line, and type the f (for file) and hit enter and you’re done. So it’s a way to recover very quickly from this slight annoyance.

I’m happy with the solution and it works fine for cases I can think of. It is a good example of how in Bash there really aren’t unsolvable problems that should be solvable. Cool.

If you’ve followed along so far, you understand the problem and motivation and even the eventual solution. If you’re a modern computer nerd in 2023, you should be wondering: how did GPT4 do with this problem? Well, I knew there was a solution and was pretty sure what it was. But I’m lazy and if you know there is a short and sweet solution to a computer nerd problem, our robot friends can often be quicker at finding it.

However. In this case GPT4 was a complete failure. Right away I could tell that input containing spaces was going to trip this up (and we just saw that’s quite a likely use case). Look at what happened when I alerted it to the problem.

There’s wrong and then there’s silly wrong. You don’t need to have any idea what this code does to see that the exact same code is not going to be some kind of improvement.

The idea to use $@ is critically flawed. GPT4 also bungled the proper usage of the dirname command. I investigated it and it was a little surprising. (Really? It eats the last subdirectory when no file is present? Yes it does.) Then again, I’m not a walking man page. After reading the short man page, it made sense and I knew what to do, which is more than we can say for GPT4.

If this post seemed too technical to you, that’s fine. Hopefully you can appreciate that I’m taxing GPT with a slightly more esoteric topic. And it can not keep up! If you’re as knowledgeable as David MacKenzie (one of the authors of dirname), or even me, you can see that the time to be worried about being completely replaced by our robot friends is not quite now.

This post has many purposes.

I always read Merriam-Webster’s Word Of The Day article and it often ends with an anagram puzzle. I can usually solve it just by the other clues but when I can’t I like to use a simple bit of unix magic to give me a hint. On Linux (maybe Apples?) you can search for a regular expression like this.

In this case the anagram I’m looking for is something with the letters r, t, i, and e. This command will look through my system’s word list and find words that contain one or more of these characters. I can further refine it by specifying I want 4 character words only with ^[rtie]\{4\}$. For sure the syntax is not pretty but it is succinct and effective. The problem with this exact strategy is that we will get not only correct words like rite, tier, and tire, but we will also get incorrect words like tree. However this strategy is usually sufficient to spot the solution and the puzzle is solved.

Sometimes however the puzzle turns out to be trickier. Today’s was looking for a synonym for "evince" unscrambled from the following letters "tmiesafn". (I’m going to give the answer below, so solve it yourself now if you’re keen to.) Using the strategy above gives me a command like this.

This produces 71 matching words e.g. "feminist", "satanism" etc. However only one of the matches uses these letters without duplicates and that can be difficult to spot. Is there a way to improve this and have it do what I really want?

For such low stakes tasks that are easily verifiable, you should now be starting to ask yourself if this is something a modern LLM AI assistant can help with. In the past it would not have been worth the effort for me to come up with a better solution to such a trivial problem but today, why not? There are a lot of problems like this which in the past just weren’t worth messing with but today are.

So I gave claude.ai a crack at it. And it instantly responded with 5 complete and entirely different strategies. All completely wrong. So wrong, that I could see that they were wrong without further checking. (Things like "pipe to uniq" which is a solution to some problems but definitely not this one.) How about ChatGPT? Starting with 3.5 it also stumbled and produced something that seemed plausible but smelled wrong to me. I went ahead and tested it and sure enough it was wrong. As I pointed out the problems, it devolved into a more appropriate position of humility admitting defeat.

GPT-4 was a different story. Its answer not only sounded confident and convincing, it was also correct. Here is the condensed solution.

Running this produced the correct solution which is "manifest". And normal people can appreciate that these AI agents are getting more clever than clever experts at stuff like this and stop reading here and have a nice day.

If you’d like to know more about what exactly this crazy regular expression is all about and learn about a situation when some of the most esoteric features of modern regexp engines are not just "nice to have" (or overkill!) but essential, read on.

What’s happening here is that the characters of the anagram are being broken apart and sed is used to dress up each character with something like this: t becomes (?=.*t) and m becomes (?=.*m) and so on. This creates a regular expression that fully written out looks like this (which also works).

It was very clever of GPT-4 to know how to create this kind of regexp from the input string using sed, but what is this and why is it useful here?

This syntax is using a "positive lookahead" token for each character. It ensures that the expression contains one (and only one) of each letter. It’s hard to explain completely because I personally can not think of any other compelling use case for it. I can’t get GPT-4 to think of any either. We can both think of examples, sure, but it’s hard to find an example that really needs this. By far the best example I’ve ever seen is this anagram solution!

The other thing to note — and why I totally ignore this kind of regular expression feature creep — is that the -P invokes PCRE (Perl Compatible Regular Expressions). This is a variant with fancier features. But since programs like sed, awk, and vim (and many others) don’t bother, it makes learning this less worthwhile. But GPT-4 learned it, learned it really well, and did not forget about it when the perfect time to deploy it arose.

The take away here is that we’re at a time where a lot of your small technical problems that you know (or suspect) are solvable in principle but annoyingly difficult in practice should now be reappraised to see if modern AI can effortlessly help. Some of these problems will just magically disappear.

Note however that anagrams are not completely solved generally by the solution above! Words that have multiples of the same letter fail with GPT-4’s strategy. When I asked for possible solutions it struggled to produce an elegant command line approach. Like I say, we’re at a transition time where it could go either way.

Almost as soon ChatGPT became the first computer system to impress me with an interaction that passed the Turing Test to my satisfaction, it was not long before I realized these systems would soon struggle with a fundamental problem impeding their continued progress. This is what I call the Ouroboros problem.

The 2023-04-23 issue of The Economist introduces the problem with a related one: "But the most important limit to the continued improvement of LLMs is the amount of training data available. GPT-3 has already been trained on what amounts to all of the high quality text that is available to download from the internet." They cite a paper which predicts that high-quality language data will be entirely exhausted before 2026.

Is this the most important problem? What I realized is that we’re not only going to have fewer words that remain unread by language models, but we will have more — perhaps exponentially — text generated by AIs. If these AIs train on this — their own output — we will see the Ouroboros effect of the snake that eats its own tail resulting in obvious deleterious effects.

I was primed for noticing this by already spotting it in another area of AI research. I remember watching one of Tesla’s long tech demos and buried deep within was an engineer explaining how the Tesla training was cleverly exploiting access to millions of cameras on their deployed fleet of cars to collect training data. He went on to outline how human driver behavior could be gleaned for training from this collection. Hang on a second! I immediately suspected that this concept was either pessimistic or seriously flawed. It would be pessimistic if Tesla’s self driving ambitions were never realized, but it would be foolish if they were! If some significant percentage of other cars on the road were being driven by software which learned a sense of "other drivers" by watching other cars, then there would be, fundamentally, nothing teaching the cars the behavior of other human drivers.

What can be done about this? The first thing is to understand that this is an issue. I think once AI starts to pollute the ecosystem its own training data is drawn from, it must be factored in that this training data is inferior to pristine sources.

For cars, maybe it will be possible to have good classifiers that can look for subtle tells that the other car is piloted by a human brain (fewer lidars, worse lane keeping, etc) and use that human-ness value as an input parameter.

For LLMs it may be trickier since the chatbots are really doing a great job of simulating ordinary text. A strategy that may work for large deployments is to not care where the training data comes from. The systems could do something like A/B testing where some users are conversed with using a model trained on one training set and other users communicate with a slight, perhaps random, variation on that. The winner is preserved.

Another potential solution is to take written text as solved. The next frontier will probably be your telephone conversations and video chat meetings. Transcripts of those will inform AIs about real human extemporaneous communication and subtle ancillary cues ("um"s and "hmms", facial expressions in video, pitch changes, etc). That should provide orders of magnitude more text than has ever been written. Obviously, for the same reasons, that approach stops when AIs are doing much of the live talking.

Of course if that goes well, the corporations that control the listening devices you religiously share your private conversations with will be strongly tempted to go ahead and train on every utterance ever made audible. After all, you did express your enthusiasm for such a tactic by agreeing to their EULA quicker than any human could possibly read it!

It may turn out that at some point in the future the most valuable conversations to eavesdrop on are the ones weirdos like me have — people who do not like suffering eavesdropping and know how to prevent it.

Very famous author and generally cool guy Neil Gaiman wrote a book about and titled Norse Mythology. Neil is mostly famous for writing the original stories behind such popular works as Coraline and the show Good Omens (and many, many more). So the author is not a stuffy academic (like Tolkien) who has to put extra effort into making their writing something one reads for pleasure. I felt like we’re really getting the most readable treatment of the material possible.

A lot of modern culture draws on a wide range of old time religions and Europeans had no shortage of wacky beliefs. Perhaps more than "religious beliefs" these myths were also by necessity filling in for what modern fiction (movies, books, games, soap operas, etc) provides today.

(While reading this book I noticed one of my favorite Youtube creators also had read it.)

If you have played Skyrim or read the Hobbit and liked that sort of thing, this book will probably be interesting to you. Those works don’t include Norse mythology per se but they’re both heavily inspired by many elements from it. I haven’t seen the Marvel Thor movies but obviously we’re not talking about intellectual property that is dead and forgotten. It seems quite reasonable that someone dredge up the authentic real source material and translate it into something modern readers can understand and enjoy without years of study.

Sometimes I do like doing things the hard way and I’ve been making a lot of progress learning Norwegian. That was an obvious motivation to check this book out. I was surprised and a bit disappointed by how un-norsk this Norse mythology seemed to me. For example, even being able to read Norwegian pretty well, I still couldn’t confidently pronounce any of the weird names in the stories. Normal humans, of course, will not have this problem. I guess it follows the pattern not unknown in English. Consider this wikipedia description: "Other… proposed … candidates for … Lancelot include … saint Fraimbault de Lassay; Maelgwn, king of Gwynedd and Llaennog (Llaenauc), father of Gwallog, king of Elmet…". If those names seem perfectly normal to you, then you are not a normal English speaker. Same for Norse mythology and modern norsk as far as I can tell. I suspect that if you are a Norwegian living in Norway today and you want to get a good introduction to your own historical mythology, this book — in English — is still probably your best bet.

Gaiman’s treatment of the material seems pretty light but maybe that’s just his easy-to-read prose making me think that. Even if it is academically weak (which it may not be!) I think it has incredible value. If you are an academic Norse mythology scholar, then you must read this book multiple times just to help teach yourself how to properly communicate with normal people. If you are quite knowledgeable about Norse mythology, this is worth reading just for being a rare refreshing presentation of that material that is quite readable. If you know nothing about Norse mythology but are kind of interested, this book is about as easy as it gets to take a next step. If you don’t know or care about Norse mythology, this book is about the best chance possible for sparking an interest (no, Marvel does not take that honor).

Thanks to the miracle of modern large language models, I was able to generate a very condensed summary of the whole book just so I could remember roughly what this was even about. It should also provide a hint of the kinds of stories in the book.

I asked my robot pal to enumerate ways that Gaiman’s book diverges from typical scholarly treatments of the material and this list pretty much says everything one might need to know.

If you didn’t know the book existed, now you do. If you weren’t sure if you wanted to read it, hopefully that’s been solved now too.

When I signed up for ChatGPT’s paid service, I knew it was worth it for me to properly explore this astonishing technology. I also knew I wouldn’t be paying for long. I’ve done a little work with some open source models and I’ll write about them later. However, it is probably smart at this point to let that community catch up a bit. But today the new hotness is Claude AI. If you have used ChatGPT, it will not completely blow your mind — of course if you haven not, it will! But it is another strong option in publicly available easy to use web-based AI chatbots.

I’ve just started playing with it and I find its prose wonderfully competent. I’m not sure about its technical abilities but it is clear that this bot is a worthy alternative to ChatGPT. I figure it can not hurt to have multiple AI agents to work with on solving problems.

I’ll show a quick interaction because I was struck by the sophistication of the responses. That is, if I received this from a real human, I would be fairly certain that I was dealing with an especially intelligent real human. This example also shows a usage annoyance — solved.

This is a conversation I had about how difficult it is to clear previous chats, something it, itself, suggested is not even possible. We’ll pick up after it hints to me that the previous conversations are stored locally somehow.

So there you go. That is about as eloquent and gracious as a completely wrong answer can get!

Another quick tip is that it has a helpful attachment upload, but I found it could get confused if you uploaded something with unusual naming. For example, I had to rename assembly_code_sample.s to assembly_code_sample.s.txt before it could handle it. On the plus side, it was happy to have a conversation with me about some assembly code!

Give claud.ai a try. Let me know what you discover!