Thanks for the reference. After reading it, the cause of the original problem became clear to me: The SU preferences are stored externally in the Windows Registry or in a Mac plist file. In both cases, the Ruby types that can be stored are limited. So write_default converts most types to character strings and read_default passes them through eval to reconstruct Ruby objects. Any string that begins with ‘/’ will cause eval to start processing a regular expression, and eval will typically conclude that the regex is not correctly formed, raising a SyntaxError. Besides, I don’t need a regex object returned when I read back the path “/Users/steve/Documents/MyMaterials/” even if it could be parsed as a regex!
As @DanRathbun noted in his response (which was posted while I was writing this), for some unstated reason the SU developers decided to trap the error below the API, post a message, but not pass the exception back to where you could handle it. So a “clean” solution isn’t possible.
I see several problems with doing a workaround of the sort described in that previous topic:
First, it relies on empirically determined knowledge of where and using what keys these preferences are stored. Trimble does not document either the mechanism or the keys, so the entire idea involves “reverse engineering” (a possible violation of the EULA), and a risk that they may change the implementation in the future (each version of SU already uses a separate section of the registry or a separate plist file - there would be no issue of compatibility for SU itself).
Second, there is no assurance that SU has yet written the preference value out when your Ruby code tries to read it. It is permissible for a program to hold preferences internally and write them only when the program closes or at any other time it chooses. This issue is compounded on Mac because preferences are cached by the system, which may in turn wait until still later to write them to the physical plist file. One is expected to go through the official macOS preferences API, not to read the plist manually.
Third, there would need to be an equivalent for Mac. There is no equivalent to the win32/registry library provided for Mac. I’m a Mac user. I could not test the Windows version and would have to figure out a clean way to access the Preferences system on my own. Another of the myriad ways in which Trimble has neglected the Mac version of SU compared to Windows!
Fourth, the original problem of correctly converting from stored strings to Ruby objects remains. Your registry/plist reader would need to be aimed at a specific kind of saved preference to know when eval is safe vs needing a workaround.
I spelled out all these objections explicitly to make the point: Trimble needs to provide an official and documented way to access preferences so that we are not relegated to reverse-engineered workarounds. I suppose this topic could be changed to a Feature Request, though it would be of interest only to developers.
Today we have a mess on both Windows and Mac! Some preferences are accessible via things such as OptionsProviders (though it is hit-or miss and the documentation sucks!). Some are accessible via other methods in the Ruby API. And some, like these Files path values are not accessible at all.