From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6311 invoked by alias); 31 Dec 2016 18:18:10 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 40251 Received: (qmail 5637 invoked from network); 31 Dec 2016 18:18:10 -0000 X-Qmail-Scanner-Diagnostics: from forward5m.cmail.yandex.net by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(5.255.216.23):SA:0(-0.7/5.0):. Processed in 3.049677 secs); 31 Dec 2016 18:18:10 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=FREEMAIL_FROM, RCVD_IN_DNSWL_LOW,SPF_PASS,T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: kp-pav@yandex.ru X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf-ipv4.yandex.ru designates 5.255.216.23 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1483207890; bh=vuVmi5YGkpOQDIr585/Zc+59uLhdm4QGt6pv0s30iaU=; h=From:To:In-Reply-To:References:Subject:Message-Id:Date; b=sGbUzuURR8eV64BeJnLR4kxsx7kkF1coKgHg9RV3gSYOpaLFgbxHFirmZHc2O0S7S /8xK+paeKNMui7fiOdafN2FT8PaeATL4ih8soXPwOwZKHZsxJzUQMgXdpVu1k2Dhs3 TNrHt6lAoWIylXRl9Vzyeyy1QfDuWI83B+4kjpv4= Authentication-Results: mxback9j.mail.yandex.net; dkim=pass header.i=@yandex.ru From: "Nikolay Aleksandrovich Pavlov (ZyX)" To: Bart Schaefer , zsh workers In-Reply-To: <161229185629.ZM11029@torch.brasslantern.com> References: <1302831483050697@web1o.yandex.ru> <161229185629.ZM11029@torch.brasslantern.com> Subject: Re: indented heredocs MIME-Version: 1.0 Message-Id: <3466861483207890@web23j.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sat, 31 Dec 2016 21:11:30 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 30.12.2016, 05:57, "Bart Schaefer" : > On Dec 30, 1:31am, Nikolay Aleksandrovich Pavlov (ZyX) wrote: > } > } > } 22.12.2016, 01:11, "Bart Schaefer" : > } > I would propose instead something similar (read on below) to this: > } > > } > % cat <<-' xx' > > As has already been pointed out, this can't be used exactly as-is, > because quotes around the end marker already have semantics. > > } This makes changing the indent rather tricky. > > Well ... it means you have to both change the indent and declare that > you've changed it. I wouldn't call that "tricky". “Tricky” here means only “I can’t just use `V)>` in Vim”. Or “when doing refactoring it would be easy to miss necessary changes”. > > } YAML does better here: amount of stripped indent is either determined > } based on the first non-blank line [...] > > This is at least feasible. (Does "non-blank" mean "contains a character > that is not whitespace"? What's whitespace?) I would suggest to mean “space or tab” by whitespace. Generally “anything what may be used for indentation or separating command arguments” (I would not be surprised to hear that I missed that zsh allows using some fancy unicode characters as whitespaces for indentation or separating comand arguments in unicode locales). > > Would we want to strip leading space and tab, or e.g. leading $IFS (with > the probable exclusion of the set $'\f\n\r\v' in that case)? I would expect it to strip leading spaces and tabs (and error out if there are no necessary spaces in a non-blank line). Involving IFS is not needed: it is not checked for indentation or separating command arguments in source code currently after all, only in some expansions and for `read`. Example of error: "cat <<| EOF\n\tabc\n\n def\nEOF" (indent of the third heredoc line is neither preceding the EOF marker nor indent of the first non-blank line (which is \t)). > > } or is specified explicitly, relative to the indent of the line where > } block scalar starts > > Now that latter I *would* call "tricky" -- a numeric count relative > to some other indent? What if some of the leading whitespace is tabs? > Also if I read the rest of your explanation correctly, this would make > signficant the leading whitespace before the command whose input is > being redirected, which is a non-starter. If this is implemented then heredocs own indent should be space-only, “some other” indent is copied as-is. But I agree that this would be tricky and it is not much needed. Also code with such explicit indent is less readable: harder to determine what exactly heredoc will result in if there is more then one line with extra (compared to initial+requested by number) indent. Actually I did not see YAML documents with such block scalars. > > } YAML uses `|` and `>` to start block scalars, that's why I used > } `|` above (`<<>` seems odd and may be confused with `<>`). Not > } sure why this should be a bad choice: `|` already has different > } meanings in different contexts > > It seems a bad choice to me because of >| and >>| which have a very > different meaning. If we were going to use either <| or <<| for some > special purpose, it feels as if there should be symmetry implied, as > with e.g. <& and >&. > > Of course << and >> have already given up that sort of symmetry except > for one being input and one being output, so ... > > This reminds me that both <<; and <<& also are currently bad syntax; > though "<<;" is probably an even worse choice than "<<|". There is > at least precedent for combining one of "|" or "&" with redirection.