Carets in script args require double-escaping on Windows

[rads]

Overview

On Windows, each bbin script has a .bat wrapper that interprets ^ in the args as an escape character. There appear to be two levels of escaping because you need to write ^^^^ to pass a single ^ to the bbin script. This problem doesn't happen on macOS/Linux because zsh and bash interpret ^ as a literal character.

I did a little research and I couldn't find an easy way to fix this while still keeping the .bat wrappers. I'm not sure how to fix this issue.

Steps to Reproduce

1. Start with a script called foo.clj:

(prn *command-line-args*)

2. Install the script:

$ bbin install foo.clj

3. In zsh and bash, carets don't need to be escaped to be passed through:

   $ foo ^hello
   ("^hello")
   

   In PowerShell and cmd.exe, carets need to be escaped four times:

   $ foo ^hello
   ("hello")
   $ foo ^^hello
   ("hello")
   $ foo ^^^^hello
   ("^hello")
   

[borkdude]

Is the ^ character important to bbin itself? I don't think bbin should compensate shell escaping rules, people should just escape according to their shell themselves when typing commands?

[rads]

In PowerShell you don't normally have to escape carets:

bb -e '(prn *command-line-args*)' ^hello
("^hello")

In cmd.exe you escape carets using ^^:

bb -e '(prn *command-line-args*)' ^^hello
("^hello")

This means you have to use different escaping rules for bbin scripts as opposed to other commands within the same shell. The difference in behavior comes from the wrapper .bat script, but bbin doesn't tell users that the .bat script exists.

For context, I discovered this indirectly when I was debugging why the Windows tests were failing in my refactoring branch. The tests were failing because we have a test-only git-wrapper.bat file and some of the carets were getting stripped from valid Git commands. I plan to fix that separately from this issue in the refactoring branch.

As I mentioned, I don't know of any easy fixes for this, so it might not be worth fixing in the short-term. That said, I wanted to document the difference in escaping behavior in case anyone else runs into it.

[borkdude]

Right. I'm also not sure of a good solution. Other programs sometimes work around this by creating an .exe shim for a script. scoop does this I think. Not sure if that's possible/easy to do. So... I asked Claude if this was possible. And yes, it seems possible to do... :)

See the end of this conversation.: https://claude.ai/share/c6512601-728d-436d-9c97-182d53976cc6

[rads]

The .exe approach does seem like the right way to address this issue.

[rads]

I accidentally hit the close button while typing my earlier comment. Woops!