9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
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?



  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).