Rationale for path canonicalize? #12628
Replies: 5 comments 2 replies
-
There's a related PR that does change nu's behaviour #12515 |
Beta Was this translation helpful? Give feedback.
-
I could totally be making this up due to remembering wrong, but I remember starting to do some canonicalization stuff for 2 reasons.
As I recall, there are a handful of issues of nushell not finding files properly, the most recent that I remember happened when we added XDG_CONFIG_HOME support. |
Beta Was this translation helpful? Give feedback.
-
Thanks @fdncred. Manipulating paths containing symlinks is clearly tricky, and I can see why Nu has taken the solution of canonicalize everything in general. #12515 shows that this is not desirable in general. As do my own examples above. This must be a solved problem. though - it's not as if Nu is the first shell to face this! I am inclined to look into this some more. |
Beta Was this translation helpful? Give feedback.
-
I think it will be worth listing the cases where canonicalize has been used to solve real or potential breakage. Let me start.
|
Beta Was this translation helpful? Give feedback.
-
And separately, potential solutions to these problem cases, which preserve the desired user view of non-expanded symlinks. To open a file relative to another file, we could envisage a In contrast, what Nu currently does could be called early bound canonicalization. I am gently arguing in favour of late bound canonicalization, for reasons of increased usability and greater intuition. But this is early days in this line of reasoning. |
Beta Was this translation helpful? Give feedback.
-
I am trying to understand why Nu does what it does with regard to aggressive canonicalization of paths. I have hunted around various issues and found some snippets, but nowhere did I find a nicely reasoned rationale for this is what Nu does and why. Is there such a thing?
Fully acknowledging that I am coming to this quite late in the piece, my feeling is that I am in the early stages of a long and rewarding relationship with Nu, and so I am wanting to engage in this discussion so that in the long term I have a sense that Nu's handling of paths is conceptually clean.
My perspective is that aggressive canonicalization is conceptually misguided. In particular, the readiness with which Nu resolves symlinks into their canonical paths is quite uncomfortable, and at times, even painful. But rather than simply stating a contrary opinion, I would like to give a handful of examples, and then state my general principle here, with a view to eliciting a helpful discussion.
With Nix Home Manager we find this sort of thing very frequently occuring:
GNU Stow is a useful program for installing unrelated directory trees into a common place (e.g.
/usr/local
) by means of a link farm. Files which end up appearing to live in the same directory are in fact nowhere near each other when symlinks are resolved.Bash has a long-established way of maintaining a logical working directory distinct from the physical one. So users coming from Bash have a certain expectation, for which Nu's behaviour is a bit of a gotcha.
So here's my principle on this. I think somehow these symlinks provide the "public interface" if you like to these paths. Resolving symlinks is rather like violating this encapsulation, and exposing internal details (physical paths) where this is not really appropriate.
Is there a good reason for canonicalizing paths in some cases? Has it perhaps been applied a little too universally?
Beta Was this translation helpful? Give feedback.
All reactions