AW: Platform-specific file path delimiters
Tiemo Hollmann TB
toolbook at kestner.de
Thu Sep 24 07:21:19 EDT 2015
Good to know!
Though I knew, that I could have only used "/" for all platforms, I always
put lots of effort in setting platform specific slashes in every case,
because of "nicer" error messages for the end user.
If you are building a path like specialFolderPath("sdat") & slash & myFolder
etc. and get back any kind or error like path/file not found, on windows it
will look like "C:\ProgramData/myFolder/etc", what puzzled some customers,
telling me, that this strange path with slash and backslash can't work
(though the reason was other)...
I know, that I could have refined the path platform specific only for
messaging, but that was too much overhead for me. In future I will only use
slash and let the customers be puzzled.
Von: use-livecode [mailto:use-livecode-bounces at lists.runrev.com] Im Auftrag
von Mark Waddingham
Gesendet: Donnerstag, 24. September 2015 11:30
An: How to use LiveCode <use-livecode at lists.runrev.com>
Betreff: Re: Platform-specific file path delimiters
On 2015-09-23 21:02, Richard Gaskin wrote:
> It's nice when it works like that. I started using MC on Mac Classic,
> and I ran into path issues early on because IIRC no such accommodation
> was made for the Mac-specific ":" delimiter. Rather than read the
> docs I wrote to Dr. Raney, who referred me to the docs.
As I said, the fact it worked on Windows is entirely down to the Win32 APIs
being lax - not by explicit design:
i.e. Win32 API calls happily treat / the same as \ in many instances - this
was not the case in Mac Classic API calls.
If it had been me doing the Windows port I would have made the attempt to
use such paths on Windows an error -as my personal opinion is that
explicitly delimited strictness is always better than undocumented laxness
in an environment where you intend things to be 'easy to use'.
> So it looks like we're covered: anyone looking for cross-platform
> info can find what they need, and Windows-specific work is still
> supported using Windows-specific path delimiters.
Again, sorry to beat the drum again here - Windows-specific path delimiters
are supported for backwards-compatibility and no more than that, please
avoid using them for new code.
> Why would that be necessary if Windows-specific paths are supported,
> as Mark just described above?
I realize I didn't explain why it is a bad idea to use \ in your paths - I
shall now attempt to do so.
On UNIX systems '\' is nothing special - it can be part of a filename.
This means that LiveCode has to treat it as part of a filename lest you want
strange reports from users of your software when choosing certain filenames
in an open/save dialog causes odd breakage. Now, fortunately, '/' *is*
reserved on all platforms we support - thus this is the path separator that
Now, at the moment, we do not have much if any syntax which directly allows
you to process file paths. However, it is not beyond the realm of
possibility that (at some point) we will add syntax which allows easier
put the filename of filepath "foo/bar/zee.txt"
put the folder of filepath "foo/bar/zee.txt"
This syntax would be predicated on using '/' uniformly as the path separator
for all platforms. We can't make it work for both '\' and '/'
as then it would mean you would not be able to access some valid paths on
UNIX derived systems. Thus any application which does use the
Windows-specific platform separator on Windows would find that they would
not be able to use any new syntax that might appear in the future in this
I should perhaps also point out that there are numerous places in the engine
where it computes the leaf of a filepath - these will not work with '\'
separated paths correctly for exactly the same reason.
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
use-livecode mailing list
use-livecode at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
More information about the Use-livecode