Function List incomplete
-
Any part of the source that matches the
commentExpr
of the parser is skipped during the search for class, method and function definitions.
For the majority of the available parsers this feature is used to prevent detection of function definitions in text definitions (aka string literals). The detection of string literals highly depends on the proper i.e. quote balanced text definitions. Any improper definition can lead to all kinds of unexpected results.For instance double quoted string literals start and end with a double quote and any double quote within must be escaped.
AFAICT a lot of the double quoted string definitions in the provided source contain un-escaped double quotes.
-
@MAPJe71 said in Function List incomplete:
For instance double quoted string literals start and end with a double quote and any double quote within must be escaped.
This is true, except when using a subshell call : $( … ). The double quotes within the subshell execution are treated separately from the string literal definition. At least that’s the way I’ve learned to use them in Shell scripting.
AFAICT a lot of the double quoted string definitions in the provided source contain un-escaped double quotes.
For those strings within a string, yes, they are escaped. For those commands being executed within a subshell call, and the results being returned and stored as a String, no.
-
those strings within a string
for the parser (presuming
...
does not contain double quotes):
string_literal_name=" ... \" ... \" ... "
string_literal_name="${ ... \" ... \" ... }"
and those strings within a string within a string:
string_literal_name="${ ... \" ... \\\" ... \\\" ... \" ... }"
commands being executed within a sub shell call, and the results being returned and stored as a String
string_literal_name=${ ... }
The parser will see at least two string literals in the following line:
string_literal_name="${ part1 " part2 " part3 }"
i.e."${ part1 "
and" part3 }"
-
@MAPJe71 said in Function List incomplete:
for the parser (presuming
...
does not contain double quotes):
string_literal_name=" ... \" ... \" ... "
string_literal_name="${ ... \" ... \" ... }"
and those strings within a string within a string:
string_literal_name="${ ... \" ... \\\" ... \\\" ... \" ... }"
commands being executed within a sub shell call, and the results being returned and stored as a String
string_literal_name=${ ... }
The parser will see at least two string literals in the following line:
string_literal_name="${ part1 " part2 " part3 }"
i.e."${ part1 "
and" part3 }"
Is it safe to assume that your use of the curly braces in lieu of the parentheses is accidental?
-
@greg-michael Yes