Automatic installation script adds Windows support

[yruson]

I see that the scripts section only supports Mac/Linux, but there are also many Windows users. I suggest adding automatic script support for Windows. Thank you.

[4shil]

Windows isn't supported natively because these scripts use Bash-specific features
(like process substitution < <(...), find -print0, and ANSI color escapes)
and depend on Unix-like core utilities
(sed, awk, find)
that don't exist in the standard Windows Command Prompt or PowerShell.
Maybe a python alternative may help but it wont make it automatic users may still need to run them using python cmds.
you can write a scripts/convert.py and scripts/install.py that do exactly what the Bash scripts do.
Windows users can then simply run:
python scripts/convert.py
python scripts/install.py
but having WSL solves the issue
Consider a PR with the alternative scripts

[RoyCoding8]

I created a PR please have a look...

[KrystofS]

#191 I've created a PR with Python scripts.

• Using WSL is clumsy at best, and I'm not sure if the WSL machine can correctly find and modify all files on the host system to make this work.
• I'm quite opposed to the PowerShell solution, it is IMO hard to read and maintain.
• Bash could be potentially deprecated altogether to simplify maintanance although I have left it untouched for now.

[knoff]

I also created PR #190 in Powershell, as it's more in line with the current implementation. I tried to replicate it as closely as possible, although Windows has its own nuances. In particular, it has already had to be supplemented with fixing problems with Emoji, PowerShell and UTF-8

• Using WSL is clumsy at best, and I'm not sure if the WSL machine can correctly find and modify all files on the host system to make this work.

Personally, I completely agree with this statement, and if we take into account the specifics of the project, WSL may not be deployed or may prove to be extremely complex for some users.

• I'm quite opposed to the PowerShell solution, it is IMO hard to read and maintain.
• Bash could be potentially deprecated altogether to simplify maintanance although I have left it untouched for now.

This is indeed a rather interesting line of thought.
I've already prepared further improvements to the PowerShell solution (removal and cleanup, selective agent installation based on configuration, and along with that, orchestrator improvements), but now they need to be ported back to bash for full compatibility.
Full support for both systems is quite an interesting challenge, and in this context, switching to Python will greatly simplify maintenance. However, it seems the author is more comfortable working in bash, so switching to Python will be his choice for further development of the project.

Let's wait and see which PR he chooses as the starting point for Windows support.

[msitarzewski]

Alright, we now have four PRs tackling this:

• feat: Added Windows support #171 (@RoyCoding8) — PowerShell + CMD wrappers + lint
• feat: add Windows PowerShell installation and conversion scripts #172 (@ALVIN-YANG) — PowerShell, compact style
• feat: add PowerShell support for Windows #190 (@knoff) — PowerShell, close bash replica
• feat: Add Python helper scripts #191 (@KrystofS) — Python scripts

That's a lot of energy aimed at the same problem, which is great — but we can only merge one approach.

The core question: PowerShell or Python?

@KrystofS makes a fair point that Python could simplify long-term maintenance (one implementation for all platforms). On the other hand, the PowerShell PRs stay closer to the existing bash structure.

Rather than me picking a winner top-down, I'd love you four to hash it out and converge on a single PR. Some things to consider:

1. Maintainability — every new tool added to convert.sh would need to be mirrored. Python has an edge here (write once, run everywhere). PowerShell means maintaining bash + PS side by side.
2. User expectations — Python requires a Python install. PowerShell is built into Windows. Bash is built into macOS/Linux. What's the lowest friction for users?
3. Scope — the PR should cover convert and install functionality. Extras like lint support (feat: Added Windows support #171) are welcome but not required for the first pass.

If you can agree on an approach and consolidate into one PR, I'll prioritize reviewing it. Tag me when you're ready.

cc @RoyCoding8 @ALVIN-YANG @knoff @KrystofS

[msitarzewski]

Moved the PowerShell vs Python design discussion to Discussions so it has a better home: #197

Please weigh in there. Once the group aligns on an approach, we'll move forward with a single PR.

[caioreix]

I created a cli to work around this while it is still undefined. It was primarily developed for my own use case, which is installing a specific agent, but it may also be helpful for others who want this on Windows: https://github.com/caioreix/agency-cli

@msitarzewski, my intention ist to promote it, please feel free to delete it if you are not comfortable with it.