Describe the bug
I tried to run this simple command and it failed echo "\"foo\""
To Reproduce
Steps to reproduce the behavior:
echo "\"foo\""
Expected behavior
it should echo "foo"
Configuration (please complete the following information):
Add any other context about the problem here.
❯ echo "\"foo\""
error: Parse Error
- shell:1:14
1 | echo "\"foo\""
|
I think it would be useful inside double quotes (at least) to handle C-style escape sequences. I suggest at minimum a union of JSON escape sequences and bash echo -e escape sequences. That removes the need for echo -e and generalizes it nicely.
An example simple use-case: I mentioned in issue #1570 it would be useful to add options to the to-html command to specific escapes sequencs before and other the resulting html. That would be a lot easier if escapes were part of the string syntax instead of a special case for the echo command.
For now, you can use single quotes if all you need in your string are double quotes:
❯ echo '"test"'
"test"
Now, if we wanted to mix the two, we're back to the same problem. We've been discussing escaping a ton. Our major issue with escaping with backslashes is that, although it may be familiar, is not very expressive. We may experiment with something else 🙂
_"Our major issue with escaping with backslashes is that, although it may be familiar, is not very expressive."_
What are you trying to express that backslashes don't give you? More complex "here document"-style multiline strings? Do you have a link to a discussion? Kawa multi-line strings has some ideas you might find interesting, though you probably don't want the escape character to be & (chosen for XML compatibility).
Another thing to consider is structured strings, such as you might use for documentation that contain a mix of objects (elements) and text (like HTML). It is also useful (for a programming language if not a shell) to have an extensible syntax for literals of various kinds of objects. The SRFI-108 Scheme extension (implemented in Kawa) is quite flexible (thought again you probably don't want to use & as the escape character).
What are you trying to express that backslashes don't give you? More complex "here document"-style multiline strings?
\n is not expressive. It's familiar, but in no way is it clear what it's supposed to be. Something like {newline}, for example, is quite expressive. I'm not sure of the right balance between expressiveness and conciseness. I think nushell needs a set of goals/values to help prioritize these kinds of decisions 🙂
Do you have a link to a discussion?
Nope, not at the moment. It was just a few discussions that came up in private. Note, no decisions were made, just relaying some of the thoughts on this topic. I'll try to make sure these kinds of discussions get to associated GitHub issues in the future 📝
Kawa multi-line strings has some ideas you might find interesting, though you probably don't want the escape character to be & (chosen for XML compatibility).
Thanks for the links. I think having some pre-existing art to compare and contrast will be good for creating a good proposal.
We added interpolation strings (backticks) and a character command (`char), which would be a start, but likely not entirely what we would want to end up with given it's lengthiness:
> echo `here's a{{$(char tab)}}tab`
here's a tab
We should keep thinking about how to shorten that some more, without losing too much expressiveness.
Most helpful comment
I think it would be useful inside double quotes (at least) to handle C-style escape sequences. I suggest at minimum a union of JSON escape sequences and bash
echo -eescape sequences. That removes the need forecho -eand generalizes it nicely.An example simple use-case: I mentioned in issue #1570 it would be useful to add options to the
to-htmlcommand to specific escapes sequencs before and other the resulting html. That would be a lot easier if escapes were part of the string syntax instead of a special case for theechocommand.