Seeking confirmation of a bug...

[Paul Dupuis]

Certainly there is a work around based on extensions. You and I have 
both written them for Researchware ;-) However, Jeanne used this feature 
extensively in a bunch of file i/o code she wrote for Researchware for 
HyperTRANSCRIBE and HyperRESEARCH exports to many formats, which is 
why/how I discovered it. Both HR and HT are in mid-beta on LC9 releases.

I have already written work-around code. What I am really looking for is 
CONFIRMATION this is a bug.

I have not checked LC7 yet, but it was working in LC 6.7.11 and is not 
working in 8.1.10 and 9.0.0 through 9.0.4. I am sometimes astonished 
that a bug like this can go undetected through so many releases. It 
causes me to worry about the adoption of LC as a serious commercial 
application building tool. However, ultimately, LC's many advantages 
outweigh an issue like the length of time this bug has gone undetected.

-- Paul

On 5/16/2019 1:30 PM, Richard Gaskin via use-livecode wrote:
> Paul Dupuis wrote:
>
> > I just filed a serious bug for LC904 that is only under OSX. When
> > using 'asnwer file <prompt> with type <typelist>' the selected type is
> > supposed to be returned in 'the result'. This works as expected under
> > Windows, but under OSX using LC904 STABLE, 'the result' is the same as
> > the 'it', both contain the file path selected.
> >
> > Please see https://quality.livecode.com/show_bug.cgi?id=22070
>
> While it will be useful to have this fixed, the current state of macOS 
> should provide a mildly-tedious-but-not-difficult workaround:
>
> The older Finder type codes (the four-character identifiers hidden 
> away in the file's metadata) are long deprecated, and for more than a 
> decade macOS relies on file extensions to determine type.
>
> Since the range of type options is limited to types you set, a few 
> minutes writing a function to match the file extension with the type 
> categories you provided should at least get you going while waiting 
> for an engine fix.
>
> In the odd case where you may encounter a very old (or misnamed) file 
> that has no type extension in its name, you could extend the function 
> to see if the old Finder type is included in info provided with "the 
> detailed files".
>
> If you were super-thorough, you might even provide another check of 
> file contents to confirm type.  Image formats have magic numbers, and 
> text formats have patterns identifiable within a reasonably small 
> number of bytes.  A short read can confirm the type of misnamed files 
> even beyond what can be expected with "answer file".
>
>
> Psuedocode:
>
>   getFileNameExtension(fileName)
>   if absent
>      getDetailedFilesInfo
>      convertFourCharTypetoExtensionString
>   end if
>   switch fileType
>      case "png"
>      case "jpg"
>      case "jpeg"
>         return "image"
>         break
>      case "text"
>      case "rtf"
>         return "text"
>         break
>    end switch
>    -- bonus:
>    confirmTypeByReadingSomeContent
>
>
> The case block for your supported types is likely still in your code 
> base.  Copying it to a new function and adding the earlier step of 
> handling missing types by Finder code (if not already there) will make 
> short work of this.
>