Normalize paths between unix and windows environments

[balupton]

Both of these issues have been due to windows handling paths to unix:

• How to add layouts into folders #533 Not able to do nested layouts on windows (fixed in v6.42.2)
• slash vs backslash error on Windows with Docpad generate --env static #518 URLs have backslashes instead of forward slashes + paths not joined correctly (fixed in v6.42.1)

However, it seems that this is going to be an ongoing thing, and to accomplish importer support #500 we will need a way to normalize this across different environments. For instance, syncing the database between a windows and mac environment will need a consistent storage format for the paths in the database.

As such, we will need to make the decision to only allow forward-slashes, and to convert back-slashes to forward slashes. This will mean we will also have to drop support for paths that genuinely have a back-slash in them, this should be such a small edge case, it is not worth consideration.

Can I please get some feedback on this move, as I'm ready to implement the change now.

---

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

[balupton]

@jhuntdog @chase @kr1zmo @mikeumus keen to hear your thoughts

[balupton]

An alternative to this proposal is to have normalization occur outside of the file attributes, for instance just in our helper methods. However, then it becomes a game of cat and mouse, the fix will always be opt-in and as-discovered basis. See 9689fad for #533 and 83a50b9 for #518

As well as meaning that we have to do our already existent path normalization in our test suite, which is very annoying. See eeacd91

[jhuntdog]

The first proposal works great for me and definitely seems preferable. Would this eliminate need for methods like replace(/[\\]/g, '/') in 83a50b9?

Working on both Windows and Linux, definitely appreciate your work on path normalization.

[balupton]

Yeah, so the proposal for this issue is to normalize the path variables as soon as possible. This also means that we will drop all of the pathUtil.joins in favour of just a a+'/'+b instead, as pathUtil.join also introduces the backslash. Perhaps the way this will be interested is to listen to any sets, and if it is settings a variable that ends in Path then we apply that regex you mentioned.

The idea with this is that the user never has to worry about whether they need back-slashes or forward-slashes, as well as having a consistent database across platforms.

[balupton]

Just pushed up the fix for #533 to v6.42.2. Still keen to get feedback on this proposal :)

[jhuntdog]

Sorry for not getting back sooner. Everything has been working well for me on Windows and ubuntu.

I'm not experienced enough to comment on best practices regarding timing of path variable normalization or whether to engage the normalization rules depending on OS environment.

Thanks for all your work, especially the recent developments.

[jasonw22]

The proposal sounds good to me.

[balupton]

This is up next for me.

[ghost]

I'm late, sorry for not posting a reply more soon. I'm in support for requiring forward slashes.

I might add:
If you allowed both, then a user, regardless of the system they use (unix/windows), could utilize what they are comfortable with on either system and have it function the same. Though this seems contrived. A Unix (and Linux) user, most likely, would never want to use backslashes on Unix regardless if they migrated from a Windows-based system.

Once again, I'm for requiring forward slashes.

[greduan]

I agree with @kr1zmo on the forward slashes. They make way more sense and it's a trivial change for Windows users.