Replies: 3 comments
-
My vote is to operate the way the user commands. So, if they have a trailing slash, we keep it. If they don't have a trailing slash, we do not add it. This way, it's opt-in and when things go wrong, we can say, "you need to add a trailing slash" or "you need to remove your trailing slash". This also generally goes along with our mantra of not having too much "magic" in nushell. |
Beta Was this translation helpful? Give feedback.
-
im for keeping them as well - in my opinion rsync/etc are the weird ones, but for everyone coming from bash it'd be confusing (and maybe even make some things impossible). but just as a side note: for rsync it dosn't matter since it cant be marked as a path either way since it might contain a host ( |
Beta Was this translation helpful? Give feedback.
-
All right, let's keep the trailing slashes. I've opened PR #12662 to implement this. |
Beta Was this translation helpful? Give feedback.
-
Should Nushell normalize trailing slashes away, or should Nushell keep them as is?
Some commands do care about trailing slash. For example,
mv foo bar
has slightly different semantics thanmv foo bar/
. Same goes withrsync -a /src /dest
andrsync -a /src/ /dest
. Working with these commands will be troublesome if we normalize trailing slashes away.On the other hand, keeping trailing slashes means our path normalization logic is more complex, which might cause other troubles (such as issue #12453).
Currently, Nushell's path normalization functions (such as
expand_path_with()
) is implemented usingPath::components()
, which normalize trailing slashes away. However, due it a bug in the implementation, half of the time it actually keeps the trailing slashes instead (Issue #12602).We need to make a decision. My opinion is that we should keep trailing slashes. But either way, we would be changing the behavior of
expand_path_with()
, and things might break.Beta Was this translation helpful? Give feedback.
All reactions