I had a couple rounds where I was trying to fix a bug, and it insisted that it did, when it clearly hadn’t. So I dug deeper to give it some clues.

NO, I was not looking at #/db. I was on the correct page.

This went on a few more times, and the conversation was repetitive, and the writing extremely confident, with an edge of combativeness.

So the chat was activating something where it insisted it was correct.

Eventually, I gave it enough counter-evidence, and it fired up Chrome to use its WebDriver API to peer more deeply into its operation.

Eventually, after many tokens, it figured out that it was using the “.robots-section” selector rather than the “#robots-section” selector to append the HTML to display robots.

This is a really common typo for beginning programmers.

Another Rookie Mistake

This might be a rookie mistake on my part. It’s definitely a rookie mistake on the LLM’s part.

The program uses Unix filepaths. That’s common.

It also uses these paths as a namespace, for non-filesystem uses, like granting permissions, sharing, etc. The path is used as a namespace, and it’s stored in the database. Again, that’s totally common.

However, in it’s use as a namespace, the code was inconsistent in how it indicated the root directory. It used “” as root!

It also stripped the “/” at the end of a directory or namespace.

These are both the wrong way to specify a namespace, if it also maps to a Unix filepath. The error is understandable.

First, though, the correct thing to do is, always have / at the start, and at the end.

# these are good
    /a/b/c/
    /a/b/

# these are not good
    a/b/c
    a/b
    /a
    /a/b
    a/b/c/
    a/b/

The reasons why are kind of tricky to understand.

The leading / is a Unix convention for the root directory. So “/” is root. If you decide to not have that, then “” becomes your root. This is bad for URL parameters, and that was a bug we hit:

# with the /
https://example.com/api/service?folder=%2F
# %2F is the encoded value for /

# without the /
https://example.com/api/service?folder=

# the value of folder is set to "", or it may be set to underfined or null. It's indeterminate and depends on what the programmer thought was correct.

The trailing / is not as important for namespaces, but I habitually require the trailing / when I want to indicate that something is a directory.

In IETF land, trailing slashes are not required, but a trailing slash is distinct from the same URI without it. They are two different things.

https://example.com/foo
https://example.com/foo/    -- different!

The rsync command has clear differences in behavior between a path that ends with a slash, and one that does not.

What happens with rsync?

mkdir a b
# a is a directory, b is a directory
rsync -r a b
rsync -r a/ b/
# this works as expected, the nonexistent "contents" are synced over
rsync -r a b/
# a is copied into b; b/a/ directory is made an copied

Well, that sucks!

My personal solution to this is to enforce the trailing slash on paths that are used in programs, unless it’s referring to an object (like a file).

You don’t need to interrogate if a path is a directory or object — the trailing slash tells you it’s a directory.

Namespaces are like directories.

The LLM had produced code that wasn’t strict, at all. It trimmed the ends for display. It appended the trailing slash, sometimes. Other times, it trimmed an existing trailing slash.

That caused glitches and bugs, so I applied that rule of thumb, where the namespace starts and ends with a slash.

I hope it helps.