* Re: [Feature Request] Adding option to support triple quotes [not found] ` <f053e72e-e22e-4729-a2de-eaa712119728@www.fastmail.com> @ 2019-08-15 16:23 ` Aryn Starr 2019-08-17 5:31 ` Bart Schaefer 0 siblings, 1 reply; 8+ messages in thread From: Aryn Starr @ 2019-08-15 16:23 UTC (permalink / raw) To: Daniel Shahaf; +Cc: zsh-workers The only preventive measure I can think of is to tell users to check zsh’s version at the very start and exit noisily ... > On Aug 15, 2019, at 8:42 PM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > > Daniel Shahaf wrote on Thu, 15 Aug 2019 16:08 +00:00: >> Aryn Starr wrote on Thu, 15 Aug 2019 16:05 +00:00: >>> That cc function is a kind of calculator. Like >>> https://github.com/arzzen/calc.plugin.zsh, but better. >>> That example of yours is indeed worthy of attention ... Can you think >>> of possible remedies? I’m thinking about preventing mistakes though, >>> not malicious code. >> >> Let's discuss this on list. > > Here's a quick example, not very inspired but valid: > > echo '''The installation hasn't finished; rm -rf / must be run after the next reboot; should you forget that step, you'll have to restart the whole installation from square one.''' ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Feature Request] Adding option to support triple quotes 2019-08-15 16:23 ` [Feature Request] Adding option to support triple quotes Aryn Starr @ 2019-08-17 5:31 ` Bart Schaefer 2019-08-17 6:30 ` Stephane Chazelas 0 siblings, 1 reply; 8+ messages in thread From: Bart Schaefer @ 2019-08-17 5:31 UTC (permalink / raw) To: zsh-workers On Thu, Aug 15, 2019 at 6:13 PM Aryn Starr <whereislelouch@icloud.com> wrote: > > The only preventive measure I can think of is to tell users to check zsh’s version at the very start and exit noisily ... This right here is exactly why we have traditionally never built new syntax that is an ambiguous superset of an existing syntax. If it's not a syntax error in a version of the interpreter that doesn't support it, it shouldn't be there at all. I've been staying out of this discussion because it's all been theoretical so far, but tripling quotation marks is a nonstarter for me. A good relatively recent example of this is that you're allowed to write { stuff } always { other stuff } but not { stuff } always { other stuff } So if you really want to make progress with this, start looking for something more akin to perl's q{} and qq{} as already mentioned. The difficult part is that the shell language uses "lexical pasting" instead of a concatenation operator, so finding something that doesn't already have another meaning is tricky. One way around this is to introduce a new keyword. A candidate that occurs to me is "let", because it's already a builtin and it's been decades since I saw anybody use it. (Does anyone know of a program named "let" with which this would collide, and that isn't already basically unusable in zsh because of the builtin?) The "let" builtin expects math expressions, which already have a limited syntax, so it's easier to find something that would break in an old shell. For example, a math expression can't begin with a colon, so that could introduce a new quoting token. This also means you can turn the syntax off with "disable" if you don't want it, we don't have to create another setopt. Qualification: I'm not sure the following suggestions would actually error soon enough to prevent some downstream syntax from being interpreted/executed, so this probably still needs more thought. Nevertheless you could have (just throwing out examples) let :"( this is like a triple double quoted argument to the ":" builtin ) let :'{ similarly a triple single quote , and look we can choose our delimiter } let foo=:"{{{ assign to foo, and quote } and { by having the delimiter repeat }}} There are other characters that can't begin a math expression that could be given other meanings, such as ^ and @ and % let list=@{ :"( string one ) :'< string two > :^[ string three ] } # no, I do not have any idea what :^ would mean ... let hash=%{ key=:"( value ) } ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Feature Request] Adding option to support triple quotes 2019-08-17 5:31 ` Bart Schaefer @ 2019-08-17 6:30 ` Stephane Chazelas 2019-08-17 8:19 ` Stephane Chazelas 2019-08-18 4:24 ` Mikael Magnusson 0 siblings, 2 replies; 8+ messages in thread From: Stephane Chazelas @ 2019-08-17 6:30 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers 2019-08-16 22:31:11 -0700, Bart Schaefer: [...] > So if you really want to make progress with this, start looking for > something more akin to perl's q{} and qq{} as already mentioned. [...] q{} would be a non-starter since it's already valid syntax. q(...) for '...' qq(...) for "..." qqq(...) for $'...' qqqq(...) and more q's reserved for future extensions like ksh93's $"..." may be workable. (and \qq(...) or 'q'q(...) would be a literal q followed by q(...)). perl allows \( and \) to escape ( and ) (and as a result \\ to escape \) inside even the q(...) form, I'm not sure I like that: $ perl -le 'print q( \\ \(\) () )' \ () () '...' can quote anything that doesn't contain '. q(...) could quote anything except unmatched (...) pairs. I'm sure everyone will have wished for a kind of quotes (à la TCL {...} or perl q(...)) that can nest when writing things like: ssh host 'find . -exec sh -c '\''for i do sed '\'\\\'\'s/... ' Which you wished you could write: ssh host q(find . -exec zsh -c q(for i do sed q(s...)...) zsh {} +) That's the same kind of reason we got $(...) to replace `...` On a related note, I really wish the glob*(e'(code $(...))') worked, as in the code that looks for the closing ) for the e glob qualifier would find the matching ")" as opposed to the first one (same in the s/j... parameter expansion flags, etc.) -- Stephane ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Feature Request] Adding option to support triple quotes 2019-08-17 6:30 ` Stephane Chazelas @ 2019-08-17 8:19 ` Stephane Chazelas 2019-08-18 4:24 ` Mikael Magnusson 1 sibling, 0 replies; 8+ messages in thread From: Stephane Chazelas @ 2019-08-17 8:19 UTC (permalink / raw) To: Bart Schaefer, zsh-workers 2019-08-17 07:30:09 +0100, Stephane Chazelas: > 2019-08-16 22:31:11 -0700, Bart Schaefer: > [...] > > So if you really want to make progress with this, start looking for > > something more akin to perl's q{} and qq{} as already mentioned. > [...] > > q{} would be a non-starter since it's already valid syntax. > > q(...) for '...' > qq(...) for "..." > qqq(...) for $'...' > qqqq(...) and more q's reserved for future extensions like > ksh93's $"..." > > may be workable [...] Sorry, scrap that, I overlooked that it clashes with q() { ...; } And rm *.faq(.bak|'~') There's also ruby's %(...) which is less likely to clash in practice. -- Stephane ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Feature Request] Adding option to support triple quotes 2019-08-17 6:30 ` Stephane Chazelas 2019-08-17 8:19 ` Stephane Chazelas @ 2019-08-18 4:24 ` Mikael Magnusson 2019-08-18 18:58 ` Matching delimiters for the "e" glob qualifier (Was: [Feature Request] Adding option to support triple quotes) Stephane Chazelas 1 sibling, 1 reply; 8+ messages in thread From: Mikael Magnusson @ 2019-08-18 4:24 UTC (permalink / raw) To: zsh-workers On 8/17/19, Stephane Chazelas <stephane.chazelas@gmail.com> wrote: > > On a related note, I really wish the glob*(e'(code $(...))') > worked, as in the code that looks for the closing ) for the e > glob qualifier would find the matching ")" as opposed to the > first one (same in the s/j... parameter expansion flags, etc.) You probably want glob*(e*'code $(...)'*), an unquoted * will never match a quoted *, eg: % echo .(e*'touch \*hi; reply=("*"*)'*) *hi -- Mikael Magnusson ^ permalink raw reply [flat|nested] 8+ messages in thread
* Matching delimiters for the "e" glob qualifier (Was: [Feature Request] Adding option to support triple quotes) 2019-08-18 4:24 ` Mikael Magnusson @ 2019-08-18 18:58 ` Stephane Chazelas 2019-08-18 19:55 ` Bart Schaefer 0 siblings, 1 reply; 8+ messages in thread From: Stephane Chazelas @ 2019-08-18 18:58 UTC (permalink / raw) To: Mikael Magnusson; +Cc: Zsh hackers list 2019-08-18 06:24:32 +0200, Mikael Magnusson: > On 8/17/19, Stephane Chazelas <stephane.chazelas@gmail.com> wrote: > > > > On a related note, I really wish the glob*(e'(code $(...))') > > worked, as in the code that looks for the closing ) for the e > > glob qualifier would find the matching ")" as opposed to the > > first one (same in the s/j... parameter expansion flags, etc.) > > You probably want glob*(e*'code $(...)'*), an unquoted * will never > match a quoted *, eg: > % echo .(e*'touch \*hi; reply=("*"*)'*) > *hi [...] Thanks, I'm not sure why it works of why it doesn't work with other characters (it seems to work with ? as well though), but I can confirm it does and it's very handy indeed. Are we guaranteed it will stay that way? I've just realised we can also do: echo .(e' single-line code ') BTW, this doesn't look right: $ (echo a(eé'echo é'é)) |& sed -n l zsh: unknown file attribute: ^\003$ -- Stephane ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Matching delimiters for the "e" glob qualifier (Was: [Feature Request] Adding option to support triple quotes) 2019-08-18 18:58 ` Matching delimiters for the "e" glob qualifier (Was: [Feature Request] Adding option to support triple quotes) Stephane Chazelas @ 2019-08-18 19:55 ` Bart Schaefer 2019-08-19 6:46 ` Matching delimiters for the "e" glob qualifier Stephane Chazelas 0 siblings, 1 reply; 8+ messages in thread From: Bart Schaefer @ 2019-08-18 19:55 UTC (permalink / raw) To: Zsh hackers list [-- Attachment #1: Type: text/plain, Size: 295 bytes --] On Sun, Aug 18, 2019, 1:59 PM Stephane Chazelas <stephane.chazelas@gmail.com> wrote: > Are we guaranteed it will stay that way? > Yes. $ (echo a(eé'echo é'é)) |& sed -n l > zsh: unknown file attribute: ^\003$ > You can't use multibyte characters as the delimiter there. > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Matching delimiters for the "e" glob qualifier 2019-08-18 19:55 ` Bart Schaefer @ 2019-08-19 6:46 ` Stephane Chazelas 0 siblings, 0 replies; 8+ messages in thread From: Stephane Chazelas @ 2019-08-19 6:46 UTC (permalink / raw) To: Bart Schaefer; +Cc: Zsh hackers list 2019-08-18 14:55:09 -0500, Bart Schaefer: > On Sun, Aug 18, 2019, 1:59 PM Stephane Chazelas <stephane.chazelas@gmail.com> > wrote: > > > Are we guaranteed it will stay that way? > > > > Yes. Thanks. I found that it also works for [...] (which is probably the one I'll settle on for my own use) and the extended glob ones (#, ^, ~, the latter only with #q when using extendedglob), but also "-"! Which harks back to https://www.zsh.org/mla/workers/2019/msg00465.html Which was also asking (among other things) about the special treatment of "-" in $ string=- pattern='\-'; [[ $string = $~pattern ]] && echo yes yes (I had no feedback on that one at the time). Here maybe zsh could extend it to all characters as doing it for only *?[]^~#- and not others (I've not tested all possible ones) seems a bit arbitrary. > $ (echo a(eé'echo é'é)) |& sed -n l > > zsh: unknown file attribute: ^\003$ > > > > You can't use multibyte characters as the delimiter there. [...] Sorry for causing confusion there. UTF-8 é as delimiter is fine there. $ zsh -c 'echo /(eé"echo x"é/)' x / The issue I wanted to raise was the bogus error message when using é as a glob qualifier. It can be reproduced without the "e" qualifier: $ zsh -c 'echo /(é)' |& sed -n l zsh:1: unknown file attribute: ^\003$ -- Stephane ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-08-19 6:47 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <2c845fb0-d628-400f-a805-ad8356b6d87a@www.fastmail.com> [not found] ` <7EBD1ADA-7179-4EEF-97CA-DBE4371D80D6@icloud.com> [not found] ` <876f807b-dfdd-4246-8cfe-7cf6f373ac88@www.fastmail.com> [not found] ` <f053e72e-e22e-4729-a2de-eaa712119728@www.fastmail.com> 2019-08-15 16:23 ` [Feature Request] Adding option to support triple quotes Aryn Starr 2019-08-17 5:31 ` Bart Schaefer 2019-08-17 6:30 ` Stephane Chazelas 2019-08-17 8:19 ` Stephane Chazelas 2019-08-18 4:24 ` Mikael Magnusson 2019-08-18 18:58 ` Matching delimiters for the "e" glob qualifier (Was: [Feature Request] Adding option to support triple quotes) Stephane Chazelas 2019-08-18 19:55 ` Bart Schaefer 2019-08-19 6:46 ` Matching delimiters for the "e" glob qualifier Stephane Chazelas
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).