From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by hawkwind.utcs.toronto.edu with SMTP id <2679>; Mon, 20 Sep 1993 05:43:18 -0400
Received: from dahlie.TechFak.Uni-Bielefeld.DE
	by techfac.TechFak.Uni-Bielefeld.DE id AA06266; Mon, 20 Sep 1993 11:42:20 +0200
Received: by dahlie.techfak.uni-bielefeld.de (5.0/tp.29.0890)
	id AA16182; Mon, 20 Sep 93 11:42:19 +0200
Date:	Mon, 20 Sep 1993 05:42:19 -0400
From:	malte@TechFak.Uni-Bielefeld.DE
Message-Id: <9309200942.AA16182@dahlie.techfak.uni-bielefeld.de>
To:	rc@hawkwind.utcs.toronto.edu
Subject: builtins, changes et al

Why not discuss changes and/or additions to rc until blue-in-the-face?
I for myself am very grateful for the reponses I received in return to
my last proposal 'cause if I had already implemented it, I'd have to
rework the code now. I don't think this forum should evolve into some
kind of beta test group.

And about reusability, libsh.a (librc.a in this case): As someone else
already stated, there is no easy way to ensure that your shell scripts
uses the same version of some not builtin feature, making it difficult
to pass them on to others. The multics approach stems from a time where
networking was a thing of the future. Who can assure that
gnuerks@macrohard.com.orion won't receive the necessary library module
lightyears after my script?

Now back to the real world, I don't like the idea of a builtin read
with sh semantics too much. I'd prefer a more general solution,
some kind of printf - scanf pair which is _not_ builtin. It's already
part of the GNU shellutils.

Malte