On 2019-08-22 21:07, Paul Dupuis via use-livecode wrote:
I reported what I thought was 3 bugs in 1 report in https://quality.livecode.com/show_bug.cgi?id=22213. I have edited that report to focus on a single bug - that the detailed files (and probably the detailed folders) is broken for Unicode as every Unicode character in a file name is encoded as %3F or ?. Originally I had though that meant that there was a problem with urlEncode and urlDecode as per bug https://quality.livecode.com/show_bug.cgi?id=14015 that your references Monte. However, I now consider that urlEncode and urlDecode are NOT broken and bug 14015 is really a Documentation bug that the urlEncode and urlDecode Dictionary entries should be updated.
Also, the detailed files and detailed folders doesn't need an array returned (although that would be nice). This issue is the percent-encoding is not following the standard convention of UTF8 encoding non-ASCII characters before percent encoding. LC should follow industry conventions in this regard.
Strictly speaking urlEncode and urlDecode are indeed not broken - they are just very old. They were implemented when there were no universally accepted industry conventions for encoding of URLs (particularly those containing international characters).
They cannot be changed for obvious reasons - but we could do with urlEncodeRFC and urlDecodeRFC which would be string->string functions which do what is expected today. (And also not encode some characters in a way which is now not the 'standard du jour').
For the same reason that urlEncode and urlDecode cannot be changed, the detailed files/folders cannot be changed.
My general feeling here is that 'the detailed files' and 'the detailed folders' should be put out to pasture as they are grossly inefficient and difficult to work with.
Instead new functions 'fileInfo' and 'folderInfo' could replace them. They would take one or two parameters, the first a filename and the second an optional attribute.
If no attribute is specified then an array of all known attributes for the platform is returned; otherwise that specific attribute is returned.
e.g. fileInfo("foo.txt", "modification time") -> returns the modification time of foo.txt fileInfo("foo.txt") -> returns an array with keys such as "modification time" mapping to the obvious thing
I'd probably vote for the functions returning empty if the target didn't exist (rather than throwing an error), for the simple reason as you can't check for existence of a file and get its details in an atomic fashion (another process could decide to delete the file you just asserted existed between the 'there exists' and the 'fileInfo' call).
Warmest Regards, Mark. -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
