fatal flaw in popular implementation of the rc shell

I've encountered a little trouble with the most recent version
of the rc shell as originally reimplemented by Rakitzis. It is
devastating and quite easy to straighten out. If this hasn't
been done, yet, and there's any demand for it, I will gladly
supply a patch (comprising 3 lines out of 2 original files).

According to Pike himself, "... key features of the [Unix] v8
shell ... included exportable functions and output from commands
like whatis that could be read as input." And Pike planning rc
meant it to outdo the v8 shell, with both these features intact.

But Release 1.7.1 (2003-07-17) of the rc implementation by Byron
Rakitzis doesn't quite live up to that; just consider the natural
shell 'function' that prints a single star:

fn star { echo '*' }

A subsequent

whatis star

yields but

fn star { echo * }

which would hardly ever print any star, and this is what gets
exported to the subshells. From then on, and only then, just
about anything might happen for more ambitious functions.

The trouble arises from quote minimization: For all I know,
that particular rc even does minimize the quotes, but only
at the expense of the meaning of some expressions so reduced,
which is clearly intolerable.

As far as I can see, the flaw affects only file name patterns.
I've fixed it by simply propagating the property of being marked
quoted from the parser to the prettyprinter, altogether dropping
quote minimization, which I don't much care for, anyway.

Dirk

Re: fatal flaw in popular implementation of the rc shell

2007-09-13, 06:22(-07), dirk.froembgen@freenet.de:
[...]
> The trouble arises from quote minimization: For all I know,
> that particular rc even does minimize the quotes, but only
> at the expense of the meaning of some expressions so reduced,
> which is clearly intolerable.
>
> As far as I can see, the flaw affects only file name patterns.
> I've fixed it by simply propagating the property of being marked
> quoted from the parser to the prettyprinter, altogether dropping
> quote minimization, which I don't much care for, anyway.
[...]

Well spotted. However, if you'd like something to be done about
it, I'd suggest you contact the maintainer of that shell.

--
Stéphane

Re: fatal flaw in popular implementation of the rc shell

On 13 Sep., 19:42, Stephane CHAZELAS wrote:
> ... if you'd like something to be done about it,
> I'd suggest you contact the maintainer of that shell.

I could hear you say that before my posting, but the maintainer
seemed to have disappeared with his website, and I don't have
enough interest to track him down, as I have already fixed the
bug to my complete satisfaction; but I couldn't just let it ride.

I didn't write that just to gloat -- this is a serious matter;
just export this, then run it on your favorite folder of executable
files for a concise specification of a mild form of Russian roulette:

fn surprise { '*' }

Dirk

Re: fatal flaw in popular implementation of the rc shell

On Sep 13, 6:22 am, dirk.froemb...@freenet.de wrote:
> I've encountered a little trouble with the most recent version
> of the rc shell as originally reimplemented by Rakitzis. It is
> devastating and quite easy to straighten out. If this hasn't
> been done, yet, and there's any demand for it, I will gladly
> supply a patch (comprising 3 lines out of 2 original files).
>
> According to Pike himself, "... key features of the [Unix] v8
> shell ... included exportable functions and output from commands
> like whatis that could be read as input." And Pike planning rc
> meant it to outdo the v8 shell, with both these features intact.
>
> But Release 1.7.1 (2003-07-17) of the rc implementation by Byron
> Rakitzis doesn't quite live up to that; just consider the natural
> shell 'function' that prints a single star:
>
> fn star { echo '*' }
>
> A subsequent
>
> whatis star
>
> yields but
>
> fn star { echo * }
>
> which would hardly ever print any star, and this is what gets
> exported to the subshells. From then on, and only then, just
> about anything might happen for more ambitious functions.
> The trouble arises from quote minimization: For all I know,
> that particular rc even does minimize the quotes, but only
> at the expense of the meaning of some expressions so reduced,
> which is clearly intolerable.
> As far as I can see, the flaw affects only file name patterns.
> I've fixed it by simply propagating the property of being marked
> quoted from the parser to the prettyprinter, altogether dropping
> quote minimization, which I don't much care for, anyway.

Yes, indeed, this would be a major "gotcha" to the coder -- and thank
you for the propagation of this information; however, I tend to agree
with SC that contacting the author or maintainer of rc(1) is the
preferable
route, although it is no less appropriate to have posted it here.

Any one to volunteer? (I should be saying "I will" at this moment, you
say?) I'm not being sarcastic when I say that asking the volunteer
debug programmer to submit his results is like asking the volunteer
cook to clean the dishes after the meal.

BTW, my information is that it is not Byron Rakitzis

(and "Paul Haahr" ) that wrote rc, but Tom Duff
and
Tim Goodwin . BR wrote es(1), a superset
of rc(1).

Is this going to affect akanga(1), another superset of rc(1)/es(1)?

Incidentally: Scott Schwartz's set of printing routines for rc(1):
usenet:comp.sources.unix v29i017

=Brian

Re: fatal flaw in popular implementation of the rc shell

2007-09-13, 13:34(-07), dirk.froembgen@freenet.de:
> On 13 Sep., 19:42, Stephane CHAZELAS wrote:
>> ... if you'd like something to be done about it,
>> I'd suggest you contact the maintainer of that shell.
>
> I could hear you say that before my posting, but the maintainer
> seemed to have disappeared with his website, and I don't have
> enough interest to track him down, as I have already fixed the
> bug to my complete satisfaction; but I couldn't just let it ride.
>
> I didn't write that just to gloat -- this is a serious matter;
> just export this, then run it on your favorite folder of executable
> files for a concise specification of a mild form of Russian roulette:
>
> fn surprise { '*' }
[...]

I totally agree with you it's a somewhat serious bug. If the fix
is not tool big, you could include the diff in a post in this
thread so that at least someone googling about the problem may
find the solution here.

I'd be curious to know how many people actually use rc. It's
true that it's a far better shell than the Bourne like shells
(at least in its language, for scripting) but the very fact that
it's not Bourne-like makes it completely forgotten in the Unix
world.

Is plan9 still alive?

BTW, as Brian mentionned es, I could verify that at least the es
you find on debian (es 0.9-beta1) doesn't have the bug.

--
Stéphane

Re: fatal flaw in popular implementation of the rc shell

Brian and St=E9phane both,

I will gladly disclose the results of my very feeble effort
to correct that blunder in rc on behalf of my client, who
is indifferent to rc as such.

So I informally propose the concluding preliminary patch.
Please verify or refute it, and post any corrections here.

> BTW, my information is that it is not Byron Rakitzis ...
> that wrote rc, but Tom Duff and Tim Goodwin ...
> BR wrote es(1), a superset of rc(1). Is this going to
> affect akanga(1), another superset of rc(1)/es(1)?

Rakitzis did write one all right, and so did Duff at AT&T,
commissioned by Pike, and this is all told about in the manual.
Goodwin is the current maintainer of Rakitzis's one. Es is
irrelevant, because it represents a paradigm foreign to Unix.
Akanga sounds foreign, too. Incidentally, only recently was
reported a standalone backport of Duff's rc to some Unix.

> I'd be curious to know how many people actually use rc.

At least as many as can tell a modern language from an ancient one
and do properly operate some Unix in the first place -- so, 42 ?

> It's true that it's a far better shell than the Bourne like shells

Sure. On the facts it's vastly superior -- so what?

1979 saw a conference on command languages that thoroughly
established what exactly a command language ought to be.
The design of rc follows the recommendations of that conference
quite closely. In this way, rc was state-of-the-art, and
probably still is in many ways, particularly since that art
doesn't interest anyone -- no clients, at any rate. The
proceedings only appeared in 1980.

> (at least in its language, for scripting)

You can easily build for it an extremely responsive graphical user
interface out of things as simple as xterm, GNU Screen, rio, and the
Nvi editor (or even within things as complex as Emacs or desktops).
It will even fit on an envelope, I know from experience:)

> but the very fact that it's not Bourne-like makes it completely
> forgotten in the Unix world.

Maybe that kind of attitude is why there isn't much of a Unix world
any more. It's called orthodoxy, or deliberate obsolescence:)

> Is plan9 still alive?

No idea. Pike was with Google after leaving AT&T, and had to
relearn Unix there, as they had no use for Plan9. Innovation
was dead, and tools didn't make sense any more, or so I heard.

> BTW, as Brian mentionned es, I could verify that at least the
> es you find on debian (es 0.9-beta1) doesn't have the bug.

That had to be expected, as es is a totally different beast.
I suspect the bug is just an oversight by Goodwin, no doubt
in the pursuit of some laudable ambition. In due course, he
will surely see to this much better than I finally do now:

Assume version '1.7.1 $Release: @(#)rc 1.7.1 2003-07-17 $', and
copy original files to their original names with .original appended.
Then arrange for this state of affairs, and build as you did before:

{diff tree.c.original tree.c}
#84c84
#< n =3D (*alloc)(offsetof(Node, u[2]));
#---
#> n =3D (*alloc)(offsetof(Node, u[3]));
#85a86
#> n->u[2].i =3D s->u[2].i;
#
{diff footobar.c.original footobar.c}
#76c76
#< fmtprint(f, quotep(n->u[0].s, dollar) ? "%#S" : "%S",
n->u[0].s);
#---
#> fmtprint(f, n->u[2].i || quotep(n->u[0].s, dollar) ?
"%#S" : "%S", n->u[0].s);
#

(Sorry for the excessive punctuation; this was cut from my history
files.)

OK, so this is blunt; at least, it passes the trip test by the
distribution and works for my humble designs. I came across the
bug when multiplying two numbers, so this is not all academic.
I didn't debug the code, and I had never seen the source before.

Dirk

Re: fatal flaw in popular implementation of the rc shell

2007-09-15, 02:53(-07), dirk.froembgen@freenet.de:
[...]
>> BTW, my information is that it is not Byron Rakitzis ...
>> that wrote rc, but Tom Duff and Tim Goodwin ...
>> BR wrote es(1), a superset of rc(1). Is this going to
>> affect akanga(1), another superset of rc(1)/es(1)?
>
> Rakitzis did write one all right, and so did Duff at AT&T,
> commissioned by Pike, and this is all told about in the manual.
> Goodwin is the current maintainer of Rakitzis's one. Es is
> irrelevant, because it represents a paradigm foreign to Unix.
> Akanga sounds foreign, too.
[...]

AFAIK, akanga is just rc with some embedded arithmetic
operators.

[...]
>> (at least in its language, for scripting)
>
> You can easily build for it an extremely responsive graphical user
> interface out of things as simple as xterm, GNU Screen, rio, and the
> Nvi editor (or even within things as complex as Emacs or desktops).
> It will even fit on an envelope, I know from experience:)

But, in term of innovation, shells even based on a poor syntax
like tcsh went a long way in empowering the user for day to day
interactive shell usage. tcl, perl, python, ruby offer a
valuable alternative to the shell and unix toolchest for
scripting. So, it's understandable that shells like zsh, tcsh,
and to some extent bash developped mostly their interactive
usage side recently.

fish (http://fishshell.org/) is interesting in that it is new,
not based on the Bourne shell, with a very simple syntax (yet
consistent, probably a lot more than the ksh/bashs... though
I've never looked at it in great detail) and designed to be a
power tool interactively.

>> but the very fact that it's not Bourne-like makes it completely
>> forgotten in the Unix world.
>
> Maybe that kind of attitude is why there isn't much of a Unix world
> any more. It's called orthodoxy, or deliberate obsolescence:)

Though it could take little to change habits. See for instance
how bash took off even though it is far from being the best free
software shell for the only reason that it is the default shell
on Linux, and that, for the only reason that it is the shell of
the GNU project.

>> BTW, as Brian mentionned es, I could verify that at least the
>> es you find on debian (es 0.9-beta1) doesn't have the bug.
>
> That had to be expected, as es is a totally different beast.

Well in the same was as the Bourne and Korn shells are different
beasts. es is still mostly a superset of rc.

[...]
> {diff tree.c.original tree.c}
[...]

Thanks for sharing the fix.

--
Stéphane

Re: fatal flaw in popular implementation of the rc shell

On 15 Sep., 12:44, Stephane CHAZELAS wrote:
> AFAIK, akanga is just rc with some embedded arithmetic operators

.... and many more "enhancements" as dispensable. Rc is complete.

> shells even based on a poor syntax like tcsh went a long way in
> empowering the user for day to day interactive shell usage

Whom do they empower? To do what? They enforce particular (and
peculiar) interaction techniques, which ought to be very personal
things,
if not habits.

> perl, python, ruby offer a valuable alternative to the shell and
> unix toolchest for scripting

They also replace Unix altogether; as soon as you need to extend
your language by something uncommon, you've lost out. I still
remember when I needed (efficient) suffix arrays with Perl, or
even proper strings! Tcl, however, can be used very much like rc
and is extensible like Unix. I've deployed it on Windows. I would
not count it among the languages, though.

> it's understandable that shells like zsh, tcsh, and to some
> extent bash developped mostly their interactive usage side
> recently.

It's understandable all right, but why bother?

> fish (http://fishshell.org/) is interesting ...

Decades ago, there was a functional Unix shell called fish, kind
of the archetype of es. This is what I meant by "different beast".
The new fish doesn't smell like the old one, though, but it doesn't
smell all that new, either.

> See for instance how bash took off even though it is far from
> being the best free software shell for the only reason that it
> is the default shell on Linux,

See for instance how Windows took off even though it is far
from being the best software shell for the only reason that
it is the default shell on PC's.

> Thanks for sharing the fix.

You're welcome, but don't rely on it; at least, it can hardly
be worse than the bug itself:)

Dirk