From: Geoff Collyer <geoff@collyer.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] rc here docs
Date: Sun, 31 Aug 2003 19:23:31 -0700 [thread overview]
Message-ID: <69f5b2e51adfc734027e4cf14ffa8286@collyer.net> (raw)
In-Reply-To: <f715870610921193e5a128cc87b5ce58@plan9.bell-labs.com>
Getting here documents right inside functions and loops and loops
inside functions and in the background is tricky. Even Bourne didn't
get it right (see BUGS in V7's sh(1)). I think the SVR2 shell (thus
the V8 shell) got it mostly right, but I didn't push it hard. There
are two main issues to sort out: when to start reading a given here
document (and collecting it into a temp file or perhaps into memory
nowadays) and when to remove the temp file. This needs to work in the
presence of notes too. So consider scripts like this one:
fn sigint sigexit {
{
for (i in 1 2 3) {
cat <<!
going $i times...
!
sleep 1
}
} &
sleep 4
}
{
for (f) {
cat <<! $f <<! | lp
header
!
trailer
!
}
} &
sleep 3
exec date
Note the extra complications: variable substitution in a here document
in a loop, and multiple here documents for a single command. (Do all
the here-document temp files get removed if you type an interrupt?)
Getting all of this to work together is tricky, so I can't fault
Bourne or td. As I recall, the SVR2 sh added a separate stack for
here documents, but even then I'm not sure it got all the cases right
(for example, does an "exec" command remove any outstanding
here-document temp files?). If /tmp were always a ramfs, we could
probably ignore the hard cases of removing here-document temp files.
This still leaves cases like variable substitution in a here document
in a loop, for which you need to generate a different temporary file
on each iteration. According to rc(1), we don't have to deal with one
of the messy cases that sh had to:
cat <<!
stuff
`cat <<!!
inner stuff for $USER
!!
`
more stuff
!
It's evident from the code (V7 sh) that here documents were a late
addition to the shell, hacked in rather hurriedly, perhaps to
eliminate the need for the PWB/UNIX pump command, which had been used
with the PWB shell to give a similar effect.
So: do we need here documents at all? Is
cat <<! | somecommand
stuff
$user
more stuff
!
any more useful or noticeably more convenient than
echo 'stuff
'$user'
more stuff' | somecommand
on Plan 9, where we have more-or-less unrestricted command-line
arguments (unlike V7 Unix, which had a limit of 5120 bytes, including
environment if I can trust my memory).
How are others using here documents?
next prev parent reply other threads:[~2003-09-01 2:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-01 0:58 boyd
2003-09-01 1:05 ` David Presotto
2003-09-01 1:43 ` Scott Schwartz
2003-09-01 3:03 ` boyd, rounin
2003-09-01 3:10 ` Scott Schwartz
2003-09-01 3:14 ` boyd, rounin
2003-09-01 6:48 ` Charles Forsyth
2003-09-01 2:23 ` Geoff Collyer [this message]
2003-09-01 2:56 ` boyd, rounin
2003-09-01 3:19 ` Geoff Collyer
2003-09-01 3:33 ` boyd, rounin
2003-09-01 8:36 ` Douglas A. Gwyn
2003-09-01 3:35 ` boyd, rounin
2003-09-01 5:30 ` andrey mirtchovski
2003-09-01 5:36 ` boyd, rounin
2003-09-09 17:12 ` rog
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=69f5b2e51adfc734027e4cf14ffa8286@collyer.net \
--to=geoff@collyer.net \
--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).