3 ms·
The whole article seems to be about bad practices. If the human does not follow good practice is there a reasonable expectation that the AI will? It is possib
by HocusLocus 1y ago
The whole article seems to be about bad practices. If the human does not follow good practice is there a reasonable expectation that the AI will? It is possible that Gemini engaged in these practices also, but it's hard to tell.
"move * "..\anuraag_xyz project"
Whether or not that is a real command or not here is the problem.
"anuraag_xyz project" is SUPPOSED to be a directory. Therefore every time it is used as a destination the proper syntax is "anuraag_xyz project\" in DOS or "anuraag_xyz project/" in unix.
The DOS/UNIX chestnut of referring to destination directories by bare name only was always the kind of cheap shortcut that is just SCREAMING for this kind of thing to happen. It should never have worked.
So years ago I trained myself to NEVER refer to destinations without the explicit [\/] suffix. It gives the 'expected, rational' behavior that if the destination does not exist or is not a directory, the command will fail.
It is doubly absurd that a wildcard expansion might pathologically yield a stack of file replacements, but that would be possible with a badly written utility (say, someone's clever idea of a 'move' replacement that has a bug). But then again, it is possible that an AI assistant would do wildcard expansion itself and turn it into a collection of single-file commands. It may even do so as part of some scheme where it tracks state and thinks it can use its state to 'roll back' incomplete operations. Nevertheless, bare word directories as destinations (without suffix) is bad practice.
But the "x/" convention solves it everywhere. "x" is never treated like anything but a directory, fail-if-nonexistent, so no data is ever lost.