Problem
Several step display-text emitters wrap names in "..." with no escape convention for embedded quotes:
$"\"{byRef.Script.Name}\" (#{byRef.Script.Id})"
A script literally named O"Brien renders as "O"Brien" (#5). Visually ambiguous; a hand-editor can't tell whether the inner " is a terminator or a literal.
The display-text parser (PerformScriptStep.NamedScriptToken and siblings) uses a greedy .* capture, so the round-trip probably still produces the correct Name value because backtracking finds the rightmost "\s*(#\d+) tail — but this isn't covered by any test, and it's a coincidence rather than a contract.
Affected sites (13 across 7 files)
src/SharpFM.Model/Scripting/Steps/PerformScriptStep.cs:99-100
src/SharpFM.Model/Scripting/Steps/PerformScriptOnServerStep.cs:69-70
src/SharpFM.Model/Scripting/Steps/PerformScriptOnServerWithCallbackStep.cs:77,84
src/SharpFM.Model/Scripting/Steps/GoToLayoutStep.cs:137-138
src/SharpFM.Model/Scripting/Steps/GoToRelatedRecordStep.cs:71,73
src/SharpFM.Model/Scripting/Steps/InstallMenuSetStep.cs:32
src/SharpFM.Model/Scripting/Steps/InstallOnTimerScriptStep.cs:41
Suggested approach
Pick an escape convention (FileMaker's own calc-string convention is doubled quotes: "O""Brien") and apply it consistently:
- Centralise the quote/unquote logic in one helper (e.g.
DisplayQuote(name) / matching unescape in the parser).
- Update the seven emitters to call it.
- Extend
NamedScriptToken / NamedLayoutToken regexes (or replace with a hand parser) to handle doubled quotes.
- Add round-trip tests for names containing
", leading/trailing whitespace, (#...) suffix lookalikes, and empty strings.
Data integrity is probably fine today; this is a UX/contract issue. Lower priority but worth closing the loop.
Problem
Several step display-text emitters wrap names in
"..."with no escape convention for embedded quotes:$"\"{byRef.Script.Name}\" (#{byRef.Script.Id})"A script literally named
O"Brienrenders as"O"Brien" (#5). Visually ambiguous; a hand-editor can't tell whether the inner"is a terminator or a literal.The display-text parser (
PerformScriptStep.NamedScriptTokenand siblings) uses a greedy.*capture, so the round-trip probably still produces the correctNamevalue because backtracking finds the rightmost"\s*(#\d+)tail — but this isn't covered by any test, and it's a coincidence rather than a contract.Affected sites (13 across 7 files)
src/SharpFM.Model/Scripting/Steps/PerformScriptStep.cs:99-100src/SharpFM.Model/Scripting/Steps/PerformScriptOnServerStep.cs:69-70src/SharpFM.Model/Scripting/Steps/PerformScriptOnServerWithCallbackStep.cs:77,84src/SharpFM.Model/Scripting/Steps/GoToLayoutStep.cs:137-138src/SharpFM.Model/Scripting/Steps/GoToRelatedRecordStep.cs:71,73src/SharpFM.Model/Scripting/Steps/InstallMenuSetStep.cs:32src/SharpFM.Model/Scripting/Steps/InstallOnTimerScriptStep.cs:41Suggested approach
Pick an escape convention (FileMaker's own calc-string convention is doubled quotes:
"O""Brien") and apply it consistently:DisplayQuote(name)/ matching unescape in the parser).NamedScriptToken/NamedLayoutTokenregexes (or replace with a hand parser) to handle doubled quotes.", leading/trailing whitespace,(#...)suffix lookalikes, and empty strings.Data integrity is probably fine today; this is a UX/contract issue. Lower priority but worth closing the loop.