feat: add Windows support by handling empty path case in PathSplit function #5944
+1
−1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Goal: Fix
PathSplit
function to handle empty path case forWindows
supportContext: This PR fixes an issue I was having when adding
Windows
support for some of my utilities by updating the function to handle the case when is empty.The issue
When running on
Windows
, I was getting errors because the function wasn't handling empty paths correctly. The problem occurs becauseWindows
uses backslashes (\
) as path separators, so when resolves to\
, the path splitting logic behaves differently than on Unix systems.For example, I was seeing errors like this locally:
Causing a
stack overflow
:click here to see the stack trace... ❗️
Note:
go version go1.24.5 windows/arm64
My proposal
I added a simple check to the existing condition in . This prevents issues when working with
Windows
systems.Why this works
The existing tests already pass with this change, which confirms this change does not impact existing unix support. It is aimed at ensuring consistent behaviour across operating systems without requiring more invasive changes.
Testing notes
The existing tests exclude
Windows
intentionally, and I wasn't sure if adapting them would be straightforward since proper testing needs to be done on aWindows
host where resolves to theWindows
-specific rune.Any form of feedback is greatly appreciated.