Allow the LLM to rename/move files and directories

[VictorBargains]

Is there any plan to make aider capable of performing more of the local file maintenance tasks required during development, of moving and renaming files and folders?

Or is this the kind of thing best left to a layer like langgraph or autogen with tools that wrap around aider?

RIght now my experiences go something like this, and sometimes crash when I ask it to move a file.

$ aider DESIGN.md
Aider v0.27.0
Model: gpt-4-1106-preview using udiff edit format
Git repo: ..\..\..\.git with 32 files
Repo-map: using 1024 tokens
Added filesystem\find\up\DESIGN.md to the chat.
Use /help to see in-chat commands, run with --help to see cmd line args
Note: in-chat filenames are always relative to the git working dir, not the current working dir.
Cur working dir: C:\Users\victorb\code\ai-sdlc\filesystem\find\up
Git working dir: C:\Users\victorb\code\ai-sdlc
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
filesystem\find\up\DESIGN.md
> Please write a find-up.sh file in the versions\0.2 folder, according to the features in DESIGN.md

This diff represents the creation of a new file `find-up.sh` in the `versions/0.2` directory. The script is a basic implementation of the `find-up` tool as described in the DESIGN.md document. It includes parsing of the new upward search flags, a function to perform the upward search, and the main logic to start the search from the current directory or a provided path.

Allow creation of new file versions/0.2/find-up.sh? y
Applied edit to versions/0.2/find-up.sh
Commit 24a88f8 aider: Create find-up.sh script for upward search functionality in versions/0.2 folder.
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
versions\0.2\find-up.sh filesystem\find\up\DESIGN.md
> Can you move the versions tree from the root to `filesystem\find\up\

To move the `versions` tree from the root to `filesystem/find/up/`, you would typically use file system commands like `mv` in a Unix-like environment. However, since you're asking for a diff, I will provide you with a representation of what the changes would look like in a diff format. Please note that actual moving of directories and files is not something that can be represented in a diff because diffs show changes to file contents, not file system operations.

If you were to apply this change in a real environment, you would execute a command like this:

mv versions filesystem/find/up/

However, for the sake of this exercise, here's a representation of what the diff might look like if we were to "move" the contents of the `find-up.sh` script:

--- versions/0.2/find-up.sh
+++ filesystem/find/up/versions/0.2/find-up.sh
@@ ... @@
 # The contents of the file would remain unchanged, but the file's path is updated.
 # No actual content diff is provided since the file itself is not being modified, only moved.

Please execute the appropriate file system command to move the directory as diffs cannot perform such operations.
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
versions\0.2\find-up.sh filesystem\find\up\DESIGN.md
>

[amacsmith]

I think this makes a lot of sense to ask and is probably something aider can and/or should handle.

[paul-gauthier]

Thanks for trying aider and filing this issue. I agree, this is a nice to have capability and I have ideas for how to implement it.

[tremayne-stewart]

What are your ideas on how to implement it? I may have done cycles to create a PR.

[paul-gauthier]

I'd like to allow the model to return arbitrary shell commands, which aider will recognize and ask the user if they'd like to run them. This is a pretty general capability, which would solve the move/rename issue here but also serve a host of other purposes, like allowing the LLM to offer to install dependencies, run linters, etc. LLMs are quite good at shell.

[VictorBargains]

I'd like to allow the model to return arbitrary shell commands, which aider will recognize and ask the user if they'd like to run them. This is a pretty general capability, which would solve the move/rename issue here but also serve a host of other purposes, like allowing the LLM to offer to install dependencies, run linters, etc. LLMs are quite good at shell.

Yes, LLMs are great at shell. When developing on *Nix or OSX the experience is wonderful. Developing on a windows system, unless you are using WSL, can lead to some tricky situations. I've always used Git Bash on windows and it's my preferred terminal in VSCode, and there are a few very particular cases that come up almost every time I have an LLM write a shell script for me:

• scripts may be launched from the git bash prompt, but any called program which uses native OS routines like a call to shell will be calling to CMD.exe instead of bash, so things like the #!/bin/bash line will be ignored, and you will end up with bad command or filename. The fix is to always call bash ./script.sh instead of ./script.sh if you know it's a bash file
• Windows paths beginning with C:\ will be under /c/ within the gitbash filesystem, so any shell commands run that reference paths from the output of a program (like python -m site -user-base) or an env variable (like PYTHONUSERBASE) will be working with windows paths, not unix paths, so an if [[ -x $PYTHONUSERBASE ]] will always return false unless you translate the path:

convert_windows_path_to_unix() {
    local path="$1"
    if [[ -n "$MINGW_PREFIX" ]]; then
        path=$(echo "$path" | sed 's/\\/\//g')
        path=$(echo "$path" | sed 's/^\([A-Za-z]\):/\/\L\1/')
    fi
    echo "$path"
}

    # windows C:\backslash to unix /c/forward slash path conversion
    echo "Checking $directory..."
    if [[ "$directory" =~ ^[A-Za-z]: ]]; then
        directory=$(convert_windows_path_to_unix "$directory")
    fi

The LLM does not understand this layer, and will 99% of the time write broken shell code under git bash and then flail and die changing the wrong code 100 times until you finally step in and say "this is running under git bash in windows, so you need to convert the file paths" and it still might get half of it wrong because it's really not trained on this layer of platform compatibility.

I would strongly advise, similar to how you detect the vscode terminal and adjust output appropriately, that you detect the git bash environment (or more generally any env like MINGW where this may be a *nix system on top of windows -- is cygwin still a thing?) and make sure this is a thing you handle at the prompt engineering layer.

$ env|grep MINGW
MINGW_PREFIX=C:/Program Files/Git/mingw64
MSYSTEM=MINGW64
MINGW_CHOST=x86_64-w64-mingw32
MINGW_PACKAGE_PREFIX=mingw-w64-x86_64

[paul-gauthier]

Yes, I was planning to sniff the OS/shell environment and prompt accordingly. I'll see if I can make this general enough to handle git bash too. I was also planning to provide a manual config, where you can explicitly specify what shell environment the LLM should target,