From: Paul Haahr <email@example.com> To: firstname.lastname@example.org Subject: Re: rc 1.6 $version Date: Sat, 30 Mar 2002 13:43:31 -0500 [thread overview] Message-ID: <8ZFwtjf51i@dmul.paulhaahr.com> (raw) In-Reply-To: <20020327221226.A25153@strozzi.it> 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
next prev parent reply other threads:[~2002-03-30 22:04 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-03-14 22:37 erik quanstrom 2002-03-27 13:27 ` Tim Goodwin 2002-03-27 21:12 ` Carlo Strozzi 2002-03-30 18:43 ` Paul Haahr [this message] 2002-03-31 15:13 ` Carlo Strozzi 2002-04-03 14:31 ` Tim Goodwin 2002-04-03 15:06 ` Paul Haahr 2002-04-04 10:04 ` Tim Goodwin 2002-04-04 21:42 ` Scott Schwartz 2002-04-04 21:54 Byron Rakitzis 2002-04-05 8:35 ` Tim Goodwin 2002-04-05 1:38 Smarasderagd
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=8ZFwtjf51i@dmul.paulhaahr.com \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: rc 1.6 $version' \ /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
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).