I'm sponsoring this case for Venky Tv.
Required release binding:
Patch binding for the announcement and marking as Obsolete.
Minor binding for the removal.
Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI
This information is Copyright (c) 2010, Oracle and/or its affiliates. All
righ
Below is an amended proposal. Timer is not reset as it essentially
clarifies the discussion so far.
Required release binding:
Patch binding for the announcement and marking as Obsolete.
Minor binding for the removal.
1. Introduction
1.1. Project/Component Working Name:
EOF le
+1
I always thought it was a back to front interface anyway.
On 08/06/2010 09:52, Peter Dennis wrote:
I'm sponsoring this case for Venky Tv.
Required release binding:
Patch binding for the announcement and marking as Obsolete.
Minor binding for the removal.
Template Version: @(#)sac
Why are these "not relevant"? In my experience they are mostly
used in scripts and Makefiles, to ensure that the right code path
is taken. Won't removing them break older configure-style scripts,
i.e. ones that test things like "if [ ! vax ]" etc.?
Is the gain of removal worth more than poten
James C. McPherson wrote:
/usr/bin/iAPX286
/usr/bin/i286
/usr/bin/i860
/usr/bin/pdp11
/usr/bin/u3b
/usr/bin/u3b2
/usr/bin/u3b5
/usr/bin/u3b15
/usr/bin/vax
/usr/bin/u370
Can you tell me, with a straight face - and proof- that
Solaris 2.6 or later will even run on *any* of the above
processor
Steve McKinty wrote:
> If I wrote a portable configure script which contained something
> like:
>
> if [ vax ]; then
> do vaxy setup
Obviously, that should be "if vax; then" rather than with the test
brackets, but otherwise I think Steve McKinty has a very good point.
How many bytes are save
On 08/06/2010 13:14, Steve McKinty wrote:
If I wrote a portable configure script which contained something
like:
if [ vax ]; then
do vaxy setup
else if [ u3b ]; then
do AT&T setup
else if [ sun ]; then
do Solaris setup
endif
it would work unchanged on all those architectures. Take out the
vax a
>The same script will fail on Ububtu as well - I just checked they don't
>exist there.
if vax; then
will fail whether vax exists with one or with vax not present.
Whether "-e" is set is not important. Other than the additional errors
the script will continue to run.
Casper
__
On Tue, Jun 08, 2010 at 01:44:47PM +0100, Darren J Moffat wrote:
> On 08/06/2010 13:14, Steve McKinty wrote:
>> If I wrote a portable configure script which contained something
>> like:
>>
>> if [ vax ]; then
>> do vaxy setup
>> else if [ u3b ]; then
>> do AT&T setup
>> else if [ sun ]; then
>> do
On 8/06/10 07:59 PM, Steve McKinty wrote:
Why are these "not relevant"? In my experience they are mostly
used in scripts and Makefiles, to ensure that the right code path
is taken. Won't removing them break older configure-style scripts,
i.e. ones that test things like "if [ ! vax ]" etc.?
Is th
On 8/06/10 10:33 PM, James Carlson wrote:
Steve McKinty wrote:
If I wrote a portable configure script which contained something
like:
if [ vax ]; then
do vaxy setup
Obviously, that should be "if vax; then" rather than with the test
brackets, but otherwise I think Steve McKinty has a ver
On Tue, 2010-06-08 at 11:59 +0200, Steve McKinty wrote:
> Why are these "not relevant"? In my experience they are mostly
> used in scripts and Makefiles, to ensure that the right code path
> is taken. Won't removing them break older configure-style scripts,
> i.e. ones that test things like "if [ !
Several people have pointed out that the harm from removing these
commands isn't that great because
(a) recent scripts tend not to use this mechanism to figure out the type
of platform, and
(b) older scripts will still work (with error messages) because a
missing command evaluates to false.
On Tue, 2010-06-08 at 13:03 -0700, Scott Rotondo wrote:
> Several people have pointed out that the harm from removing these
> commands isn't that great because
>
> (a) recent scripts tend not to use this mechanism to figure out the type
> of platform, and
>
> (b) older scripts will still work (
> On Tue, 2010-06-08 at 13:03 -0700, Scott Rotondo
> wrote:
> > Several people have pointed out that the harm from
> removing these
> > commands isn't that great because
> >
> > (a) recent scripts tend not to use this mechanism
> to figure out the type
> > of platform, and
> >
> > (b) older scr
Note that there is one known issue caused by having the /usr/bin/i386 &
/usr/bin/i486 binaries - every isaexec command on x86 trips over it when
looking for the subdir to find isa-specific binaries in before finding
them in /usr/bin/i86 (the more generic ISA required to avoid the name clash).
[Tho
On 6/8/10 1:15 PM, Garrett D'Amore wrote:
d) every bit costs something. to compile, to link, to deliver. Just in
the listing of /usr/bin. Anything which serves no useful function
should IMO be removed. (Individually, these costs are minuscule, but
taken collectively over the entire life of a
> Nevertheless, if there are _any_ scripts that use it, unless you get
> rid of all 29 (or however many) links to it, I don't see any incremental gain
> by removing some of them.
Am taking the conservative approach here by removing only those
commands which could not possibly return true. It woul
> > Nevertheless, if there are _any_ scripts that use
> it, unless you get
> > rid of all 29 (or however many) links to it, I
> don't see any incremental gain
> > by removing some of them.
>
> Am taking the conservative approach here by removing
> only those
> commands which could not possibly ret
On Wed, Jun 09, 2010 at 02:15:56AM -0700, Richard L. Hamilton wrote:
> Of those you just mentioned, it might be worth keeping sun4m for awhile,
> since AFAIK Solaris 9 (last that could run on sun4m) is still supported, and
> thus a script might exist such that it would still be true on Solaris 9
>
On Tue, Jun 08, 2010 at 01:15:18PM -0700, Garrett D'Amore wrote:
> d) every bit costs something. to compile, to link, to deliver. [...]
There's also a run-time cost. Anyone who's browsed for executables to
open media content with from Firefox will have observed that browsing
/bin borders on the
KzEKClBldGVyIERlbm5pcyA8cGV0ZXIuZGVubmlzQG9yYWNsZS5jb20+IHdyb3RlOgoKPkJlbG93
IGlzIGFuIGFtZW5kZWQgcHJvcG9zYWwuIFRpbWVyIGlzIG5vdCByZXNldCBhcyBpdCBlc3NlbnRp
YWxseQo+Y2xhcmlmaWVzIHRoZSBkaXNjdXNzaW9uIHNvIGZhci4KPgo+UmVxdWlyZWQgcmVsZWFz
ZSBiaW5kaW5nOgo+ICAgICBQYXRjaCBiaW5kaW5nIGZvciB0aGUgYW5ub3VuY2VtZW50
How long did you type on the text below? :)
Something is wrong, either list or mail app.
Olga
2010/6/10 Garrett D'Amore :
> KzEKClBldGVyIERlbm5pcyA8cGV0ZXIuZGVubmlzQG9yYWNsZS5jb20+IHdyb3RlOgoKPkJlbG93
> IGlzIGFuIGFtZW5kZWQgcHJvcG9zYWwuIFRpbWVyIGlzIG5vdCByZXNldCBhcyBpdCBlc3NlbnRp
> YWxseQo+Y2xhcm
If you base64 decode it, it just says:
+1
;-)
ольга крыжановская wrote:
How long did you type on the text below? :)
Something is wrong, either list or mail app.
Olga
2010/6/10 Garrett D'Amore :
KzEKClBldGVyIERlbm5pcyA8cGV0ZXIuZGVubmlzQG9yYWNsZS5jb20+IHdyb3RlOgoKPkJlbG93
IGlzIGFuIGFtZW5k
On 10.06.10 20:48, Andrew Gabriel wrote:
If you base64 decode it, it just says:
+1
Garrett does sometimes have a roundabout way of saying things ;-))
cheers
--
michael.schus...@oracle.com http://blogs.sun.com/recursion
Recursion, n.: see 'Recursion'
___
The problem is toxicity in the PSARC mailing list software with the
Android client. I think what is happening is that the PSARC processing
is stripping of the bits that are responsible for indicating the mime
encoding for this.
I'm sorry about this, I just need to stop responding to PSARC mai
This case has timed out with a +1 and, in addition, was approved
during the PSARC meeting of 16-Jun-2010.
pete
___
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
27 matches
Mail list logo
