Closed stanio closed 2 weeks ago
FWIW, here's the relevant oh-my-posh debug cmd --plain
output when in non-writable directory such as C:\Windows\System32
:
[TRACE] 08:22:52.934 text.go:Render({{ if not .Segments.Path.Writable }}white{{ end }}) - 0s
[DEBUG] 08:22:52.934 win32_windows.go:isWriteable:258 → not current user or in group
[DEBUG] 08:22:52.934 win32_windows.go:isWriteable:258 → not current user or in group
[DEBUG] 08:22:52.934 win32_windows.go:isWriteable:258 → not current user or in group
[DEBUG] 08:22:52.934 win32_windows.go:isWriteable:258 → not current user or in group
[DEBUG] 08:22:52.934 win32_windows.go:isWriteable:262 → current user is member of S-1-5-32-544
[DEBUG] 08:22:52.934 win32_windows.go:isWriteable:270 ↓
SYNCHRONIZE
DELETE
READ_CONTROL
[DEBUG] 08:22:52.934 win32_windows.go:isWriteable:262 → current user is member of S-1-5-32-544
[DEBUG] 08:22:52.934 win32_windows.go:isWriteable:270 → GENERIC_ALL
[DEBUG] 08:22:52.934 win32_windows.go:isWriteable:262 → current user is member of S-1-5-32-545
[DEBUG] 08:22:52.934 win32_windows.go:isWriteable:270 ↓
SYNCHRONIZE
READ_CONTROL
[DEBUG] 08:22:52.934 win32_windows.go:isWriteable:262 → current user is member of S-1-5-32-545
[DEBUG] 08:22:52.934 win32_windows.go:isWriteable:270 ↓
GENERIC_READ
GENERIC_EXECUTE
[DEBUG] 08:22:52.934 win32_windows.go:isWriteable:258 → not current user or in group
[DEBUG] 08:22:52.934 win32_windows.go:isWriteable:258 → not current user or in group
[DEBUG] 08:22:52.934 win32_windows.go:isWriteable:258 → not current user or in group
[DEBUG] 08:22:52.934 win32_windows.go:isWriteable:258 → not current user or in group
[DEBUG] 08:22:52.934 win32_windows.go:isWriteable:258 → not current user or in group
[DEBUG] 08:22:52.934 win32_windows.go:isWriteable:276 → no write access
[TRACE] 08:22:52.934 terminal_windows.go:DirIsWritable() - 998.3µs
[TRACE] 08:22:52.934 terminal.go:TemplateCache() - 0s
@stanio it's not the .Writable
property that's incorrect but the fact that we now render this in parallel and cross template properties no longer work reliably in the color templates. I never assumed this would be something would do, it's actually easier to reuse the path
segment for this, where it should work as the os
segment is rather empty and all properties you use are available to any template before rendering.
If I'm getting it right, I'll need to reference .Segments.Os.Icon
in a path
segment, and I still need to have the os
segment defined. Is it possible to have an empty segment?
{
"alias": "Os",
"type": "os",
"style": "plain",
"template": ""
},
{
"type": "path",
"style": "diamond",
"leading_diamond": "\ue0b6",
"trailing_diamond": "\ue0b0",
"template": "{{ if .WSL }}WSL at {{ end }}{{ .Segments.Os.Icon }} ",
"foreground": "black",
"background": "magenta",
"background_templates": [
"{{ if .Root }}red{{ end }}",
"{{ if not .Writable }}white{{ end }}"
]
}
An empty os
template definition results in the default segment template being used, and a whitespace-only template prevents the cross-reference in the next segment from working.
@stanio I'll check how to do this during lunch. If something is missing, I'll make sure to do a change.
@stanio found another issue while figuring this out and adding support isn't that much of a change. I'll test this a final time tomorrow and will release.
@JanDeDobbeleer, thank you for looking into it.
In the meantime, I've tried:
{
"type": "os",
"style": "plain",
"template": " \u0008" // backspace
},
and (when it is the first on the line):
"template": "\u000D" // carriage return
effectively achieves an empty segment from which I could cross-reference .Segments.Os.Icon
.
@stanio that's pretty smart, I fixed the issue in the meantime in #5820, thanks for noticing this one. I think the solution now covers more use-cases and can also be extended if it turns out people use cross segment properties in other places.
Tested with OMP v24.0.8, my original configuration referencing .Segments.Path.Writable
from an os
segment works as expected.
@stanio thanks for confirming!
Stopped working again after updating v24.0.11 → v24.1.0. The wrong .Segments.Path.Writable
value appears constant this time. The workaround using an os
"template": " \u0008"
segment, and referencing .Segments.Os.Icon
from a path
segment works, though.
@stanio fixed in latest.
Thank you. Works again for me using v24.2.1.
Code of Conduct
What happened?
After upgrading from v23.20.3 → v24.0.2, and currently on v24.0.4, I've noticed a
.Segments.Path.Writable
template condition:stopped working. More accurately it fails to indicate a writable directory more often than it works as expected (white indicates non-writable directory, while purple is normal/writable):
Theme
Custom
```jsonc { "$schema": "https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/main/themes/schema.json", "blocks": [ { "type": "prompt", "alignment": "right", "segments": [ { "properties": { "style": "round" }, "style": "plain", "template": "{{ .FormattedMs }} | ", "foreground": "darkGray", "background": "", "type": "executiontime" }, { "style": "plain", "template": "{{ if .SSHSession }}\uf817 {{ end }}{{ .UserName }}@{{ .HostName }}", "foreground": "green", "background": "", "type": "session" }, { "properties": { "root_icon": "root" }, "style": "plain", "template": " as \uf0e7", "foreground": "red", "background": "", "type": "root" } ] }, { "type": "prompt", "alignment": "left", "segments": [ { "style": "diamond", "leading_diamond": "\ue0b6", "trailing_diamond": "\ue0b0", "template": "{{ if .WSL }}WSL at {{ end }}{{.Icon}} ", "foreground": "black", "background": "magenta", "type": "os", "background_templates": [ "{{ if .Root }}red{{ end }}", "{{ if not .Segments.Path.Writable }}white{{ end }}" ] }, { "properties": { "folder_separator_icon": " \ue0b1 ", "home_icon": "\udb80\udedc ", "max_depth": 4, "style": "agnoster_short" }, "style": "diamond", "leading_diamond": "What OS are you seeing the problem on?
Windows
Which shell are you using?
bash, cmd
Log output