Re: RC => POSIX

[Malte Uhl <Uhl@rrz.Uni-Koeln.DE>]

> 	> The problem is harder than that in rc's case.  Signal semantics make a
> 	> good example.  To be really posixy you'd use sigaction(), and while
> 	> you can write signal() in terms of sigaction, the reverse is not very
> 	> doable.  The differences between BSD and SysV signal semantics are one
> 	> of the reasons that RC has a bunch of #if's.
> 
> 	And that's exactly his point! Why use BSD or SysV semantics when you can do 
> 	it posixly correct?
> 
> 	> Others include optional
> 	> features such as readline, nonstandard OS features that make something
> 	> work in a better, safer way when they're present such as /dev/fd and
> 	> kernel recognition of "#!" in executable scrpts.  All your proposal
> 	> would do is move the #if's into the compatibility library.
> 
> 	Again, that's the very point: To seperate the shells code from the OS stuff 
> 	as much as possible.
> 
> 	I'd even go further suggesting to drop all the "ANSI compatibility" headers 
> 	Byron once wrote. They are a major source of problems porting rc to different 
> 	platforms and to maintain it. Frequently, the declarations made in them are 
> 	slightly incompatible with the systems declarations, although hard clashes 
> 	are rare.
> 
> 	Summarising the intense discussions a few years back, we've concluded not to 
> 	add new features so, rewriting to Posix and Xopen specs gets my vote!
> 
> 	If rc was to be changed, I'd suggest setting the status variable to the 
> 	result of a backquote command in an assignment, as in
> 
> 		; x=`false || echo error
> 		error
> 		;
> 
> 	Malte
> 
>