Joerg Schilling wrote:
> "Don Cragun" wrote:
>
>
>>> Don Cragun was RIF'ed and right now I don't know anyone at Sun who can
>>> be queried for standards issues.
>>>
>> Even though I am no longer at Sun, I'm still interested in OpenSolaris. I'm
>> remaining involved in Austin Group activ
"Don Cragun" wrote:
> > Don Cragun was RIF'ed and right now I don't know anyone at Sun who can
> > be queried for standards issues.
>
> Even though I am no longer at Sun, I'm still interested in OpenSolaris. I'm
> remaining involved in Austin Group activities on my own dime.
Sun was and still m
Joerg Schilling wrote:
> "Don Cragun" wrote:
>
>>> Don Cragun was RIF'ed and right now I don't know anyone at Sun who can
>>> be queried for standards issues.
>> Even though I am no longer at Sun, I'm still interested in OpenSolaris. I'm
>> remaining involved in Austin Group activities on my own
James Carlson wrote:
> Don Cragun writes:
> > During the last revision cycle, the committee received requests to
> > explicitly
> > add these functions because they are widely used in Linux application
> > programming and were a portability problem for people porting code from
> > Linux systems
Don Cragun writes:
> During the last revision cycle, the committee received requests to explicitly
> add these functions because they are widely used in Linux application
> programming and were a portability problem for people porting code from
> Linux systems to POSIX/UNIX platforms. I don't reme
"Mark J. Nelson" wrote:
> > ...I've asked around
> > whether it is possible to deliver the contents of one ARC case with
> > multiple putbacks but the answers were a bit "fuzzy"
>
> Speaking not as an ARC member, but rather as a CRT Advocate and former
> Tech Lead:
>
> Standard expectation is tha
> Date: Tue, 10 Feb 2009 17:14:07 +0100
> From: Roland Mainz
>
> James Carlson wrote:
>> Casper Dik writes:
>> >char *stpcpy(char *restrict s1, const char *restrict s2);
>> >char *stpncpy(char *restrict s1, const char *restrict s2, size_t n);
>> >wchar_t *wcpcpy(wchar_t restrict *ws1
"Mark J. Nelson" wrote:
> > ...I've asked around
> > whether it is possible to deliver the contents of one ARC case with
> > multiple putbacks but the answers were a bit "fuzzy"
>
> Speaking not as an ARC member, but rather as a CRT Advocate and former
> Tech Lead:
>
> Standard expectation is tha
"I. Szczesniak" wrote:
> On 2/4/09, Roland Mainz wrote:
> > 2. The next ARC case may contain a few more non-filesystem utilties
> > (e.g. "join", "head", "tail", "tee", "mkfifo") from libcmd and (as a
> > seperare ARC case) cover the remaining closed-source commands defined by
> > POSIX (e.g.
> ...I've asked around
> whether it is possible to deliver the contents of one ARC case with
> multiple putbacks but the answers were a bit "fuzzy"
Speaking not as an ARC member, but rather as a CRT Advocate and former
Tech Lead:
Standard expectation is that a single ARC case will be integrated
Casper.Dik at Sun.COM wrote:
> > > >>> It's fine to make use of the ksh builtin support for various
> > > >>> commands, but
> > > >>> can we please learn from the problems that occurred when we
> > > >>> changed sleep
> > > >>> to be a builtin recently (e.g. 6793120) and instead create trivial
> >
>
> > >>> It's fine to make use of the ksh builtin support for various
> > >>> commands, but
> > >>> can we please learn from the problems that occurred when we
> > >>> changed sleep
> > >>> to be a builtin recently (e.g. 6793120) and instead create trivial
> > >>> wrapper
> > >>> *programs*
Roland Mainz writes:
> 2. Restricted shell scripts (e.g. "rsh", "rksh", "pfrksh" [2] etc.) need
> a way to output data (e.g. counterpart to "read") and therefore "print"
> was never bound to a PATH element since the korn shell exists. Otherwise
> you have shell scripts which can't output anything e
Peter Memishian wrote:
> > > It's fine to make use of the ksh builtin support for various commands,
> but
> > > can we please learn from the problems that occurred when we changed sleep
> > > to be a builtin recently (e.g. 6793120) and instead create trivial
> wrapper
> > > *programs* that ac
Peter Memishian wrote:
> > >>> It's fine to make use of the ksh builtin support for various
> > >>> commands, but
> > >>> can we please learn from the problems that occurred when we
> > >>> changed sleep
> > >>> to be a builtin recently (e.g. 6793120) and instead create trivial
> > >>> wrappe
Dale Ghent wrote:
> On Feb 4, 2009, at 12:32 AM, Peter Memishian wrote:
> >>> It's fine to make use of the ksh builtin support for various
> >>> commands, but
> >>> can we please learn from the problems that occurred when we
> >>> changed sleep
> >>> to be a builtin recently (e.g. 6793120) and inst
Peter Memishian wrote:
>
> It's fine to make use of the ksh builtin support for various commands, but
> can we please learn from the problems that occurred when we changed sleep
> to be a builtin recently (e.g. 6793120) and instead create trivial wrapper
> *programs* that access the builtin functi
James Carlson wrote:
> Alan Hargreaves writes:
> > Unlike other built-in commands named in PSARC/2006/550, the "print"
> > built-in in ksh93 will _not_ be bound to the /usr/bin/ pathname to
> > ensure backwards-compatiblity to existing ksh93 scripts (for example
> > scripts running in "restricted"
> > So there is a unique pid for each program and thus it can still be pkill'd?
>
> If you start the command as seperate child job (e.g. $ sleep 12345 & #)
> it will always have a seperate pid. But that was not the problem which
> caused CR #6793120 - the process name changed from "sleep 123
> >>> It's fine to make use of the ksh builtin support for various
> >>> commands, but
> >>> can we please learn from the problems that occurred when we
> >>> changed sleep
> >>> to be a builtin recently (e.g. 6793120) and instead create trivial
> >>> wrapper
> >>> *programs* that acc
On Feb 4, 2009, at 12:32 AM, Peter Memishian wrote:
>
>>> It's fine to make use of the ksh builtin support for various
>>> commands, but
>>> can we please learn from the problems that occurred when we
>>> changed sleep
>>> to be a builtin recently (e.g. 6793120) and instead create trivial
>>
> > It's fine to make use of the ksh builtin support for various commands, but
> > can we please learn from the problems that occurred when we changed sleep
> > to be a builtin recently (e.g. 6793120) and instead create trivial wrapper
> > *programs* that access the builtin functionality throu
22 matches
Mail list logo
