Re: [9fans] Making read(1) an rc(1) builtin?

[Balwinder S Dheeman <bsd.SANSPAM@anu.homelinux.net>]

On 04/05/2011 03:19 AM, Anthony Sorace wrote:
> On Apr 4, 2011, at 17:35, smiley@zenzebra.mv.com wrote:
>
>> All combined (forking read/test/echo, forking awk/sed/dd, parsing
>> /mnt/acme/%d/events, etc.)... this, I think, is why languages like Perl
>> came into existence and became so popular.  I could definitely write an
>> Acme event parser in Perl, or even in bash(1).  rc(1) is just a few
>> small features shy of making it practical to do in rc(1).
>
> I think this does a very good job of summing up the issue. I think the point
> you might be missing, though, is that most of the Plan 9 community is quite
> happy about the current state of things. You're likely right that considerations
> like this led to perl and bash - but rc's state is not an accident. We know
> where to get perl and bash if we want them.

[bsd@werc ~] man bash |tail -24
BUGS
    *It's too big and too slow*.

    There are some subtle differences between bash and traditional
    versions of sh, mostly because of the POSIX specification.

    Aliases are confusing in some uses.

    Shell builtin commands and functions are not stoppable/restartable.

    Compound commands and command sequences of the form `a ; b ; c' are
    not handled gracefully when process suspension is attempted. When a
    process is stopped, the shell immediately executes the next command
    in the sequence. It suffices to place the sequence of commands
    between parentheses to force it into a subshell, which may be
    stopped as a unit.

    Array variables may not (yet) be exported.

    There may be only one active coprocess at a time.

GNU Bash-4.2               2010 December 28                  BASH(1)

BTW, that highlighting, above, is mine ;)

> Put another way, your problem seems to be "I can't write an acme client in
> rc with performance I'm happy with" (leaving aside, for the moment,
> questions of measurement). Your solution is "expand rc"; I suspect the
> consensus of the community would be either "deal with it" or "use C".
>
> Actually, that might be the consensus of the community on *most* issues. :-)

--
Balwinder S "bdheeman" Dheeman        Registered Linux User: #229709
Anu'z Linux@HOME (Unix Shoppe)        Machines: #168573, 170593, 259192
Chandigarh, UT, 160062, India         Plan9, T2, Arch/Debian/FreeBSD/XP
Home: http://werc.homelinux.net/      Visit: http://counter.li.org/