rc 1.6 $version

rc 1.6 $version

[erik quanstrom]

is there any way that $version could be changed either
to not be so magic (i.e. assigned at startup time) or
better something like _rc_version_. i have been discovering
scripts that no longer work with rc 1.6 ever since i installed
it because they were assigning to $version and expecting the
same value back. silly me.

erik

Re: rc 1.6 $version

[Tim Goodwin]

> is there any way that $version could be changed either
> to not be so magic (i.e. assigned at startup time) or
> better something like _rc_version_.

The `version' variable was introduced in rc-1.6b1 (replacing the `-V'
flag, which itself was new in rc-1.5b4).  Thus, it's never been in a
full release.  Thus, I'm prepared to change it :-).

Any objections to `rc_version'?

Tim.

Re: rc 1.6 $version

[Carlo Strozzi]

On Wed, Mar 27, 2002 at 08:27:16AM -0500, Tim Goodwin wrote:
> > is there any way that $version could be changed either
> > to not be so magic (i.e. assigned at startup time) or
> > better something like _rc_version_.
> 
> The `version' variable was introduced in rc-1.6b1 (replacing the `-V'
> flag, which itself was new in rc-1.5b4).  Thus, it's never been in a
> full release.  Thus, I'm prepared to change it :-).
> 
> Any objections to `rc_version'?

rc already has a few reserved variable names, like $pid, $bqstatus,
$status, and so on. Others, like $version, could be added in the
future. It would be nice to have a naming-convention for reserved names,
so that one knows in advance what names should be left alone.
The proposed `rc_version' is ok, 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. Since rc supports 'funny'
characters in names, the reserved ones could even be 'rc.something',
so that they are even more peculiar. Just my two-cent.

bye,
carlo
-- 
For easier reading please set the Courier font.
Messages larger than 30 KB may not receive immediate attention.
Freedom for Business: http://swpat.ffii.org

Re: rc 1.6 $version

[Paul Haahr]

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

Re: rc 1.6 $version

[Carlo Strozzi]

On Sat, Mar 30, 2002 at 01:43:31PM -0500, Paul Haahr wrote:
> 
> 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.

This certainly makes sense, I agree. Just forget about my proposed
special `rc_' namespace.

	-cs-
-- 
For easier reading please set the Courier font.
Messages larger than 30 KB may not receive immediate attention.
Freedom for Business: http://swpat.ffii.org

Re: rc 1.6 $version

[Tim Goodwin]

Paul Haahr wrote:
> > Any objections to `rc_version'?
> 
> I'd prefer $rc-version, but either should be fine.

(As it turns out, this is all irrelevant, but I have would two
objections to this.  First, `-' turns on free careting, so you'd have
to say things like this.

    ; whatis $'rc-version'

Not so bad, but wrap it in another level of quotes, perhaps from a
less sane shell, and it starts to get *very* ugly.

    $ rc -c 'whatis $'"'rc-version'"

Secondly, rc is meant to be C-ish, not Lisp-ish.)

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

Mea culpa.  I failed to realise that there are two types of special
variable in rc: 1) those that merely have a default initial value, and
2) those that invoke special code when substituted.  Till now,
$version was in category 2.  I've just moved it to category 1.

Category 2 now contains just $apids and $status, which seems about
right; they are both, of necessity, magical.  Category 1 now contains
$ifs, $path, $pid, $prompt, and $version.  (I was surprised to
discover that assignments to pid are persistent!)

As a separate matter, several variables are not exportable.  These
are: $apid, $apids, $cdpath, $home, $ifs, $path, $pid, and $*.
(Remember that $cdpath, $home, and $path are all aliased to upper case
versions, which *are* exportable.  Also, the default assignment to
$path happens before $PATH is examined: so if $PATH is set, $path will
acquire its value instead of the default.)

I think $bqstatus and $status ought to be non-exportable too.  I've
just made them so; you can all see what this breaks in the next
release candidate :-).

Tim.

Re: rc 1.6 $version

[Paul Haahr]

Tim wrote

> > I'd prefer $rc-version, but either should be fine.
> 
> (As it turns out, this is all irrelevant, but I have would two
> objections to this.  First, `-' turns on free careting, [...]

Yeah, I forgot about that.  (We had fixed that in es.)

> Secondly, rc is meant to be C-ish, not Lisp-ish.)

That, too, we fixed in es.

> Mea culpa.  I failed to realise that there are two types of special
> variable in rc: 1) those that merely have a default initial value, and
> 2) those that invoke special code when substituted.  Till now,
> $version was in category 2.  I've just moved it to category 1.

This seems quite sensible.

> As a separate matter, several variables are not exportable.  These
> are: $apid, $apids, $cdpath, $home, $ifs, $path, $pid, and $*.
> (Remember that $cdpath, $home, and $path are all aliased to upper case
> versions, which *are* exportable.  Also, the default assignment to
> $path happens before $PATH is examined: so if $PATH is set, $path will
> acquire its value instead of the default.)
> 
> I think $bqstatus and $status ought to be non-exportable too.  I've
> just made them so; you can all see what this breaks in the next
> release candidate :-).

Seems good to me.

Three questions:
  - Is $version exportable?
  - Is $version exported if the user doesn't assign to it?
  - Is $version inherited from the environment?

--p

Re: rc 1.6 $version

[Tim Goodwin]

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

OK, after a couple of iterations I've now done exactly that.

I've made $prompt act in the same way; I wonder if $ifs should too?
The other variables to which rc gives default values: $path and $pid;
are never exported.

All this will be in another release candidate soon...

Tim.

Re: rc 1.6 $version

[Scott Schwartz]

| > 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.
| 
| OK, after a couple of iterations I've now done exactly that.

I dunno.  In that case calling it rc_version makes more sense to me.
Less likely to have accidental collisions.

Re: rc 1.6 $version

[Tim Goodwin]

> I would have thought you'd want to export $prompt.

It's exported if it's changed from the default.

The motivation for doing so was this little snippet:

    $ env - rc
    ; printenv
    PATH=/usr/local/bin:/usr/bin:/bin:.
    prompt=; ^A

No point in cluttering the environment with a value that any
descendant rc process would default to anyway.  And since I'd just
invented the mechanism to export $version only if it's assigned to
(all 3 lines of code of it!), I thought I'd use it.

So in the dev version, we get this.

    $ env - rc
    ; printenv
    PATH=/usr/local/bin:/usr/bin:/bin:.
    ; prompt=('rc$ ' '')
    rc$ printenv
    PATH=/usr/local/bin:/usr/bin:/bin:.
    prompt=rc$ ^A

(And even PATH goes away if you build with `--disable-def-path'.)

Tim.

Re: rc 1.6 $version

[Smarasderagd]

>I would have thought you'd want to export $prompt.

I'd rather have prompt exported as well.

Re: rc 1.6 $version

[Byron Rakitzis]

>I've made $prompt act in the same way; I wonder if $ifs should too?

I would have thought you'd want to export $prompt.

What about subshells?