rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
From: culliton@srg.af.mil (Tom Culliton x2278)
To: cks@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu
Subject: Re: Command execution
Date: Wed, 24 Jun 1992 17:19:34 -0400	[thread overview]
Message-ID: <9206241719.aa07461@ceres.srg.af.mil> (raw)

>>  Duff's rc lets you define a function that looks like a full path, and
>> running the full path will run the function (ie, fn /bin/csh ...). I
>> don't think this is a good idea myself; the uses seem limited to trapping
>> standard programs when invoked by explicit paths, and I see more problems
>> as a result than solutions.

This was exactly what I wanted to do.  One of my friends likes to run a
couple of obnoxious programs on my workstation when he drops by to
visit and I'm not in the office.  Since they're coming from the file
server's shared bin directory a function seemed like a good way to
interdict them.  I can also see other uses to transparently stick a
front end on something, say to translate command line options from one
form to another.  In any case, it was a fairly minor quibble.

>>				Contrary to the documentation, Duff's rc
>> and Byron's behave the *same* for 'foo/bar', and at least Rob Pike a)
>> thinks this is a good thing and b) uses this feature.

This iregularity troubles me more, but thats just because odd little
gotchas set my teeth on edge, and in almost any other unix context
"x/y" is identical to "./x/y".  Could you say more about why Pike
thinks this is good and what you would use it for?

Tom


             reply	other threads:[~1992-06-24 22:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1992-06-24 21:19 Tom Culliton x2278 [this message]
1992-06-24 23:04 ` David Moore
1992-06-25 21:22 ` Chris Siebenmann
  -- strict thread matches above, loose matches on Subject: below --
1992-06-25 21:56 Tom Culliton x2278
1992-06-24 19:10 Tom Culliton x2278
1992-06-24 20:19 ` Chris Siebenmann

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=9206241719.aa07461@ceres.srg.af.mil \
    --to=culliton@srg.af.mil \
    --cc=cks@hawkwind.utcs.toronto.edu \
    --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).