From: dave.l@mac.com
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] late to the party - Here docs
Date: Wed, 7 Nov 2007 16:41:09 +0000 [thread overview]
Message-ID: <40711DDA-D0EC-496B-BB91-9132B3ADBD78@mac.com> (raw)
In-Reply-To: <c9bc8cef93affed86c717e702789cff6@quanstro.net>
>> I like here documents,
Metoo, although there may be a bias according to people's typical
application domains:
I often use them (on (l)unices) to spout the obscene gibberish that
some external system requires:
mysql --blah-blah <<!
select $blah blah;
$imbibe_rat_urine
...
!
and it's a hell of a lot saner and simpler if it's all bottled up in
in one place,
rather than spread all over the script.
I may not use them frequently but when I do they are a brain-saver.
>> I think they look better than multi-line echoes
Exactly: they are an aesthetic convenience compared with multiple
echo invocations
but so are quotes compared with multiple backslashes.
>> though it is annoying they can't be used in fn definitions.
That's a bug which could be fixed ...
> i was thinking about this topic again the other day during an
> idle moment. here documents are part of the parsing routine.
> but they don't end up in rc's machine language.
Does this mean they don't work in loops too?
Sadly, I have to nerdishly play sh's advocate:
I just tested a recent ksh and bash and, as expected, heredocs in
functions work,
as do things like:
$ for n in 1 2 3 4 5;do cat<<EOF;done
> $n
> EOF
see below for why.
A quick scan of the rc source code suggests that rc won't DTRT with
an analogous construct:
can someone with a running plan9 or p9p please confirm this
as a matter of academic interest?
It's non-trivial (but not hard) to implement correctly:
the old Bourne shell, and thus, presumably, it's successors, DidTRT:
store the text of the here documents verbatim when they are parsed
then spit the substituted text into a (new) tempfile every time it's
needed.
IIRC it ate temporary files and there were also a few perverse
boundary cases where it would break or
lose track of it's temp files or leave them lying around, but so what?.
Trivial aside: sh also did `...` in here docs, as do it's successors.
> they really are anomolous critters. they need to be taken out
> back and shot. ☺
Anomalous in use or in implementation?
Personally I think they are fine,
but their current implementation may need care and feeding.
If punishment is desired, may I suggest that the implementor be
castigated for anomalousness.
DaveL
next prev parent reply other threads:[~2007-11-07 16:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-06 20:31 maht-9fans
2007-11-06 21:07 ` erik quanstrom
2007-11-07 16:41 ` dave.l [this message]
2007-11-07 20:19 ` erik quanstrom
2007-11-07 21:20 ` geoff
2007-11-07 21:23 ` erik quanstrom
2007-11-07 22:58 ` Martin Neubauer
2007-11-07 23:04 ` erik quanstrom
2007-11-07 23:24 ` Martin Neubauer
2007-11-08 0:37 ` dave.l
2007-11-08 1:21 ` Gregory Pavelcak
2007-11-06 21:54 ` arisawa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40711DDA-D0EC-496B-BB91-9132B3ADBD78@mac.com \
--to=dave.l@mac.com \
--cc=9fans@cse.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).