Replies: 1 comment
|
I think it sounds like a helpful expansion of capability. The last benefit you mentioned — a more capable autocomplete — is actually something that had just started rattling around in my head over the last few days. I hadn't gotten so far as to even sketch the idea, but I knew it would involve a more complicated function and scope, and I wasn't sure if I'd be able to get there for the reasons you just mentioned. The syntax you're floating seems reasonable. It's consistent with the rest of the string-building approach. 👍🏽👍🏽 |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
I've been mulling over the idea of enhancing the
%( ... )string syntax to bring it some templating capabilities.The original purpose of the string builder,
%(), was to allow for nested quotation marks. Too often in shell scripting, you run into issues where you need to nest quotation marks:While the above isn't a practical, real-world, way you'd approach that problem, it is a good illusatration of the more generalised problem.
With the string builder operator, you could then nest strings like follows:
...which is massively more readable and easier to reason about.
However one limitation of the string builder is that it doesn't support escaping. Which make it annoying to use with variables. For example
...would output "bob" because the variable is expanded rather than escaped. Thus you still end up having to write code like:
And it gets even more annoying if you want nested quotes because you then need to nest the escape character, eg
\\\$name.I cannot speak for everyone, but this is a pet peeve of mine.
Possibly Solution
Since the
%()syntax is already described as a "string builder", then why don't we make it more intelligent?Let's say we want
$nameto be expanded within a particular scope of quotation marks, we could add the%sigil to the variable. For example...would then guarantee that
$nameisn't expanded untilechoexpands its%()string. This then gives us guarantees about the scoping of variables without worrying about correctly nesting escape characters.Template Functions
Why stop there, though? Perhaps we could have functions that are only evaluated when that string is evaluated. For example:
In the above,
datetime "{py}%A"would print the day of the week, egWednesday. So the above string would check the day of the week only when the last echo goes to expand its parameters.The main benefit here would be for things like autocomplete or other syntax where shell script functions are inlined inside documents like JSON.
What are people's thoughts?
All reactions