Conversation
WalkthroughAdds support for copying the Wave binary alongside the existing wsh binary during installation and initialization. Introduces a new exported constant wavebase.RemoteFullWaveBinPath set to "~/.waveterm/bin/wave". Updates remote install templates to include a cp step and adds a wavePath template variable. In shell initialization, defines a wave destination path and performs an additional AtomicRenameCopy to that path, updating logs accordingly. Similar cp steps are added for WSL installation templates with error propagation. No changes to exported APIs other than the new constant. Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20–30 minutes Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (4)
🧰 Additional context used🧬 Code graph analysis (3)pkg/wslconn/wsl-util.go (1)
pkg/util/shellutil/shellutil.go (1)
pkg/remote/connutil.go (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
🔇 Additional comments (9)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
thinking about installing "wave" to the path. so instead of users running
wsh [command]they can runwave [command]which would be more intuitive.for now we'd install both, but the idea would be to deprecate wsh, give warning messages about using
wsh, and then in the future remove the wsh name completely.