From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from dmul.paulhaahr.com ([63.203.198.9]) by hawkwind.utcs.toronto.edu with SMTP id <75151>; Sat, 30 Mar 2002 17:04:24 -0500
Received: (qmail 2005 invoked by uid 500); 30 Mar 2002 18:43:31 -0000
Message-Id: <8ZFwtjf51i@dmul.paulhaahr.com>
Date:	Sat, 30 Mar 2002 13:43:31 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From:	Paul Haahr <paul@paulhaahr.com>
To:	rc@hawkwind.utcs.toronto.edu
Subject: Re: rc 1.6 $version
In-Reply-To: <20020327221226.A25153@strozzi.it>
References: <20020314223715.003CB3F40B@quanstro.net>
	<20020327132716.23114.qmail@happy.star.le.ac.uk>
	<20020327221226.A25153@strozzi.it>
X-Mailer: VM 6.30 under Emacs 20.7.1

Tim wrote
> Any objections to `rc_version'?

I'd prefer $rc-version, but either should be fine.

However, making it such a magic variable feels silly.  As Eric noted,
having assignments to a variable just be eaten without warning seems,
er, surprising at best.

Why not just initialize version (provided there's none set in the
environment?), not export it, and have any assignments turn it into a
normal variable.  I think that's pretty easy to do.

Carlo wrote:
> rc already has a few reserved variable names, like $pid, $bqstatus,
> $status [...]  and my suggestion is to set the `rc_' prefix aside for
> rc reserved variables. We would then have rc_path, rc_home,
> rc_whatever. Of course, for backward compatibility we will continue to
> have also $pid, $path and that, but from now on there whould at least
> be a standard for any new rc needs, and that could be documented in
> the man page.

No!  No!  No!

I understand why one might want to prefix ``version'' -- this is rc's
version, not a system-wide version -- but your path, home directory,
etc, are exported and global properties.  (The path/PATH distinction,
etc, is just backwards compatibility, after all.)

One of the points of rc is that it uses so few special variables that we
don't need special namespaces.

--p