I noticed that recently and on one site welcomed a more “Linux-like” behavior but now realize this inconsistency causes some major interoperability issues.
In essence the node “List Files/Folders” always uses “Linux-like” backwards slash. Windows apparently does things differently which requires workflows, in particular when handling files and folders, to be dynamically managed in order to share workflows properly.
This might also become an issue when uploading a workflow, which was created on Windows, i.e. to a Knime Server which might run on Linux. The necessary manual adjustments are not only a point of failure but also hinder efficiency.
The issue emerges from the greater picture. Albeit being supported by Windows, it’s inconsistent and regular / casual users might get confused. Thinking a few steps ahead, though, this inconsistency can become a problem when:
External Tools are used in combination with Knime
When data is exchanged and i.e. Excel need to open / process the data
There is another issue. On Linux paths with whitespace(s) require these to get escaped making this inconsistency even more complex. But let’s ignore that for the moment as this aspect, from my perspective, is strongly related to full automation of path / location handling.
There are also some quite elaborate exchanges out there about this “generic” inconsistency like:
Overall, the path treatment, in particular when we think about cross platform compatibility and data inter-compatibility can become quite tricky to handle and consistency is key to predictability. I.e. imagine the follow scenario. The first works, the second fails.
C:\Users\USER\Downloads\test space
C:/Users\USER/Downloads/test\ space
Again, this relates to a scenario about data inter-compatibility and exchange. Maybe, this issue is rather specific and has little impact as not many Knime users create easily exchangeable, meaning plug & play like, workflows.
As I said Windows in general can handle with forward slashes therefore any external program that you call should be able to deal with it.
Spaces in paths only must be escaped if you are in a shell where the space is usually the delimiter between arguments to a program call. But they must be escaped on all operating systems. And the backslash is also only an escape character in a shell.
If you come up with a real problem then we can have a look at it.
Spaces are not always escaped. As follows an example which putting the interoperability at display.
Anyhow, as you do not consider the inconsistency as an issue in the explained scenarios, which I’d describe as quality of live functionality, users must deal with these specific scenarios on demand.
I’m not sure what you want to say with this example. Obviously, you can either escape a space with a backslash in a shell command or put the argument into quotes. I don’t see what this has to do with forward vs. backward slashes in KNIME.
On the interoperability: since Linux will not understand backward slashes as path separators the forward slash is the only option to make workflows work reliably on both operating systems.
