rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
From: Alan Watson <alan@oldp.astro.wisc.edu>
To: byron@netapp.com (Byron Rakitzis), rc@hawkwind.utcs.toronto.edu
Subject: Re: ifs
Date: Wed, 6 Oct 1993 04:48:22 -0400	[thread overview]
Message-ID: <9310060848.AA29158@oldp.astro.wisc.edu> (raw)

Yes, this all hangs on whether one sees ifs as a per shell or per
environment property.  It depends on whether you expect:

	rc -c $cmd

to be (roughly) identical to:

	@ eval $cmd

or not.  (Yes, I know about the magic $pid variable, but its odd
behaviour is dictated by reasons firmly rooted in pragmatism.)  I tend
to think that the current behaviour is wrong, and would like you to
reconsider this.  If you still feel it's right, please add something to
the man page.

I'm not entirely convinced by the trojan horse argument -- is certainly
doesn't exist to the same degree than it did in sh.  By your argument,
why not disable the export of functions to save people from using
builtin to prevent trojan horse commands?  

I'm more in favour of flexibility.  I tend towards prefering to allow
the programmer to explicitly over-ride functions and ifs (by using
builtin and setting ifs) or to inherit the user's preference from the
environment.  We are all used to setting path and using builtin, why is
setting ifs so different?

Besides, I wouldn't trust Paul's view -- he's on record as being
prejudiced against innocent state variables. :-)


             reply	other threads:[~1993-10-06  8:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1993-10-06  8:48 Alan Watson [this message]
  -- strict thread matches above, loose matches on Subject: below --
1993-10-06 18:56 ifs Paul Haahr
1993-10-06  7:21 ifs Byron Rakitzis
1993-10-06  6:55 ifs Alan Watson

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=9310060848.AA29158@oldp.astro.wisc.edu \
    --to=alan@oldp.astro.wisc.edu \
    --cc=byron@netapp.com \
    --cc=rc@hawkwind.utcs.toronto.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).