broot --install on Windows PowerShell updates the wrong Profile.ps1 file
alexxbb opened this issue · comments
>> broot --version
>> broot 1.30.0
>> broot --install
Writing br shell function in C:\Users\arusev\AppData\Roaming\dystroy\broot\data\launcher\powershell\1.
Creating link from C:\Users\arusev\AppData\Roaming\dystroy\broot\config\launcher\powershell\br.ps1 to C:\Users\arusev\AppData\Roaming\dystroy\broot\data\launcher\powershell\1.
C:\Users\arusev\OneDrive - XXX\Documents\WindowsPowerShell\Profile.ps1 successfully patched.
However, my Profile file is different:
>> echo $PROFILE
>> C:\Users\arusev\OneDrive - XXX\Documents\PowerShell\Microsoft.PowerShell_profile.ps1
I'd like rusticians with knowledge of Windows to have a look there.
However, my Profile file is different:
But br
still works, right?
So imo what broot does here is correct, and the best option as well.
But
br
still works, right?
Unfortunately no, I had to manually source the broot ps1 script in my $PROFILE
, then br
started working.
Right, I missed that you're probably running PS Core, hence it looks in $HOME\Documents\PowerShell
not $HOME\Documents\WindowsPowerShell
(but note that PS will load both $HOME\Documents\PowerShell\Profile.ps1
and $HOME\Documents\PowerShell\Microsoft.PowerShell_profile.ps1
). I'm not sure if it's broot's job to fix this. Plus from a brief look over the code, it could be non-trivial to implement because the installation doesn't run in the shell but in Rust, and I'm not sure if that somehow has access to the shell which launched it somehow: ideally this should access $PSVersionTable
or similar to check what it's being ran on.
Anyway, the typical fix for this PS/PS Core discrepancy is symlinking the WindowsPowershell to the Powershell directory or vice-versa.
I think we should be revisiting this; the install script is currently in a broken state anyway* and we need to get eyes on it.
*: Last I checked, needs to be installed twice before br works, and then br will have you install it a third time 🤪
Note: PScore is typically referred to as pwsh, while the version currently bundled with Windows is referred to as WindowsPowerShell. This will be the familiar nomenclature to anyone who opted to install pwsh.
I propose the following change:
- Respect the $PROFILE env var. Do not just assume profile.ps1. It creates unnecessary clutter and confusion. If we're using
Microsoft.PowerShell_profile.ps1
then that's what you should be patching. I'd also suggest that the above should be the preferred default instead ofProfile.ps1
, when creating the profile for the user. - If the user has pwsh, patch pwsh and not WindowsPowerShell, unless maybe we're willing to add a y/n prompt, or implement more involved logic to detect if symlinks/sourcing are in play.
By the by,
Instead of symlinking, you may want to /source/ one profile from the other. Also, implement guard statements for things that are not supported in the older powershell 5.
If ((Get-Host).version.major -gt 5) {
// this won't run in powershell 5
}
A focused PR not touching other systems could be welcome here.
Encountered exactly this issue today.
scoop install broot
broot --install
Still changes E:\Windows\Documents\WindowsPowerShell\Profile.ps1
and doesn't touch E:\Windows\Documents\PowerShell\Microsoft.PowerShell_profile.ps1
so br
doesn't work. Writing the patch to $profile
seems quite reasonable.