[request-sponsor] Requesting sponsor for CR #6799167("real gcc build fails in libshell") ...
Milan Jurik wrote:
> Roland Mainz pe v po 02. 03. 2009 v 05:38 +0100:
> > This is a sponsor request to "fix" ([1]) CR #6799167
> > (http://bugs.opensolaris.org/view_bug.do?bug_id=6799167 - "real gcc
> > build fails in libshell").
> >
> > [1]=The "fix" is more a workaround since I don't know exactly how the
> > ctf*-tools can be fixed.
> >
> > My contributor ID is "OS0025".
> >
> > Webrev follows later when my "hg clone" is complete...
>
> I will sponsor it (if it's ksh93 issue).
It's an issue in the ctf*-tools but we failed to find a fix for these
tools for more than a month and IMO breaking the gcc build for such a
long time IMO not acceptable. Since I don't know how to fix the ctf
tools the patch in
http://cr.opensolaris.org/~gisburn/ksh93_integration_cr_6799167_001/
works around the problem by using an arithmetric expression in the VLA
declaration which seems to work in this case.
To explain the workaround: The following testcase causes "ctfconvert" to
fail with the error "die 8002: failed to get unsigned (form 0x13)":
-- snip --
#include
#include
#include
int main(int ac, char *av[])
{
int len=strlen(av[0])+1;
char name[len];
strcpy(name, av[0]);
printf("name='%s'\n", name);
return EXIT_SUCCESS;
}
-- snip --
The problem goes away if I replace the first two lines of the |main()|
function like this...
-- snip --
int len=strlen(av[0]);
char name[len+1];
-- snip --
... e.g. VLA declarations seem to work if you use an arithemtric
expression instead of a plain variable... but I can't explain _why_ this
works... ;-(
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6799167 ("real gcc build fails in libshell") ...
Roland Mainz wrote: > This is a sponsor request to "fix" ([1]) CR #6799167 > (http://bugs.opensolaris.org/view_bug.do?bug_id=6799167 - "real gcc > build fails in libshell"). > > [1]=The "fix" is more a workaround since I don't know exactly how the > ctf*-tools can be fixed. > > My contributor ID is "OS0025". > > Webrev follows later when my "hg clone" is complete... Webrev is now available at http://cr.opensolaris.org/~gisburn/ksh93_integration_cr_6799167_001/ - can anyone give me a short code review for the change, please (we'll file a new bug in bugster to make sure the original issues doesn't get forgotten) ? Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6799167 ("real gcc build fails in libshell") ...
"Roger A. Faulkner" wrote: > > Roland Mainz wrote: > > > This is a sponsor request to "fix" ([1]) CR #6799167 > > > (http://bugs.opensolaris.org/view_bug.do?bug_id=6799167 - "real gcc > > > build fails in libshell"). > > > > > > [1]=The "fix" is more a workaround since I don't know exactly how the > > > ctf*-tools can be fixed. > > > > > > My contributor ID is "OS0025". > > > > > > Webrev follows later when my "hg clone" is complete... > > > > Webrev is now available at > > http://cr.opensolaris.org/~gisburn/ksh93_integration_cr_6799167_001/ - > > can anyone give me a short code review for the change, please (we'll > > file a new bug in bugster to make sure the original issues doesn't get > > forgotten) ? > > The code change looks good to me (and compiles for me). > (I've been concerned about the not-buildable-with-gcc > issue for some time now. I thought I was the only one.) It was AFAIK the only one (there are other VLA users in the tree but they all use the arithmetric expressions and therefore avoid this xxx@@@!!!-trap). > Nit: > Could you break the comment into more than one line, > to make it fit in 80-columns, something like: > > /* > * Allocate one extra array entry as workaround for: > * CR 6799167 real gcc build fails in libshell > */ Fixed. I've uploaded the new webrev as http://cr.opensolaris.org/~gisburn/ksh93_integration_cr_6799167_002/ Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6799167 ("real gcc build fails in libshell") ...
John Sonnenschein wrote: > On 2-Mar-09, at 10:05 AM, Roger A. Faulkner wrote: > >> Roland Mainz wrote: [snip] > > Nit: > > Could you break the comment into more than one line, > > to make it fit in 80-columns, something like: > > > >/* > > * Allocate one extra array entry as workaround for: > > * CR 6799167 real gcc build fails in libshell > > */ > > Sorry to butt in here, but I was under the impression that code should > never make reference to the bug it fixes. Am I mistaken here? No, you're right... but AFAIK there is an exception when you add a workaround which is expected to be removed (at least there is sufficient precedent in usr/src/uts/ for this kind of comments). IMO no _permanent_ code should contain such comments but the workarounds need such stuff (to avoid excessively large comment blocks) that there is a clear sign why it was done this way... Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6799167 ("real gcc build fails in libshell") ...
"Roger A. Faulkner" wrote:
> > "Roger A. Faulkner" wrote:
> > > > Roland Mainz wrote:
> > > > > This is a sponsor request to "fix" ([1]) CR #6799167
> > > > > (http://bugs.opensolaris.org/view_bug.do?bug_id=6799167 - "real gcc
> > > > > build fails in libshell").
> > > > >
> > > > > [1]=The "fix" is more a workaround since I don't know exactly how the
> > > > > ctf*-tools can be fixed.
> > > > >
> > > > > My contributor ID is "OS0025".
> > > > >
> > > > > Webrev follows later when my "hg clone" is complete...
> > > >
> > > > Webrev is now available at
> > > > http://cr.opensolaris.org/~gisburn/ksh93_integration_cr_6799167_001/ -
> > > > can anyone give me a short code review for the change, please (we'll
> > > > file a new bug in bugster to make sure the original issues doesn't get
> > > > forgotten) ?
> > >
> > > The code change looks good to me (and compiles for me).
> > > (I've been concerned about the not-buildable-with-gcc
> > > issue for some time now. I thought I was the only one.)
> >
> > It was AFAIK the only one (there are other VLA users in the tree but
> > they all use the arithmetric expressions and therefore avoid this
> > xxx@@@!!!-trap).
> >
> > > Nit:
> > > Could you break the comment into more than one line,
> > > to make it fit in 80-columns, something like:
> > >
> > > /*
> > > * Allocate one extra array entry as workaround for:
> > > * CR 6799167 real gcc build fails in libshell
> > > */
> >
> > Fixed. I've uploaded the new webrev as
> > http://cr.opensolaris.org/~gisburn/ksh93_integration_cr_6799167_002/
>
> Beautiful. Thanks.
For the log:
I've filed CR #6811985 ('"ctfconvert" fails when gcc x86 executable uses
"VLA" (="Variable Length Array")') to get the bug in "ctfconvert" fixed
(see attached email, too).
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
-- next part --
An embedded message was scrubbed...
From: bugmail-sen...@sun.com
Subject: CR 6811985 Created, P2 opensolaris/triage-queue "ctfconvert" fails
when gcc x86 executable uses "VLA" (="Variable Length Array")
Date: Mon, 2 Mar 2009 11:51:47 -0700 (MST)
Size: 6017
URL:
<http://mail.opensolaris.org/pipermail/request-sponsor/attachments/20090302/5490802d/attachment.nws>
[request-sponsor] Requesting sponsor for CR #6799167 ("real gccbuild fails in libshell") ...
John Beck wrote: > JohnS> ... I was under the impression that code should > JohnS> never make reference to the bug it fixes. Am I mistaken here? > > No, you are quite correct. Referring to an open bug e.g.: > > /* > * Work around silly misfeature until 699 is fixed. > */ > > is OK, but the comment proposed in this case is not. Something like: > > /* > * Allocate one extra array entry to keep gcc happy. > */ > > should suffice. Is the new webrev (http://cr.opensolaris.org/~gisburn/ksh93_integration_cr_6799167_003/) Ok for you ? It refernces an open bug instead of the one used for the putback... Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
[request-sponsor] [ksh93-integration-discuss] Requestingsponsor for CR #6799167 ("real gcc build fails in libshell") ...
John Levon wrote: > On Mon, Mar 02, 2009 at 11:01:54AM -0800, Garrett D'Amore wrote: > > John Sonnenschein wrote: > > >Sorry to butt in here, but I was under the impression that code should > > >never make reference to the bug it fixes. Am I mistaken here? > > > > Normally yes. However in this case, I think since the "workaround" may > > need some explanation, its not a bad idea to reference it. > > The correct CR is: > > 6379193 ctfconvert needs to support VLA for gcc's DWARF > > (which I just duped the new one to) Are you sure this is the same bug ? VLAs appear to work now with gcc builds in the case that the size is defined via an arithmetric expression... Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6799167 ("real gcc build fails in libshell") ...
Hi! This is a sponsor request to "fix" ([1]) CR #6799167 (http://bugs.opensolaris.org/view_bug.do?bug_id=6799167 - "real gcc build fails in libshell"). [1]=The "fix" is more a workaround since I don't know exactly how the ctf*-tools can be fixed. My contributor ID is "OS0025". Webrev follows later when my "hg clone" is complete... Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6862121 ("shbinexec kernel module defunct") ...
Hi! This is a sponsor request to fix CR #6862121 (http://bugs.opensolaris.org/view_bug.do?bug_id=6862121 - "shbinexec kernel module defunct"). Current webrev is available at http://cr.opensolaris.org/~gisburn/cr_6862121_shbinexec_kernel_module_defunct_20090720_002/ , received reviews from Jennifer Pioch, Garrett D'Amore and Irek Szcsesniak and passes the usual build tests. Note that the patch does not include a test module for the ksh93 test suite to avoid interference with the upcoming ksh93-integration update2 - I'll a RFE for that to get it implemented after the ksh93-integration update2 putback is done... My contributor ID is "OS0025". Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
[request-sponsor] [proposal] opensolaris OS/Net+SFWNV hacking summit...
Hi! Would be there some interest to run a small experiment and create a "hacking festival" (short: "hackfest") for OpenSolaris ? The goal is a bit different than a normal "hackfest" - the idea in this case is to get as _many_ putbacks (e.g. getting the maximum throughput+quality by having all neccesary people for the putbacks in _one_ location for four days with enougth coffee, whiteboards, pizza and computers) into OS/Net and SWFNV done as possible - which means we need: 1. Hackers/developers/engineers (up to 30 people maximum, canidate projects must have at least a raw prototype codebase which a) works (more or less) and b) fully passes a nightly build) 2. putback sponsors (from Sun's side) 3. Code reviewers (usually recruited from either [1], [2] or via IRC) 4. People to do the RTI 5. A copy of the OS/Net + SFWNV gates which is constantly being tested (e.g. putbacks first go into the matching SFWNV+OS/Net "hackfest" gate and once the summit is over the gate is tested again and then synced with the main gate) 6. Two or more lawyers (if any license issues need to be checked+approved) 7. Fast development and build machines. The basic layout should look like this: - Development machines/workstations (with no root rights for the owners to keep them in a "stable" state (hacking/testing experiments can be done on the "test" machines below (all machines share NFS home dirs+work dirs so there shouldn't be a problem))) - Test machines for doing BFU&co. - Gate machines (where the "hackfest" gates are located) - NFS&6o. servers (for the development machines) which provide home dirs, project dirs, HG+Subversion repositories, email services, NTP, FTP, Jumpstart etc. - Tinderbox machines which constantly build+test the "hackfest" gates to test whether all putbacks are working Comments/suggestions/etc. welcome... Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
[request-sponsor] [tools-discuss] snv_106 ksh93 update breaks Install(1M)
Roland Mainz wrote: > Edward Pilatowicz wrote: > > On Tue, Feb 03, 2009 at 04:39:31PM -0800, Edward Pilatowicz wrote: > > > so i just upgraded this morning from snv_105 to snv_106. now > > > Install(1M) is hanging whenever i run it. i'm wondering if anyone else > > > has seen this problem. (perhaps there's already a bug filed?) > > > > > > i'm running it as follows: > > > Install -o debug -k i86xpv -T domu-219:/tmp > > > > > > and here's where it's hung: > > > ---8<--- > > > edp at mcescher$ pstack 204600 > > > 204600: /bin/ksh /opt/onbld/bin/Install -o debug -k i86xpv -T > > > domu-219:/tmp > > > fd7fff2e3d1a write(1, 4154c0, 64) > > > fd7ffefdafc8 sfwr () + 2d0 > > > fd7ffefc0f6f _sfflsbuf () + 217 > > > fd7ffefcb9f7 sfsync () + 17f > > > fd7ffefc5c58 _sfphead () + 188 > > > fd7ffefc5ef5 _sfpmove () + 55 > > > fd7ffefc2595 _sfmode () + 22d > > > fd7ffefc5fb1 sfpool () + 99 > > > fd7fff15eb8e sh_exec () + 2f56 > > > fd7fff15f78c sh_exec () + 3b54 > > > fd7fff15d9c8 sh_exec () + 1d90 > > > fd7fff15788e sh_subshell () + 646 > > > fd7fff134562 comsubst () + 8a2 > > > fd7fff12f61f copyto () + bcf > > > fd7fff12df79 sh_macexpand () + 1f1 > > > fd7fff1129f5 arg_expand () + a5 > > > fd7fff112812 sh_argbuild () + 9a > > > fd7fff15dbe2 sh_exec () + 1faa > > > fd7fff15d854 sh_exec () + 1c1c > > > fd7fff0f22ef b_dot_cmd () + 507 > > > fd7fff161559 sh_funct () + 199 > > > fd7fff15ef35 sh_exec () + 32fd > > > fd7fff136e86 exfile () + 786 > > > fd7fff136676 sh_main () + 7fe > > > 00400e72 main () + 52 > > > 00400ccc > > > ---8<--- > > > > > > there is only one place where Install(1M) invokes "uniq": > > > set -- `grep "^CONF" $modlist | sort | uniq`; > > > > > > as it turns out, i can easily reproduce this problem as follows: > > > ---8<--- > > > edp at mcescher$ ksh93 > > > edp at mcescher$ set -- `cat /etc/termcap | sort | uniq` > > > > > > ---8<--- > > > > ok. i just filed: > > 6800929 snv_106 ksh93 update breaks Install(1M) > > Uhm... I think I have a "solid lead" where this bug hides... > ... but I need a sponsor for the putback (April Chin is no longer at > Sun) ... I have a patch which fixes the problem... ... does anyone have time to sponsor the fix for CR#6800929, please ? Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
[request-sponsor] [tools-discuss] snv_106 ksh93 update breaksInstall(1M)
Roland Mainz wrote:
> Roland Mainz wrote:
> > Edward Pilatowicz wrote:
> > > On Tue, Feb 03, 2009 at 04:39:31PM -0800, Edward Pilatowicz wrote:
> > > > so i just upgraded this morning from snv_105 to snv_106. now
> > > > Install(1M) is hanging whenever i run it. i'm wondering if anyone else
> > > > has seen this problem. (perhaps there's already a bug filed?)
> > > >
> > > > i'm running it as follows:
> > > > Install -o debug -k i86xpv -T domu-219:/tmp
> > > >
> > > > and here's where it's hung:
> > > > ---8<---
> > > > edp at mcescher$ pstack 204600
> > > > 204600: /bin/ksh /opt/onbld/bin/Install -o debug -k i86xpv -T
> > > > domu-219:/tmp
> > > > fd7fff2e3d1a write(1, 4154c0, 64)
> > > > fd7ffefdafc8 sfwr () + 2d0
> > > > fd7ffefc0f6f _sfflsbuf () + 217
> > > > fd7ffefcb9f7 sfsync () + 17f
> > > > fd7ffefc5c58 _sfphead () + 188
> > > > fd7ffefc5ef5 _sfpmove () + 55
> > > > fd7ffefc2595 _sfmode () + 22d
> > > > fd7ffefc5fb1 sfpool () + 99
> > > > fd7fff15eb8e sh_exec () + 2f56
> > > > fd7fff15f78c sh_exec () + 3b54
> > > > fd7fff15d9c8 sh_exec () + 1d90
> > > > fd7fff15788e sh_subshell () + 646
> > > > fd7fff134562 comsubst () + 8a2
> > > > fd7fff12f61f copyto () + bcf
> > > > fd7fff12df79 sh_macexpand () + 1f1
> > > > fd7fff1129f5 arg_expand () + a5
> > > > fd7fff112812 sh_argbuild () + 9a
> > > > fd7fff15dbe2 sh_exec () + 1faa
> > > > fd7fff15d854 sh_exec () + 1c1c
> > > > fd7fff0f22ef b_dot_cmd () + 507
> > > > fd7fff161559 sh_funct () + 199
> > > > fd7fff15ef35 sh_exec () + 32fd
> > > > fd7fff136e86 exfile () + 786
> > > > fd7fff136676 sh_main () + 7fe
> > > > 00400e72 main () + 52
> > > > 00400ccc
> > > > ---8<---
> > > >
> > > > there is only one place where Install(1M) invokes "uniq":
> > > > set -- `grep "^CONF" $modlist | sort | uniq`;
> > > >
> > > > as it turns out, i can easily reproduce this problem as follows:
> > > > ---8<---
> > > > edp at mcescher$ ksh93
> > > > edp at mcescher$ set -- `cat /etc/termcap | sort | uniq`
> > > >
> > > > ---8<---
> > >
> > > ok. i just filed:
> > > 6800929 snv_106 ksh93 update breaks Install(1M)
> >
> > Uhm... I think I have a "solid lead" where this bug hides...
> > ... but I need a sponsor for the putback (April Chin is no longer at
> > Sun) ...
>
> I have a patch which fixes the problem...
> ... does anyone have time to sponsor the fix for CR#6800929, please ?
Attached (as
"cr6800929_large_command_substitution_hang20090206001.diff.txt") is a
patch which should fix the problem (the patch itself is complete but I
am going to add a ksh93 test suite module to make sure we won't hit this
bug again in the future) ...
... Edward: Do you have time to sponsor this, please ?
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
-- next part --
Index: src/lib/libshell/common/include/defs.h
===
--- src/lib/libshell/common/include/defs.h (revision 1391)
+++ src/lib/libshell/common/include/defs.h (working copy)
@@ -166,6 +166,7 @@
charwinch; \
charindebug;/* set when in debug trap */ \
unsigned char lastsig;/* last signal received */ \
+ charsubshare; /* set when in ${..} comsub */ \
char*readscript;/* set before reading a script */ \
int *inpipe;/* input pipe pointer */ \
int *outpipe; /* output pipe pointer */ \
Index: src/lib/libshell/common/sh/subshell.c
===
--- src/lib/libshell/common/sh/subshell.c (revision 1391)
+++ src/lib/libshell/common/sh/subshell.c (working copy)
@@ -89,6 +89,7 @@
int coutpipe;
int cpipe;
int nofork;
+ charsubshare;
} *sub
[request-sponsor] Seeking sponsor for ksh93-integration update2 work...
Hi!
This is a sponsor request for the ksh93-integration update2 putback
which is covered by the following CR#'s in bugster:
CR #6793763 ("RFE: Update /usr/bin/ksh93 to ast-ksh.2009-01-14")
CR #6793722 ('RFE: Update /usr/bin/cmp to AT&T AST "cmp')
CR #6793714 ('RFE: Update /usr/bin/comm to AT&T AST "comm')
CR #6793719 ('RFE: Update /usr/bin/cut to AT&T AST "cut"')
CR #6793721 ('RFE: Update /usr/bin/paste to AT&T AST "paste"')
CR #6793747 ('RFE: Provide "print" builtin as /usr/bin/print for
external applications')
CR #6793726 ('RFE: Update /usr/bin/uniq to AT&T AST "uniq"')
CR #6793735 ('RFE: Update /usr/bin/wc to AT&T AST "wc"')
CR #6794952 ("RFE: Enable "globstar" mode in /etc/ksh.kshrc (=
interactive ksh93 shells)")
CR #6800113 ("We need a /usr/xpg4/bin/printf utility for SUS
conformance")
CR #6793744 ("RFE: Add /usr/share/doc/ksh/ for ksh93 documentation")
CR #6791838 ("*ksh93* unset of a variable which is not set should return
0")
CR #6790507 ("RFE: Update /usr/bin/tail and /usr/xpg4/bin/tail to AT&T
AST tail")
CR #6789247 ("[ku1] libast/ksh93 1-digit hexfloat base conversion rounds
incorrectly")
CR #6778077 ("*ksh93* does not understand "THAW" as a signal for use
with trap")
CR #6631969 ("/usr/bin/printf does not recognize positional arguments
like %n$")
CR #6765756 ("*libast* Array overruns in libast")
CR #6764665 ("*libpp* Array overrun in libpp")
CR #6805792 ("Moving local compound var into array does not work")
CR #6805794 ('printf returns "invalid character constant" for $ printf
"%d\n" "'"')
CR #6805797 ('Can't append to nodes of an array of comp. vars if
addressing them via nref')
CR #6805795 ("ksh93 does not differ between -0 and +0")
CR #6805800 ("Declaring associative compound array does not work")
CR #6805799 ("Indexed compound variable arrays do not work...")
Note that this list looks large but this is technically only one single
putback.
My contributor ID is "OS0025".
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
[request-sponsor] Seeking sponsor for ksh93-integration update2 work...
Casper.Dik at Sun.COM wrote:
>
> >CR #6800113 ("We need a /usr/xpg4/bin/printf utility for SUS
> >conformance")
>
> Is there a incompatibility between xpg4 printf and /usr/bin/printf?
http://svn.genunix.org/repos/on/branches/ksh93/gisburn/arc/printf/onepager.txt
explains the difference:
-- snip --
Notes:
- The only difference between /usr/bin/printf and /usr/xpg4/bin/printf
is
that /usr/bin/printf's "%s" precision option counts in screen columns
for SystemV backwards compatibity (e.g. a "screen column" means a
character which only spans one column - there are multibyte characters
which span more than one column).
-- snip --
Or short: The current /usr/bin/printf is _not_ POSIX/SUS conformant and
cannot be fixed because it must behave (in this case) like the original
Solaris version. Therefore we need a /usr/xpg4/bin/printf to handle this
case (ksh93's "printf" version will behave like /usr/xpg4/bin/printf
_without_ being bound to a PATH element (Don Cragun signed this off)).
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6807179 ("ksh93 does unneccesary |libc::getpwnam()| lookups for ~(modifer)pattern patterns")
Hi!
This is a sponsor request to fix CR #6807179 ("ksh93 does unneccesary
|libc::getpwnam()| lookups for ~(modifer)pattern patterns")
My contributor ID is "OS0025".
Webrev can be found at
http://cr.opensolaris.org/~gisburn/ksh93_integration_cr_6807179_001/
(matching ksh93 test suite module comes later)
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6807179 ("ksh93 does unneccesary |libc::getpwnam()| lookups for ~(modifer)pattern patterns")
Casper.Dik at Sun.COM wrote:
> >This is a sponsor request to fix CR #6807179 ("ksh93 does unneccesary
> >|libc::getpwnam()| lookups for ~(modifer)pattern patterns")
> >
> >My contributor ID is "OS0025".
> >
> >Webrev can be found at
> >http://cr.opensolaris.org/~gisburn/ksh93_integration_cr_6807179_001/
> >(matching ksh93 test suite module comes later)
>
> I'll take this. I hope to get this in this build (110).
Thanks! :-)
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
[request-sponsor] CR 6870093
Garrett D'Amore wrote: > > I would like to record the fact that I am sponsoring Roland Mainz on > 6870093. Please add this to the request sponsor table. I expect I'll > be integrating his changes shortly after the associated PSARC case > (2009/429) is approved. Erm... technically I asked Pete Dennis to sponsor this... ... if you already started with testing and RTI please "scream here", otherwise just pass it over to Pete, please (I have more patches in my "gisburn's janitor work queue" ...) ... Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
[request-sponsor] 1224122 windex not created by install/upgrade
Mike Gerdts wrote:
[CC:'ing Michelle Olson as co-lead of the
(yet-to-be-announched) manpage-subsystem-rewrite project]
>
> I'm looking for a sponsor for the following:
>
> 1224122 windex not created by install/upgrade
> 4858166 makewhatis should remove duplicate windex entries
>
> A working prototype prototype is at:
>
> http://cr.opensolaris.org/~mgerdts/windex-service/
Groan...
... for the log: I am currently _rewriting_ the manpage subsystem from
scratch (the frontend already exists as
http://svn.genunix.org/repos/on/branches/ksh93/gisburn/scripts/shman.ksh
; I'm now waiting for the "ksh93-integration update1" to land before
doing the remaining work). IMO it may be nice to syncronize the work a
bit...
Some notes:
- IMO it may be nice to have something like /etc/man/mandirs which keeps
track of directories which contain man directories and a tool ("manadm"
?) which adds/removes entries to that list and invokes the crawling
process for all subdirs listed there.
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] 1224122 windex not created by install/upgrade
Roland Mainz wrote:
> Mike Gerdts wrote:
[snip]
> Some notes:
> - IMO it may be nice to have something like /etc/man/mandirs which keeps
> track of directories which contain man directories and a tool ("manadm"
> ?) which adds/removes entries to that list and invokes the crawling
> process for all subdirs listed there.
BTW: When I say "list" - the file should contain a ksh93 serialised
array variable (e.g. something like
http://www.nrubsig.org/people/gisburn/work/sun/xserver_license_extractor/X-src-20071107_XW_NV_open-src_tarballs_extraced_comments20080331.cpv)
- this avoids any problems with adding new fields/options/etc. since the
shell will be able to read it anyway...
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6662241 ("RFE: Link /usr/xpg4/bin/sh to /usr/bin/ksh93") / was: [Fwd: CR 6662241 Created P3 opensolaris/triage-queue RFE: Link/usr/xpg4/bin/sh to /usr/bin/
April Chin wrote:
> > This is a sponsor request to fix CR #6662241 ("RFE: Link
> > /usr/xpg4/bin/sh to /usr/bin/ksh93") which should follow CR #6619428
> > ("RFE: Update ksh93 in Solaris to ast-ksh.2007-10-15 (or higher)").
> >
> > My contributor ID is "OS0025".
> >
> > Original Message
> > Subject: CR 6662241 Created P3 opensolaris/triage-queue RFE:
> > Link/usr/xpg4/bin/sh to /usr/bin/ksh93
> > Date: Tue, 12 Feb 2008 12:50:14 -0700 (MST)
> > From: bugmail-sender at Sun.COM
> > To: undisclosed-recipients: ;
> >
> > *Synopsis*: RFE: Link /usr/xpg4/bin/sh to /usr/bin/ksh93
[snip]
>
> I'll sponsor this.
Thanks! :-)
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] request-sponsor BUG ID(s) : 6649911,6578005
vinay simha wrote: > > name1 : Vinay Simha.B.N > email id: simhavcs at gmail.com > name2 : Beeresh.G > email-id: beeresh at gmail.com > > Bug ID Number : 6649911 > synopsis:/usr/bin/printf should support field width or precision > format specifiers like %*d or %0*d > category : utility > subcategory : shell > description : /usr/bin/printf should be able to use field with or > precision format specifiers like %*d or %0*d [snip] /usr/bin/printf is currently closed-source, however we're working on a replacement codebase which will be completely opensource and will cover this CR# (and most of the other RFEs for /usr/bin/printf), too - see http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2007-December/005831.html for the matching ARC case draft. Technically the only thing I forgot was to ask for a sponsor for this CR ... ;-( Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
[request-sponsor] request-sponsor BUG ID(s) : 6649911,6578005
"Dana H. Myers" wrote: > vinay simha wrote: > > Bug ID Number :* 6649911* > > synopsis:/usr/bin/printf should support field width or precision > > format specifiers like %*d or %0*d > > category : utility > > subcategory : shell > > description : /usr/bin/printf should be able to use field with or > > precision format specifiers like %*d or %0*d > > I believe the source code to /usr/bin/printf is one of the small number > of files > from Solaris that are not available in OpenSolaris - do you already have > a proposed > fix for this? Erm... I already have a replacement for the current /usr/bin/printf codebase ready (e.g. the code itself is already finished) which covers CR #6649911 and almost all of the other outstanding RFEs and bug reports for /usr/bin/printf ... right now we're waiting for the ARC case being started (see http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2007-December/005831.html for the draft). Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6662241 ("RFE: Link /usr/xpg4/bin/sh to /usr/bin/ksh93") / was: [Fwd: CR 6662241 Created P3 opensolaris/triage-queue RFE: Link/usr/xpg4/bin/sh to /usr/bin/
Hi!
This is a sponsor request to fix CR #6662241 ("RFE: Link
/usr/xpg4/bin/sh to /usr/bin/ksh93") which should follow CR #6619428
("RFE: Update ksh93 in Solaris to ast-ksh.2007-10-15 (or higher)").
My contributor ID is "OS0025".
Original Message
Subject: CR 6662241 Created P3 opensolaris/triage-queue RFE:
Link/usr/xpg4/bin/sh to /usr/bin/ksh93
Date: Tue, 12 Feb 2008 12:50:14 -0700 (MST)
From: bugmail-sen...@sun.com
To: undisclosed-recipients: ;
*Synopsis*: RFE: Link /usr/xpg4/bin/sh to /usr/bin/ksh93
*Change Request ID*: 6662241
*Synopsis*: RFE: Link /usr/xpg4/bin/sh to /usr/bin/ksh93
Product: solaris
Category: opensolaris
Subcategory: triage-queue
Type: RFE
Subtype:
Status: 1-Dispatched
Substatus:
Priority: 3-Medium
Introduced In Release:
Introduced In Build:
Responsible Engineer:
Keywords: opensolaris
=== *Description*
Category
shell
Sub-Category
korn
Description
RFE: Link /usr/xpg4/bin/sh to ksh93. ksh93 (after the update in CR
#6619428) should be standard-conformant enougth to take-over the job of
the "POSIX shell" (=/usr/xpg4/bin/sh in Solaris; the
platform-independent way to find the POSIX shell is to fetch the value
of $ getconf CS_PATH # and search this path for "sh") which is currently
done by a modified version of the (closed-source) ksh88 codebase.
AFAIK the following things may need to be done (needs to be discussed
with Don Cragun and April Chin; most of these items may be done in ksh93
itself or by writing a different "frontend" binary for libshell.so.1
(which contains the core of ksh93) which does these adjustments):
- Bind the "echo" builtin to /usr/bin/echo
- Bind the "printf" builtin to /usr/bin/printf
- ... [more stuff may need to be done based on discussions and what the
VSW test suite says]
Frequency
Always
Regression
No
Steps to Reproduce
-
Expected Result
-
Actual Result
-
Error Message(s)
-
Test Case
-
Workaround
-
Submitter wants to work on bug
Yes
Additional configuration information
Solaris 11/B72
*** (#1 of 1): 2008-02-12 19:49:27 GMT+00:00
=== *Workaround*
=
=== *Additional Details*
=
Targeted Release:
Commit To Fix In Build:
Fixed In Build:
Integrated In Build:
Verified In Build:
See Also: 6619428
Duplicate of:
Hooks:
Hook1:
Hook2:
Hook3:
Hook4:
Hook5:
Hook6:
Program Management:
Root Cause:
Fix Affects Documentation: No
Fix Affects Localization: No
=== *History*
Date Submitted: 2008-02-12 19:49:26 GMT+00:00
Submitted By:
Status ChangedDate Updated Updated By
=== *Service Request*
Impact: Significant
Functionality: Secondary
Severity: 3
Product Name: solaris
Product Release: solaris_nevada
Product Build: snv_72
Operating System: solaris_nevada
Hardware: generic
Submitted Date: 2008-02-12 19:49:27 GMT+00:00
=== *Multiple Release (MR) Cluster* - 0
==
[request-sponsor] CR #6667990 ("quagga svc method script breaks with ksh93") ...
Hi!
This is a sponsor request to fix CR #6667990 ("quagga svc method script
breaks with ksh93").
My contributor ID is "OS0025".
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] CR #6667990("quagga svc method script breaks with ksh93") ...
Garrett D'Amore wrote:
> Roland Mainz wrote:
> > This is a sponsor request to fix CR #6667990 ("quagga svc method script
> > breaks with ksh93").
> >
> > My contributor ID is "OS0025".
>
> I'll sponsor this request.
Thanks! :-)
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] CR #6668828 ("Quagga SMF script may return random return code") ...
Hi!
This is a sponsor request to fix CR #6668828 ("Quagga SMF script may
return random return code").
My contributor ID is "OS0025".
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6687656 ("Provide an opensource version of /usr/xpg4/bin/sed and /usr/bin/sed") ...
Hi!
This is a sponsor request for CR #6687656 ("Provide an opensource
version of /usr/xpg4/bin/sed and /usr/bin/sed") ...
My contributor ID is "OS0025".
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] request sponsor for 6518038: cron & crontabshould support multiple timezones
Darren J Moffat wrote: > Chris Gerhard wrote: > > I have a working prototype which I have documented here: > > > > http://blogs.sun.com/chrisg/entry/mutliple_time_zones_for_cron > > > > Since this is not part of my day job, I'm requesting a sponsor despite > > being a Sun employee so I can do this on my own time. > > Chris is local to me (physically and timezone :-) I hope that we can > present the full process at a future LOSUG and given this needs ARC > review I'll sponsor the ARC case and the putback for this. Two items: 1. Is it possible to sync with the POSIX people whether the change is legal for XPG4/XPG6, please (CC:'ing Don Cragun for that) ? 2. Somewhere in my queue is support for sub-minute timing in cron... would it be usefull to add this in one step with this patch, too ? Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
[request-sponsor] request sponsor for 6518038: cron & crontabshould support multiple timezones
On 2/14/07, Richard Lowe wrote: > Don Cragun wrote: > > Roland, > > Thanks for bringing this to my attention. > > > > Chris, > > The format shown in > > [... huge amount of snipping ...] > > This conversation is still happening on request-sponsor, which is a tool, > not a discussion list. Could it please be diverted to opensolaris-rfe or > the like, where it belongs? Please move the discussion to shell-discuss at opensolaris.org - AFAIK that is the closest match in this case. As possible solution (I don't have the manual pages around) the environment variables could be used. AFAIK (POSIX) cron allows it to add variable definitions in the form of = at the beginning of the crontab file. If this is really allowed we could follow ksh93's approach to compound variables (please read http://www.opensolaris.org/os/project/ksh93-integration/docs/ksh93r/man/man1/sh/ - the syntax should follow POSIX shell+crontab rules, including quoting etc.) and use a variable like ".cron.timezone" (note the '.' at the beginning) as variable name to define a timezone per line (please do not use something like ".cron.TZ", uppercase names should be avoided to prevent confusion with environment variables defined here and long variable names do not hurt anyone). This would allow setting "cron"-specific settings for the following lines and provide an easy mechanism for future extensions of the crontab without creating some format and/or parser nightmare. Anyway... please move the discussion to shell-discuss at opensolaris.org if possible... Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
[request-sponsor] Requesting sponsor for Sun-Bug #6452094 ("An interactive bash shell should source /etc/bash.bashrc")
Hi! Is anyone interested to sponsor Sun-Bug #6452094 (http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6452094 - "An interactive bash shell should source /etc/bash.bashrc") ? The RFE should enable "/etc/bash.bashrc" and "/etc/bash.bash_logout" for bash to keep it in sync (e.g. feature-parity) with ksh93. My contributor ID is "OS0025". Bye, ROland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
[request-sponsor] Seeking sponsor for CR #6540124 ("RFE: OS/Netbuildcould be slightly more portable")
Alan Burlison wrote:
> Roland Mainz wrote:
> > Roland Mainz wrote:
> >> Requesting sponsor for CR #6540124 ("RFE: OS/Net build could be slightly
> >> more portable"). The patch is attached in a bug...
> >>
> >> ... Alan: Would you be interested to sponor the fix ? Most of the patch
> >> affects your territory...
> >
> > Ok... Garrett D'Amore volunters as "code reviewer"
> > ...
> > ... which means I only need a "sponsor" and Alan Burlison's "blessing"
> > for the patch...
>
> I never actually received the patch..
Uhm... please check your InBox whether you received "Message-ID:
<4608C1D8.E0DB907F at nrubsig.org>" ...
... I've attached the patch as
"cr_6540124_more_portable_os_net_001.diff.txt".
The patch covers two items:
1. usr/src/lib/libmapid/Makefile.com assumes "ln" can override an
exixting link. This will not work for a POSIX-conformant version of
"ln". The patch...
-- snip --
Index: src/lib/libmapid/Makefile.com
===
--- src/lib/libmapid/Makefile.com (revision 647)
+++ src/lib/libmapid/Makefile.com (working copy)
@@ -41,6 +41,7 @@
ROOTSLINK32 = $(ROOTLIBDIR)/32
$(ROOTSLINK32):$(ROOTLIBDIR)
+ $(RM) $@ ; \
$(SYMLINK) . $@
#
-- snip --
... fixes the problem by adjusting usr/src/lib/libmapid/Makefile.com to
follow the XPG rules for "ln" (e.g. it can't overwrite an existing
link).
2. The 2nd major part (which affects your territory) is the patch for
usr/src/cmd/perl/ which fixes a problem with "unset".
http://www.opengroup.org/onlinepubs/95399/utilities/unset.html says:
-- snip --
EXIT STATUS
0
All name operands were successfully unset.
>0
At least one name could not be unset.
-- snip --
Since the maching variables may not be set "unset" returns an exit code
greater than zero and will therefore trigger the matching "make" rules
to fail if the shell used by the Makefile implements the "unset" builtin
correctly.
The diffs for usr/src/cmd/perl/ in the attached patch fix that (and a
missing ';' after "pwd").
> A webrev would be handy.
That's a little bit tricky... "webrev" currently has no working
Subversion support and my home-grown script is only able to compare two
checked-in versions (which means I have to create a branch etc. etc.).
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
-- next part --
Index: src/cmd/perl/5.6.1/extract_makeext.sh
===
--- src/cmd/perl/5.6.1/extract_makeext.sh (revision 647)
+++ src/cmd/perl/5.6.1/extract_makeext.sh (working copy)
@@ -123,7 +123,7 @@
for ext in $nonxs_ext
do
printf '%s: %s/Makefile FRC\n' $ext $ext
- printf '\t@ cd $@; pwd '
+ printf '\t@ cd $@; pwd; '
printf '$(PERL_MM_ENV); $(MAKE) all\n\n'
done
Index: src/cmd/perl/5.6.1/extract_config.sh
===
--- src/cmd/perl/5.6.1/extract_config.sh(revision 647)
+++ src/cmd/perl/5.6.1/extract_config.sh(working copy)
@@ -76,7 +76,7 @@
printf 'PERL_POD_DIR = $(ROOT)%s/pod\n' $privlibexp
# Compilation environment flags
-printf 'KEEP_STATE_OFF = unset KEEP_STATE SUNPRO_DEPENDENCIES\n'
+printf 'KEEP_STATE_OFF = unset KEEP_STATE SUNPRO_DEPENDENCIES || true\n'
printf 'PERL_COREFLAGS = -DPERL_CORE\n'
printf 'PERL_LFFLAGS = %s\n' "$ccflags_uselargefiles"
printf 'PERL_LDLIBS = %s\n' "$perllibs"
Index: src/cmd/perl/5.8.4/extract_makeext.sh
===
--- src/cmd/perl/5.8.4/extract_makeext.sh (revision 647)
+++ src/cmd/perl/5.8.4/extract_makeext.sh (working copy)
@@ -122,7 +122,7 @@
for ext in $nonxs_ext
do
printf '%s: %s/Makefile FRC\n' $ext $ext
- printf '\t@ cd $@; pwd '
+ printf '\t@ cd $@; pwd; '
printf '$(PERL_MM_ENV); $(MAKE) all\n\n'
done
Index: src/cmd/perl/5.8.4/extract_config.sh
===
--- src/cmd/perl/5.8.4/extract_config.sh(revision 647)
+++ src/cmd/perl/5.8.4/extract_config.sh(working copy)
@@ -76,7 +76,7 @@
printf 'PERL_POD_DIR = $(ROOT)%s/pod\n' $privlibexp
# Compilation environment flags.
-printf 'KEEP_STATE_OFF = unset KEEP_STATE SUNPRO_DEPENDENCIES\n'
+p
[request-sponsor] Seeking sponsor for CR #6540124 ("RFE:OS/Netbuildcouldbe slightly more portable")
Richard Lowe wrote: > Rainer Orth wrote: > > Roland Mainz writes: > > > >> The patch covers two items: > >> 1. usr/src/lib/libmapid/Makefile.com assumes "ln" can override an > >> exixting link. This will not work for a POSIX-conformant version of > >> "ln". The patch... > >> -- snip -- > >> Index: src/lib/libmapid/Makefile.com > >> === > >> --- src/lib/libmapid/Makefile.com (revision 647) > >> +++ src/lib/libmapid/Makefile.com (working copy) > >> @@ -41,6 +41,7 @@ > >> ROOTSLINK32 = $(ROOTLIBDIR)/32 > >> > >> $(ROOTSLINK32):$(ROOTLIBDIR) > >> + $(RM) $@ ; \ > >> $(SYMLINK) . $@ > >> > >> # > >> -- snip -- > >> ... fixes the problem by adjusting usr/src/lib/libmapid/Makefile.com to > >> follow the XPG rules for "ln" (e.g. it can't overwrite an existing > >> link). > > > > This is CR 6434605 (repeated make install fails in libmapid). I observed > > this during nightly -i builds, but couldn't reproduce it later. > > > > This was effectively fixed by kupfer on November 10th as 6477808, which > removed the lines in question (and the racy link). Sounds like Mike Kupfer was faster... :-) ... Ok... but the "perl" part is still there and may break the build... Status: - Reviewer: gdamore - Blessed by perl maintainer: Done. - Sponsor: WANTED Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR# 6488593("/etc/profile should set TMPDIR to /tmp/$LOGNAME/") ...
Darren J Moffat wrote:
> Roland Mainz wrote:
> > Requesting sponsor for CR# 6488593 ("/etc/profile should set TMPDIR to
> > /tmp/$LOGNAME/") - patch is included in the RFE...
>
> This will I believe need an ARC case since it is a change in default
> behaviour. It also should be done for all shells not just ones
> that read /etc/profile.
>
> Since I do this myself in my own .profile I feel duty bound to stand up
> to the plate and by your sponsor for this. So sign me up for putback
> sponsor and I'll be ARC case submitter too.
ping! ... did you get any of my emails about this RFE ?
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6546677 ("usr/src/cmd/perl/ build installs Subversion directories (.svn) in the proto area") / [Fwd: makebfu's trouble with "cpiotranslate: usr/perl5/5.
Hi!
Requesting sponsor for CR #6546677 ("usr/src/cmd/perl/ build installs
Subversion directories (.svn) in the proto area"). The proposed patch is
attached to the forwarded message below
Original Message
Subject: makebfu's trouble with "cpiotranslate:
usr/perl5/5.6.1/lib/.svn/text-base/Carp.pm.svn-base: no packaging info"
...
Date: Mon, 16 Apr 2007 08:00:17 +0200
From: Roland Mainz
To: OpenSolaris Code mailing list
CC: Alan Burlison ,Mike Kupfer
Hi!
Attached is a prototype patch
("osnet_cmd_perl_copy_svn_fix001.diff.txt") which deals with the issue
that "make install" in "usr/src/cmd/perl/" copies the Subversion
(assuming the sources are under Subversion control) context dirs (e.g.
".svn/") into the proto area, e.g.
-- snip --
$ time nice makebfu 2>&1 | tee -a buildlog_makebfu.log
Making archives from
/home/test001/ksh93/on_build1/test1_x86/proto/root_i386 in
/home/test001/ksh93/on_build1/test1_x86/archives/i386/nightly.
Creating generic kernel archive:152240 blocks
Creating generic lib archive: 59950 blocks
Creating generic root archive: 4720 blocks
Creating generic sbin archive: 2520 blocks
Failed to create generic usr archive: 379370 blocks
cpiotranslate: usr/perl5/5.6.1/lib/File/Spec/.svn/entries: no packaging
info
cpiotranslate: usr/perl5/5.6.1/lib/File/Spec/.svn/format: no packaging
info
cpiotranslate:
usr/perl5/5.6.1/lib/File/Spec/.svn/text-base/VMS.pm.svn-base: no
packaging info
cpiotranslate:
usr/perl5/5.6.1/lib/File/Spec/.svn/text-base/Epoc.pm.svn-base: no
packaging info
[snip]
cpiotranslate: usr/perl5/5.6.1/lib/.svn/text-base/integer.pm.svn-base:
no packaging info
cpiotranslate: usr/perl5/5.6.1/lib/.svn/text-base/Dumpvalue.pm.svn-base:
no packaging info
cpiotranslate: usr/perl5/5.6.1/lib/.svn/text-base/FileCache.pm.svn-base:
no packaging info
cpiotranslate: usr/perl5/5.6.1/lib/.svn/text-base: no packaging info
cpiotranslate: usr/perl5/5.6.1/lib/.svn: no packaging info
Creating i86pc boot archive:5070 blocks
Creating i86pc root archive:11090 blocks
Creating i86pc usr archive: 2300 blocks
Creating conflict resolution archive: 630 blocks
real1m6.791s
user0m1.978s
sys 0m4.601s
$
-- snip --
The attached patch fixes this (and "yes", I filed a bug at
http://bugs.opensolaris.org/ but I didn't get any response yet... ;-( ).
Questions:
- Is the patch Ok ?
- Should I add support for Mercuial and GIT, too ?
- Are there any volunteers who are interested to sponsor the patch ?
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
-- next part --
Index: src/cmd/perl/5.6.1/distrib/ext/IPC/SysV/Makefile.PL
===
--- src/cmd/perl/5.6.1/distrib/ext/IPC/SysV/Makefile.PL (revision 680)
+++ src/cmd/perl/5.6.1/distrib/ext/IPC/SysV/Makefile.PL (working copy)
@@ -32,7 +32,7 @@
my($self,$path) = @_;
return ''
- if($path =~ m:/(RCS|CVS|SCCS)/: ||
+ if($path =~ m:/(RCS|CVS|SCCS|\.svn)/: ||
$path =~ m:[~%]$: ||
$path =~ m:\.(orig|rej)$:
);
Index: src/cmd/perl/5.6.1/distrib/lib/ExtUtils/MM_Unix.pm
===
--- src/cmd/perl/5.6.1/distrib/lib/ExtUtils/MM_Unix.pm (revision 680)
+++ src/cmd/perl/5.6.1/distrib/lib/ExtUtils/MM_Unix.pm (working copy)
@@ -1485,7 +1485,7 @@
require File::Find;
File::Find::find(sub {
if (-d $_){
- if ($_ eq "CVS" || $_ eq "RCS"){
+ if ($_ eq "CVS" || $_ eq "RCS" || $_ eq ".svn"){
$File::Find::prune = 1;
}
return;
@@ -2249,7 +2249,7 @@
Takes a path to a file that is found by init_dirscan and returns false
if we don't want to include this file in the library. Mainly used to
-exclude RCS, CVS, and SCCS directories from installation.
+exclude RCS, CVS, SCCS and Subversion directories from installation.
=cut
@@ -2257,7 +2257,7 @@
sub libscan {
my($self,$path) = @_;
-return '' if $path =~ m:\b(RCS|CVS|SCCS)\b: ;
+return '' if $path =~ m:\b(RCS|CVS|SCCS|\.svn)\b: ;
$path;
}
Index: src/cmd/perl/5.6.1/distrib/installperl
===
--- src/cmd/perl/5.6.1/distrib/installperl (revision 680)
+++ src/cmd/perl/5.6.1/distrib/installperl (working copy)
@@ -657,8 +657,8 @@
my $name = $_;
-# Ignore SCCS, RCS and CVS directories.
-if ((($name eq 'SCCS' or $name eq 'CVS' or $name eq 'RCS') and -d $name)
+# Ignore SCCS, RCS, CVS and Subversion directories.
+i
[request-sponsor] Requesting sponsor for CR#6474270 ("isaexec and magical builds") ...
Hi!
This is a sponsor request to implement the RFE/CR#6474270 ("isaexec and
magical builds" -
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6474270). I
already have an older patch around for that (originally written to test
the ksh93 isaexec bridge) and IMO it may be nice to move this code into
OS/Net...
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Sponsor request for bug #6407808 ("RFE: isaexec(1) should use isaexec(3C) API instead of homegrown code")
Hi!
I'd like to get sponsored for bug #6407808 ("RFE: isaexec(1) should use
isaexec(3C) API instead of homegrown code").
http://mail.opensolaris.org/pipermail/opensolaris-discuss/2006-April/014956.html
already has a patch for the issue...
Thanks! :-)
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6733971 ("Lint targets not POSIX shell (=ksh93) safe in OS/Net propagation in OS/Net Makefiles") ...
Hi! This is a sponsor request to fix CR #6733971 (http://bugs.opensolaris.org/view_bug.do?bug_id=6733971 - "Lint targets not POSIX shell (=ksh93) safe in OS/Net propagation in OS/Net Makefiles") ... My contributor ID is "OS0025". Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
[request-sponsor] [ksh93-integration-discuss] [indiana-discuss] "arithmeticsyntax error" on every file when "dmake lint" on OpenSolaris200805
Roland Mainz wrote: > James Carlson wrote: > > Alan Coopersmith writes: > > > I believe it's a known issue caused by the ksh93 used as /bin/sh in > > > indiana interpreting the (( )) as the syntax to do arithmetic. > > > > > > The ON makefiles will need to be fixed to not put two parentheses > > > next to each other when arithmetic evaluation is not desired. > > > > It's CR 6733971. > > The patches are ready, I still need a reviewer later today (>= 11:00PM, > MET timezone) once the test builds+BFU stuff is complete and reply to a > gatekeepers email... This is still stuck in the request-sponsor list awaiting a sponsor... ;-( Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
[request-sponsor] Shooting my mouth off
Ceri Davies wrote: > > It occurs to me that I've been reviewing patches posted here where it > might not actually be welcome. Tell me to shut up if necessary, > although I'm concerned that this review should happen and preferably in > good time after a submission is posted (rather than after the > potentially long wait for a sponsor to come forward). I'm not sure but AFAIK review comments should always be welcome... I wouldn't worry that much... :-) Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
[request-sponsor] Remove sponsorship of Bug 6431132
Ebru Williams wrote: > > 6431132: legacy yacc code cannot be maintained or understood > Update from the sponsor of this bug indicates that this request is > dead. The contributor has no access to a Solaris system the code, what > he contributed does not match the bug and the whole thing was massively > unclean. Please remove this bug from the sponsorship list. Mhhh... AST/UWIN (the upstream where ksh93 is coming from) has a maintained version of "yacc" which may be suiteable as replacement... Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6451262 ("RFE:
"Richard L. Hamilton" wrote:
> > This is a sponsor request to implement the RFE/CR
> > #6451262 ("RFE:
> > /usr/bin/sleep should support floating-point values"
> > -
> > http://bugs.opensolaris.org/view_bug.do?bug_id=6451262
> > ).
> > An old draft for the matching ARC case can be found
> > at
> > http://svn.genunix.org/repos/on/branches/ksh93/gisburn
> > /arc/sleep/solaris_sleep_fasttrack.txt
> > (comments welcome) ...
> >
> > My contributor ID is "OS0025".
>
> Why do I think you're going to do this in terms of ksh93? :-)
Well, it's the easiest and cheapest way to do it and we have the
precedent of /usr/bin/ksh doing it for things like /usr/bin/test ... :-)
> Maybe since it's sleep builtin can do that?
>
> So, will it be
>
> #! /usr/bin/ksh93
> # do we need to set PATH to ensure the builtin is used?
Currently the "sleep" builtin is not bound to a PATH (one reason is to
avoid that the shell has to travel all PATH elements at the first usage
and |stat()| if there are other "sleep" commands around (which is
inacceptable for sub-second timeouts like $ sleep 0.001 #)).
> exec "$(basename "${0}")" "$...@}"
>
> Or will it be a C wrapper to call b_sleep() in libcmd?
> (which if done right could also call any of the builtins,
> given a suitable hard or symbolic link; and might have
> faster startup than ksh93 itself)
Both implementations are possible - it could be implemented using a
wrapper script (like "alias.sh" links /usr/bin/ksh builtins like "kill"
to /usr/bin/kill) or directly calling the builtins via the |b_sleep()|
function (note that |b_sleep()| lives in libshell, not libcmd since this
is "core functionality" which is slightly more deeply connected with
shell internals than you may think at the first look).
The first solution has the advantage that there is the precedent of
/usr/bin/ksh already doing this stuff for it's builtins and that the
code would be quite small... the 2nd version has the advantage of being
faster and requiring less startup time (but would use a project-private
API where the usage needs to be ARC'ed somehow (AFAIK that's called
"contracted", right ?)).
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6451262 ("RFE:
Cyril Plisko wrote:
>
> On 9/1/07, Roland Mainz wrote:
> > "Richard L. Hamilton" wrote:
> >
> > > > This is a sponsor request to implement the RFE/CR
> > > > #6451262 ("RFE:
> > > > /usr/bin/sleep should support floating-point values"
> > > > -
>
> considering that /usr/gnu/bin/sleep already does that, how important
> it is to have yet another implementation of that feature ?
Some points:
- libshell.so.1 is likely going to be already loaded in the system at
the time someone calls the external application /usr/bin/sleep and
loading another extra binary (e.g. GNU sleep) would require extra time
and memory (see my previous comment about sub-second timing)
- GNU "sleep" lives in an optional package while both the current
implementation of /usr/bin/sleep and libshell.so.1 live in OS/Net. AFAIK
GNU "sleep" would need to be moved to OS/Net first or "sleep" moved out
of OS/Net somehow (which is tricky since some system scripts AFAIK
depend on "sleep")
- GNU "sleep" has extensions which would need to be implemented to
ksh93's "sleep" builtin first to ensure compatibity (and this needs to
be checked against the POSIX specs, e.g. whether 'm', 'h', 'd', 's' can
be applied as time units). However this may lead to a similar problem as
GNU "readlink" vs. ksh93 "readlink" (e.g. GNU "readlink" has extensions
which are not functional on all types of filesystems and IMHO therefore
won't be very welcome in a shell which has portabilty of it's script as
one of it's primary goals (which reminds me that I still own Stephen
Hahn an email to discuss how to get rid of GNU "readlink" from
/usr/bin/readlink)) which is already a big mess and I don't like to see
more of these problems in my ToDo list... ;-(
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] CR 4296835 xxxxx, Now responsible manager P4 network/internet-uti"in.rwhod" lacks usable configuration
jim.j.moore at sun.com wrote: > > *Synopsis*: "in.rwhod" lacks usable configuration > Due to a change of Responsible manager requested by x at sun.com, > x at sun.com is now the responsible manager for: > > CR 4296835 changed on Sep 3 2007 by x at sun.com > > === Field === New Value = === Old Value = > > Responsible Managerx at sun.com x at sun.com > Status 4-Defer 6-Fix Understood > SubStatus No Resource Available > > == === === Erm... why ? AFAIK I filed the sponsor request long ago and I just waiting that a sponsor somehow magically appears... the "resource" who writes the patch is available... Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6319768 ("Cannot execute JAR applications with setuid/setgid") ...
Hi!
This is a sponsor request to fix CR #6319768 ("Cannot execute JAR
applications with setuid/setgid"), preferably together with the patch
for
http://mail.opensolaris.org/pipermail/request-sponsor/2007-August/002741.html
since "shbinexec" and "javaexec" share similar concepts and code (e.g.
"shbinexec" was originally cloned from "javaexec", then
cleaned-up+fixed+adjusted to detect and run compiled shell code... and
the same work can be ported back to "javaexec").
My contributor ID is "OS0025".
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #5015982 ("*coreadm* should log core generation events by default") ...
Hi!
This is a sponsor request to fix CR #5015982 ("*coreadm* should log core
generation events by default") - AFAIK the fix should be easy since only
the coreadm defaults need to be updated.
My contributor ID is "OS0025".
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6600149 ("RFE: Cleanup bldenv a bit") ...
Hi!
This is a sponsor request to fix CR #6600149 ("RFE: Cleanup bldenv a
bit", e.g. minor script janitor/cleanup work...) ...
My contributor ID is "OS0025".
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6599659 ("RFE: Fix version propagation in OS/Net Makefiles") ...
Hi!
This is a sponsor request to fix CR #6599659 ("RFE: Fix version
propagation in OS/Net Makefiles", the issue was discussed during the
final ksh93-integration code review and forwarded to a seperate
bug+putback (e.g. this one))
My contributor ID is "OS0025".
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6599659("RFE: Fix version propagation in OS/Net Makefiles") ...
Peter Memishian wrote:
>
> > This is a sponsor request to fix CR #6599659 ("RFE: Fix version
> > propagation in OS/Net Makefiles", the issue was discussed during the
> > final ksh93-integration code review and forwarded to a seperate
> > bug+putback (e.g. this one))
> >
> > My contributor ID is "OS0025".
>
> I'll sponsor this.
Thanks! :-)
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6599668 ("RFE: Move consumers of alias.sh over to ksh93") ...
Hi!
This is a sponsor request to fix CR #6599668 ("RFE: Move consumers of
alias.sh over to ksh93"). The change should be more or less
straightforward and remove another chunk of items from the closed-bin
stuff.
My contributor ID is "OS0025".
Don: What needs to be done from an ARC point of view in this case ?
Existing /usr/bin/ksh scripts won't be affected (since they use the ksh
shell builtins anyway), leaving only external applications which use the
full paths to the consumers of "alias.sh" as possible "victims" of such
a case, e.g. /usr/bin/test (which would get new options and sub-second
timestamp support) and /usr/bin/kill (which would get the new "-n"
option).
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6601968 ("RFE: Add /usr/lib/shell/ksh/ as a place to store loadable shell functions") ...
Hi! This is a sponsor request to implement RFE/CR #6601968 (http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6601968 - "RFE: Add /usr/lib/shell/ksh/ as a place to store loadable shell functions" ; this RFE should be quite easy since it only proposes to create a directory hiearacy which is more or build like , e.g. /usr/lib/shell/ksh/org/opensolaris/net/http/ for shell functions related to HTTP protocol handling (this path would be added to the FPATH variable if a consumer wishes to use the functions)). My contributor ID is "OS0025". Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
[request-sponsor] 6626043: create_ramdisk could be faster
Dave Miner wrote:
> J?rgen Keil wrote:
> > "6626043 create_ramdisk could be faster" needs a sponsor;
> > my suggested performance enhancements can be found in the
> > workaround section of the bug:
> > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6626043
> >
> > My contributor agreement # is OS0003.
>
> I'll sponsor this fix.
Erm... are you interested in a cleanup patch, too ? I just did a quick
look at the script and saw some stuff which could be done better+faster
(most stuff is based on
http://www.opensolaris.org/os/project/shell/shellstyle/), e.g. (the list
is incomplete)
snip
[snip]
28 format=ufs
29 ALT_ROOT=
30 compress=yes
31 SPLIT=unknown
32 ERROR=0
33 dirsize32=0
34 dirsize64=0
Erm... typed variables may be nice (e.g. "integer dirsize=0" etc.) ...
35
36 BOOT_ARCHIVE=platform/i86pc/boot_archive
37 BOOT_ARCHIVE_64=platform/i86pc/amd64/boot_archive
38
39 export PATH=$PATH:/usr/sbin:/usr/bin:/sbin
AFAIK this is completely wrong. If $PATH gets added then it should be
after all the primary stuff, otherwise adding something "unexpected"
which supersets normal tools in /usr/bin/ may cause havoc...
BTW: The script needs to reset LC_NUMERIC to "C" to avoid that a locale
with a non-'.' decinal delimter blows the script up. AFAIK this sequence
should work:
-- snip --
if [[ "${LC_ALL}" != "" ]] ; then
export \
LC_MONETARY="${LC_ALL}" \
LC_MESSAGES="${LC_ALL}" \
LC_COLLATE="${LC_ALL}" \
LC_CTYPE="${LC_ALL}"
unset LC_ALL
fi
export LC_NUMERIC=C
-- snip --
40
41 #
42 # Parse options
43 #
44 while [ "$1" != "" ]
Please use [[ ]] instead of [ ] ... or maybe even better ks93's version
of "getopts" ...
45 do
46 case $1 in
47 -R) shift
48 ALT_ROOT="$1"
49 if [ "$ALT_ROOT" != "/" ]; then
50 echo "Creating ram disk for $ALT_ROOT"
51 fi
52 ;;
53 -n|--nocompress) compress=no
54 ;;
55 *) echo Usage: ${0##*/}: [-R \]
[--nocompress]
56 exit
57 ;;
58 esac
59 shift
60 done
61
62 if [ -x /usr/bin/mkisofs -o -x /tmp/bfubin/mkisofs ] ; then
[[ -x /usr/bin/mkisofs || -x /tmp/bfubin/mkisofs ]] may be better...
63 format=isofs
64 fi
65
66 #
67 # mkisofs on s8 doesn't support functionality used by GRUB boot.
68 # Use ufs format for boot archive instead.
69 #
70 release=`uname -r`
Please use POSIX syntax, e.g. release="$(uname -r")
71 if [ "$release" = "5.8" ]; then
72 format=ufs
73 fi
74
75 shift `expr $OPTIND - 1`
Please use builtin math, e.g. shift $((OPTIND - 1))
76
77 if [ $# -eq 1 ]; then
Please use arthmetric expressions for ksh scripts, e.g.
-- snip --
if (( $# == 1 )); then
-- snip --
78 ALT_ROOT="$1"
79 echo "Creating ram disk for $ALT_ROOT"
Please use "print", not "echo" (or maybe...
-- snip --
printf "Creating ram disk for %s\n" "$ALT_ROOT"
-- snip --
... is better...
80 fi
81
82 rundir=`dirname $0`
Please use POSIX shell syntax, e.g.
-- snip --
rundir="$(dirname "$0")"
[snip - endless bickering removed]
109 function getsize
110 {
111 # Estimate image size and add 10% overhead for ufs stuff.
112 # Note, we can't use du here in case we're on a filesystem,
e.g. zfs,
113 # in which the disk usage is less than the sum of the file
sizes.
114 # The nawk code
115 #
116 # {t += ($5 % 1024) ? (int($5 / 1024) + 1) * 1024 : $5}
117 #
118 # below rounds up the size of a file/directory, in bytes, to
the
119 # next multiple of 1024. This mimics the behavior of ufs
especially
120 # with directories. This results in a total size that's
slightly
121 # bigger than if du was called on a ufs directory.
122 size32=$(cat "$list32" | xargs -I {} ls -lLd "{}" | nawk '
123 {t += ($5 % 1024) ? (int($5 / 1024) + 1) * 1024 : $5}
124 END {print int(t * 1.10 / 1024)}')
125 (( size32 += dirsize32 ))
126 size64=$(cat "$list64" | xargs -I {} ls -lLd "{}" | nawk '
127 {t += ($5 % 1024) ? (int($5 / 1024) + 1) * 1024 : $5}
128 END {print int(t * 1.10 / 1024)}')
129 (( size64 += dirsize64 ))
130 (( total_size = size32 + size64 ))
Erm... AFAIK the use of xargs/nawk/etc. could be replaced by ksh93
builtin math...
131 }
132
133 #
134 # Copies all desired files to a target directory. One argument
should be
135 # passed: the file containing the list of files to copy. T
[request-sponsor] 6626043: create_ramdisk could be faster
Jan Setje-Eilers wrote:
> > 35
> > 36 BOOT_ARCHIVE=platform/i86pc/boot_archive
> > 37 BOOT_ARCHIVE_64=platform/i86pc/amd64/boot_archive
> > 38
> > 39 export PATH=$PATH:/usr/sbin:/usr/bin:/sbin
> >
> > AFAIK this is completely wrong. If $PATH gets added then it should be
> > after all the primary stuff, otherwise adding something "unexpected"
> > which supersets normal tools in /usr/bin/ may cause havoc...
>
> It's a misguided attempt to work around bfu being more than a bit of
> a mess in that respect. This has been changed to explicitly check for
> and pick up tmp/bfubin:
>
> if [ "`echo $PATH | cut -f 1 -d :`" = /tmp/bfubin ] && \
> [ -O /tmp/bfubin ] ; then
> export PATH=/tmp/bfubin:/usr/sbin:/usr/bin:/sbin
What is the expected content of $PATH if this contidion is "true" ?
AFAIK the same could be expressed via...
-- snip --
if [[ "${PATH}" = ~(El)/tmp/bfubin.* && -O "/tmp/bfubin" ]] ; then
-- snip --
(the ~(E) means "use egrep pattern instead of shell pattern" and the 'l'
is a modier which says "left anchor")
> else
> export PATH=/usr/sbin:/usr/bin:/sbin
> fi
>
> That change will go back with the new-boot sparc wad.
Will you keep the script or are you going to replace it with an all-new
script ?
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6551714 ("/lib/svc/method/net-routing-setup doesn't get along with ksh93=/sbin/sh")
Hi!
Requesting sponsor for CR #6551714 ("/lib/svc/method/net-routing-setup
doesn't get along with ksh93=/sbin/sh"). The prototype patch v2 is
attached as lib_svc_method_routing_setup_posix002.diff.txt ...
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
-- next part --
--- /lib/svc/method/net-routing-setup.orig Thu May 3 18:59:52 2007
+++ /lib/svc/method/net-routing-setup Thu May 3 18:59:52 2007
@@ -136,9 +136,11 @@
#
do_delete=yes
for router in $defrouters; do
- set -- `/usr/sbin/route -n add default \
+ route_added=`/usr/sbin/route -n add default \
-gateway $router`
- [ $? -ne 0 -a "x$5" = "x$route_IP:" ] \
+res=$?
+set -- ${route_added}
+ [ ${res} -ne 0 -a "x$5" = "x$route_IP:" ] \
&& do_delete=no
done
[request-sponsor] Requesting sponsor for CR #6540117 ("Debug buildof libc should be compiled with -xstrconst") ...
Roland Mainz wrote:
> Requesting sponsor for CR #6540117 ("Debug build of libc should be
> compiled with -xstrconst") ...
Uhm... ping! Are there any volunteers for such a work ?
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Re: Requesting sponsor for CR #6551714
Alan Maguire wrote:
> ("/lib/svc/method/net-routing-setup
> In-Reply-To: <464107F6.DBD1BFE4 at nrubsig.org>
[snip]
>
> i'll sponsor this,
Thanks! :-)
> let's discuss it offline.
Ok...
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6540117 ("Debug buildof libc should be compiled with -xstrconst") ...
Craig Mohrman wrote:
> >Roland Mainz wrote:
> >> Requesting sponsor for CR #6540117 ("Debug build of libc should be
> >> compiled with -xstrconst") ...
> >
> >Uhm... ping! Are there any volunteers for such a work ?
>
> I'll take this.
_Thanks!_ ... :-)
... I've attached a prototype patch
("os_net_use_xstrconst_for_debug_libc_libnsl_libsocket_001.diff.txt")
which does the job for libc, libnsl and libsocket (I filed a seperate
RFE for libnsl+libsocket tonight).
I ran a couple of tests on x86 (including booting, shutdown, building
OS/Net, FireFox (and Mozilla/FireFox's automated test suite), CDE,
StarOffice and ksh93's test suite) and found no crashes (note that any
writes to string literals will result in a SIGSEGV (e.g. the states are
eiteh "working" xor "SIGSEGV" (unless an application does some fancy
stuff and traps this signal)), therefore any applications which depend
on such a thing will be easily detectable via looking at
/var/adm/messages if "coreadm" is enabled (e.g. (as "root") # mkdir
/var/core ; coreadm -g /var/core/core.%f.%p -e global -e process -e log
-e global-setid #) ... maybe we should write a heads-up and put that
information into that text...).
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
-- next part --
Index: src/lib/libsocket/Makefile.com
===
--- src/lib/libsocket/Makefile.com (revision 694)
+++ src/lib/libsocket/Makefile.com (working copy)
@@ -45,6 +45,12 @@
LIBS = $(DYNLIB) $(LINTLIB)
SRCS = $(INETOBJS:%.o=../inet/%.c) $(SOCKOBJS:%.o=../socket/%.c)
+
+# Make string literals read-only to save memory. Currently only done for debug
+# builds until the change had enough time to "bake" in the tree.
+$(NOT_RELEASE_BUILD)CFLAGS += -xstrconst
+$(NOT_RELEASE_BUILD)CFLAGS64 += -xstrconst
+
LDLIBS += -lnsl -lc
SRCDIR = ../common
Index: src/lib/libnsl/Makefile.com
===
--- src/lib/libnsl/Makefile.com (revision 694)
+++ src/lib/libnsl/Makefile.com (working copy)
@@ -200,6 +200,11 @@
CCFLAGS += $(NOEXCEPTIONS)
CCFLAGS64 += $(NOEXCEPTIONS)
+# Make string literals read-only to save memory. Currently only done for debug
+# builds until the change had enough time to "bake" in the tree.
+$(NOT_RELEASE_BUILD)CFLAGS += -xstrconst
+$(NOT_RELEASE_BUILD)CFLAGS64 += -xstrconst
+
CPPFLAGS +=-I$(SRC)/lib/common/inc -I$(SRC)/lib/libnsl/include -D_REENTRANT
CPPFLAGS +=-I$(SRC)/lib/libnsl/dial
Index: src/lib/libc/sparcv9/Makefile
===
--- src/lib/libc/sparcv9/Makefile (revision 702)
+++ src/lib/libc/sparcv9/Makefile (working copy)
@@ -923,6 +923,10 @@
CFLAGS64 += $(THREAD_DEBUG)
+# Make string literals read-only to save memory. Currently only done for debug
+# builds until the change had enough time to "bake" in the tree.
+$(NOT_RELEASE_BUILD)CFLAGS64 += -xstrconst
+
ALTPICS= $(TRACEOBJS:%=pics/%)
$(DYNLIB) := PICS += $(ROOTFS_LIBDIR64)/libc_i18n.a
Index: src/lib/libc/sparc/Makefile
===
--- src/lib/libc/sparc/Makefile (revision 694)
+++ src/lib/libc/sparc/Makefile (working copy)
@@ -979,6 +979,10 @@
CFLAGS += $(THREAD_DEBUG)
+# Make string literals read-only to save memory. Currently only done for debug
+# builds until the change had enough time to "bake" in the tree.
+$(NOT_RELEASE_BUILD)CFLAGS += -xstrconst
+
ALTPICS= $(TRACEOBJS:%=pics/%)
$(DYNLIB) := PICS += $(ROOTFS_LIBDIR)/libc_i18n.a
Index: src/lib/libc/i386/Makefile.com
===
--- src/lib/libc/i386/Makefile.com (revision 694)
+++ src/lib/libc/i386/Makefile.com (working copy)
@@ -959,6 +959,10 @@
CFLAGS += $(THREAD_DEBUG)
+# Make string literals read-only to save memory. Currently only done for debug
+# builds until the change had enough time to "bake" in the tree.
+$(NOT_RELEASE_BUILD)CFLAGS += -xstrconst
+
ALTPICS= $(TRACEOBJS:%=pics/%)
$(DYNLIB) := PICS += $(ROOTFS_LIBDIR)/libc_i18n.a
Index: src/lib/libc/amd64/Makefile
===
--- src/lib/libc/amd64/Makefile (revision 702)
+++ src/lib/libc/amd64/Makefile (working copy)
@@ -915,6 +915,10 @@
CFLAGS64 += $(THREAD_DEBUG)
+# Make string literals read-only to save memory. Currently only done for debug
+# builds until the change had enough time to "bake" in the tree.
+$(NOT_RELEASE_BUILD)CFLAGS64 += -xstrconst
+
ALTPICS= $(TRACEOBJS:%=pics/%)
$(DYNLIB) := PICS += $(ROOTFS_LIBDIR64)/libc_i18n.a
[request-sponsor] Seeking sponsor for CR #6540124 ("RFE: OS/Net build could be slightly more portable")
Hi!
Requesting sponsor for CR #6540124 ("RFE: OS/Net build could be slightly
more portable"). The patch is attached in a bug...
... Alan: Would you be interested to sponor the fix ? Most of the patch
affects your territory...
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR #6540117 ("Debug build of libc should be compiled with -xstrconst") ...
Hi!
Requesting sponsor for CR #6540117 ("Debug build of libc should be
compiled with -xstrconst") ...
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Seeking sponsor for CR #6540124 ("RFE: OS/Netbuild could be slightly more portable")
Roland Mainz wrote:
> Requesting sponsor for CR #6540124 ("RFE: OS/Net build could be slightly
> more portable"). The patch is attached in a bug...
>
> ... Alan: Would you be interested to sponor the fix ? Most of the patch
> affects your territory...
Ok... Garrett D'Amore volunters as "code reviewer"
...
... which means I only need a "sponsor" and Alan Burlison's "blessing"
for the patch...
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Requesting spondor for bug #6514842 ('"in.rwhod" lacks useable configuration')
Hi!
This is a sponsor request for the fix for bug #6514842 ('"in.rwhod"
lacks useable configuration').
My proposed "fix" would include a SMF manifest for "in.rwhod", a
matching start script and a small modification to the package system to
create /var/spool/rwho/ ...
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Requesting spondor for bug #6514842 ('"in.rwhod"lacks useable configuration')
David.Comay at Sun.COM wrote:
> > This is a sponsor request for the fix for bug #6514842 ('"in.rwhod"
> > lacks useable configuration').
> >
> > My proposed "fix" would include a SMF manifest for "in.rwhod", a
> > matching start script and a small modification to the package system to
> > create /var/spool/rwho/ ...
>
> Just a note that 6514842 has been closed as a duplicate of
>
> 4296835 "in.rwhod" lacks usable configuration
>
> All of the relevant information from 6514842 has been moved to
> 4296835.
Ok... then I request a sponsor for bug #4296835 ...
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Requesting sponsor for bug #6516767 ('RFE: /etc/profile should set ${MANPATH} to a ${PATH}/${LANG}-related value')
Hi!
This is a sponsor request for the fix for bug #6516767 ('RFE:
/etc/profile should set ${MANPATH} to a ${PATH}/${LANG}-related value').
The proposed fix is described in the bug report including example
code...
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR# 6488593 ("/etc/profile should set TMPDIR to /tmp/$LOGNAME/") ...
Hi!
Requesting sponsor for CR# 6488593 ("/etc/profile should set TMPDIR to
/tmp/$LOGNAME/") - patch is included in the RFE...
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR# 6488593("/etc/profileshould set TMPDIR to /tmp/$LOGNAME/") ...
Bart Smaalders wrote:
> Darren J Moffat wrote:
> > Roland Mainz wrote:
> >> Requesting sponsor for CR# 6488593 ("/etc/profile should set TMPDIR to
> >> /tmp/$LOGNAME/") - patch is included in the RFE...
> >
> > This will I believe need an ARC case since it is a change in default
> > behaviour. It also should be done for all shells not just ones
> > that read /etc/profile.
> >
> > Since I do this myself in my own .profile I feel duty bound to stand up
> > to the plate and by your sponsor for this. So sign me up for putback
> > sponsor and I'll be ARC case submitter too.
> >
>
> Good idea (I use this myself :-)). Should the directory be created
> 700 by default?
Definately "no". The idea is to improve "usuabilty" and not "security".
AFAIK the best mode is "rwx" for "ugo" and then +t, e.g. the same mode
used by default for /tmp itself (otherwise "funny" things with
setuid/setgid/role scripts may happen which may not expect this kind of
change). Anyone who wants to "tighten" the mode of the /tmp/${LOGNAME}/
directory should do this in ~/.profile ...
Bye,
Roland
P.S.: Setting Reply-To: to shell-discuss at opensolaris.org
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR# 6488593("/etc/profile should set TMPDIR to /tmp/$LOGNAME/") ...
Casper.Dik at sun.com wrote:
> >Darren J Moffat wrote:
> >> Roland Mainz wrote:
> >>> Requesting sponsor for CR# 6488593 ("/etc/profile should set TMPDIR to
> >>> /tmp/$LOGNAME/") - patch is included in the RFE...
> >>
> >> This will I believe need an ARC case since it is a change in default
> >> behaviour. It also should be done for all shells not just ones
> >> that read /etc/profile.
> >>
> >> Since I do this myself in my own .profile I feel duty bound to stand up
> >> to the plate and by your sponsor for this. So sign me up for putback
> >> sponsor and I'll be ARC case submitter too.
> >>
> >
> >Good idea (I use this myself :-)). Should the directory be created
> >700 by default?
>
> There's a risk in setting $TMPDIR and making it mode 700; the risk
> is that programs started under a different uid may start to fail.
>
> But it should either by mode 1777 (to mitigate that risk) or 700
> for privacy.
Default should be the same mode as /tmp - the idea is that users do not
have to dig through zillon files to find "their" temp. files on a large
multiuser machine.
Quick check on our "grendel" (which wasn't "updated" with our custom
/etc/profile mods after last months update to Solaris 10):
$ ls -l /tmp | wc -l
6187
Fun... ;-(
Bye,
Roland
P.S.: Setting Reply-To: to shell-discuss at opensolaris.org
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR# 6488593("/etc/profile should set TMPDIR to /tmp/$LOGNAME/") ...
Darren J Moffat wrote: > Casper.Dik at Sun.COM wrote: > >>> Since I do this myself in my own .profile I feel duty bound to stand up > >>> to the plate and by your sponsor for this. So sign me up for putback > >>> sponsor and I'll be ARC case submitter too. > >>> > >> Good idea (I use this myself :-)). Should the directory be created > >> 700 by default? > > > > There's a risk in setting $TMPDIR and making it mode 700; the risk > > is that programs started under a different uid may start to fail. > > pkgadd is one of those programs. > > > But it should either by mode 1777 (to mitigate that risk) or 700 > > for privacy. > > Or honour the umask ? Please "no" (default should be identical to the default mode of "/tmp"). Users who wish to do that can simply use "chmod" in their ~/.profile (AFAIK there isn't an exploitable gap because users already own the dir on creation). bye, Roland P.S.: Reply-To: set to shell-discuss at opensolaris.org -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
pkgadd failure / was: Re: [request-sponsor] Requesting sponsor for CR# 6488593("/etc/profile should set TMPDIR to /tmp/$LOGNAME/") ...
Dave Miner wrote: > Casper.Dik at Sun.COM wrote: > >> Darren J Moffat wrote: > >>> Roland Mainz wrote: [snip] > >> Good idea (I use this myself :-)). Should the directory be created > >> 700 by default? > > > > There's a risk in setting $TMPDIR and making it mode 700; the risk > > is that programs started under a different uid may start to fail. > > > > Yeah, you'll notice that if you try to su to root and run installers > that run pkgadd internally. I use this method, and the StarOffice 8 > installer failed quite mysteriously until I realized it was just an > instance of that problem and reset TMPDIR to something else. Is there any bug yet to add a simple check to "pkgadd" to catch this kind of mistake early ? Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
[request-sponsor] Requesting sponsor for CR# 6488593("/etc/profile should set TMPDIR to /tmp/$LOGNAME/") ...
Casper.Dik at Sun.COM wrote: > > >Yeah, you'll notice that if you try to su to root and run installers > >that run pkgadd internally. I use this method, and the StarOffice 8 > >installer failed quite mysteriously until I realized it was just an > >instance of that problem and reset TMPDIR to something else. > > This, unfortunately, kills the whole idea in my mind. > (I vaguely remembered similar issues from the past) Why ? the whole idea is about "usuablity" and not "security" (see my other postings) ... Bye, Roland P.S.: Reply-To: set to shell-discuss at opensolaris.org -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
[shell-discuss] Re: [request-sponsor] Requesting sponsor for CR#6488593("/etc/profile should set TMPDIR to /tmp/$LOGNAME/") ...
Peter Tribble wrote: > I regard this as unsafe and undesirable *as a default*. It clutters up > /tmp with unnecessary directories, wastes memory and involves > extra code at login. I have no problem with administrators or > users doing it if they want, but I see no advantage to having it as > the default behaviour. I disagree. The flat layout in /tmp for all temporary files of all users is very very annoying for both admins and users. I doubt mode 1777 is "insecure" (yes, you can always craft a case where it goes wrong...). Remember this is about "usuability". Currently /tmp on large multiuser machine looks like a giant trashcan... > What is the mechanism for the community to comment on > these sorts of cases? Presumably it has to go for ARC review, > but how does one find out what cases exist, when they're up for > review, and how does one particpate in the review process? > (Particularly as a community member who might only be interested > in a small number of cases.) Uhm... there is arc-discuss at opensolaris.org for such discussions... and the related project lists (e.g. shell-discuss at opensolaris.org). > On 11/4/06, Roland Mainz wrote: > > > > Default should be the same mode as /tmp - the idea is that > > users do not > > have to dig through zillon files to find "their" temp. files > > on a large > > multiuser machine. > Why would users be manually groping through /tmp? To find their files... ? > > Quick check on our "grendel" (which wasn't "updated" with > > our custom > > /etc/profile mods after last months update to Solaris 10): > > $ ls -l /tmp | wc -l > >6187 > > Fun... ;-( > > Instead of which we will (presumably) have thousands of empty > directories > to sift through, one for each user who ever logged in. And the > associated > unnecessary memory use. What is the difference between tenthousand files created by various users ? IMO that argument is for /dev/null ... > (As an aside, how many directories can you create in /tmp?) The same number of files which can be there - the limit is AFAIK only the memory/swap, calculated based on some kernel tuneable... Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
About "6414843 SUNWonbld shouldn't install sgml man pages" / was: Re: [request-sponsor] Many SUNWonbld related fixes
Rainer Orth wrote: > 6414843 SUNWonbld shouldn't install sgml man pages What is your intended fix ? IMO Solaris should finally switch to DocBook/(SGML|XML) manual pages for all tools if possible, therefore it may be nice to simply move the manual page to sman1/ and avoid the conversion to the old troff format... Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
libast.so and /usr/lib/extendedFILE.so / was: Re: [request-sponsor] telnet(1) cannot handle more than 15 fds
Casper.Dik at Sun.COM wrote: > >Due to the 32-bit ABI's stdio file descriptor limit, an interposer is > >being used to F_DUPFD non-stdio file descriptors to 256 and above. This > >mitigates a problem with 3rd party modules and plugins that use > >fopen(3C), et al. streams in processes such as Apache HTTP Server that > >open a large number of file descriptors. Unfortunately, using the > >interposer causes failures when a child process (e.g. CGI program) > >subsequently invokes telnet(1). If telnet passed the correct nfds value > >to select(3C), that failure would be eliminated. > > In build 39 of Nevada we provide a standard interposer, > /usr/lib/extendedFILE.so, which has a similar, but different property. Umpf... for the same reason we were thinking about making the stdio-replacement API in libast public since it it supports an almost unlimited number of stdio channels... Bye, Roland P.S.: Reply-To: set to ksh93-integration-discuss at opensolaris.org as this is more or less libast-related -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
[request-sponsor] telnet(1) cannot handle more than 15 fds
Chris Elving wrote: > James Carlson wrote: > > But the bigger question is why this is needed. It'd have to be some > > situation in which telnet was exec'd with the first 16 descriptors > > already open. Does that happen? > > Due to the 32-bit ABI's stdio file descriptor limit, an interposer is > being used to F_DUPFD non-stdio file descriptors to 256 and above. You may want to look at the ksh93 integration then which includes libast. libast has a stdio replacement (sort of drop-in) which supports an almost unlimited number of stdio channels... Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
[request-sponsor] Seeking sponsor for CR #6452094 ("An interactive bash shell should source /etc/bash.bashrc")
Hi! This is a sponsor request to implement support for http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6452094 which requests the addition of /etc/bash.bashrc and /etc/bash.bash_logout to be in sync with the same set of features introduced to ksh with ksh93. Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
[request-sponsor] Re: RFE4940735: grep -r
William Hathaway wrote:
> Bonnie Corwin wrote:
> > William D. Hathaway wrote On 08/10/06 08:50,:
> >
> >> Is there any update on this? The ARC 2005/049 case has
> >> PSARC 2005/049 FastTrack Add ggrep context and recursive
> >> search fclosed approved fast-track 02/02/2005
> >
> > The fasttrack was approved, but the engineer got pulled off this to
> > address higher-priority work.
> >
> > Cyndy Eastham is willing to sponsor you if you are interested in working
> > on the implementation. Is that a possibility?
>
> Sure, I'd be happy to work on it.
Please make sure you cover BOTH /usr/bin/grep and /usr/xpg4/bin/grep,
otherwise it's getting a little bit annoying for those who have
/usr/xpg4/bin by default in their ${PATH} ...
... and feel free to ask me or the people in
shell-discuss at opensolaris.org for review... :-)
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
About "6414843 SUNWonbld shouldn't install sgml man pages" / was: Re: [request-sponsor] Many SUNWonbld related fixes
Rainer Orth wrote: > Roland Mainz writes: > > Rainer Orth wrote: > > > 6414843 SUNWonbld shouldn't install sgml man pages > > > > What is your intended fix ? IMO Solaris should finally switch to > > DocBook/(SGML|XML) manual pages for all tools if possible, therefore it > > may be nice to simply move the manual page to sman1/ and avoid the > > conversion to the old troff format... > > My current plan is to convert the few SGML man pages in SUNWonbld to nroff > on the fly and install those to avoid having two different man page formats > in a single package. Umpf... that's actually reverse of the way how it should be done.. ... about how many manual pages are we talking here ? One ? Three ? 20 ? I may be able to convert 1-3 by hand if we get rid of the xx@@@!!-"nroff" workaround... > Once the other man pages with nroff source have been converted to SGML, > that can be revised. > > It may be worthwhile to consider what to do with the man pages in SUNWman, > btw. For some time, they were delivered in SGML format, but later the > package switched back to delivering the nroff form generated from that > only. I think that was done because some of the necessary tools were not > easily/publicly available, but I recall that this has changed/is changing > in the Documentation community. But that's certainly much better to > discuss on docs-discuss. Erm... AFAIK the tools were available since a long time. The SolBook DTD isn't very different from DocBook and smaller items can be done by hand... Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
[request-sponsor] [ksh93-integration-discuss] Transfer ofsponsorship for ksh93 update 2 CRs
Bonnie Corwin wrote:
> On 09/18/09 07:01 AM, Milan Jurik wrote:
> > FYI, John Sonnenschein took over sponsorship for ksh93 update 2
> > (Contributor Roland Mainz). The list of sponsored CRs from this update
> > 2:
> >
> > 6605478 ksh93 profile shell option does not work
> > 6705126 first call to read doesn't honor new setting of HISTFILE
> > 6764665 *libpp* Array overrun in libpp
> > 6765756 *libast* Array overruns in libast
> > 6769332 Recursive function+command substitutions terminate shell after
> > 257 iterations
> > 6778077 *ksh93* does not understand "THAW" as a signal for use with trap
> > 6789247 [ku1] libast/ksh93 1-digit hexfloat base conversion rounds
> > incorrectly
> > 6791838 *ksh93* unset of a variable which is not set should return 0
> > 6793714 RFE: Update /usr/bin/comm to AT&T AST "comm"
> > 6793719 RFE: Update /usr/bin/cut to AT&T AST "cut"
> > 6793721 RFE: Update /usr/bin/paste to AT&T AST "paste"
> > 6793722 RFE: Update /usr/bin/cmp to AT&T AST "cmp"
> > 6793726 RFE: Update /usr/bin/uniq to AT&T AST "uniq"
> > 6793735 RFE: Update /usr/bin/wc to AT&T AST "wc"
> > 6793744 RFE: Add /usr/share/doc/ksh/ for ksh93 documentation
> > 6793747 RFE: Provide "print" builtin as /usr/bin/print for external
> > applications
> > 6793763 RFE: Update /usr/bin/ksh93 to ast-ksh.2009-05-05
> > 6794952 RFE: Enable "globstar" mode in /etc/ksh.kshrc (= interactive
> > ksh93 shells)
> > 6805792 [ku1] Moving local compound var into array does not work
> > 6805794 [ku1] printf returns "invalid character constant" for $ printf
> > "%d\n" "'"
> > 6805795 [ku1] ksh93 does not differ between -0 and +0
> > 6805797 [ku1]Can't append to nodes of an array of compound vars if
> > addressing them via nameref
> > 6805799 Indexed compound variable arrays do not work...
> > 6805800 [ku1] Declaring associative compound array does not work
> > 6805812 RFE: Update /usr/bin/head to AT&T AST "head".
> > 6805813 RFE: Update /usr/bin/join to AT&T AST "join".
> > 6805814 RFE: Update /usr/bin/mkfifo to AT&T AST "mkfifo".
> > 6805819 RFE: Update /usr/bin/tee to AT&T AST "tee".
> > 6809663 shlint missing ending newline on errors
> > 6811916 ksh93 repeatedly seg faults when "tee" builtin is interupted via
> > in inteactive mode
> > 6821113 SUNWosdem package issues
> > 6828644 RFE: Update /usr/bin/logname to AT&T AST "logname".
> > 6828692 RFE: Update /usr/bin/cksum to AT&T AST "cksum".
> > 6834184 ksh93 gets SIGSEGV if HISTFILE is changed in place.
> > 6834207 ksh93 gets SIGSEGV on interactive function definition with
> > HISTSIZE unset
> > 6835835 ksh93 "cat" builtin does not handle "-n" correctly
> > 6848486 "echo ${test}" with test undefined crashes the shell
> > 6850672 ksh93 (VISUAL=vi) crashes with memory fault while scrolling
> > through history
> > 6855875 typeset -X x ; print $x # does not print sufficient digits to
> > restore value
> >
> >
> > I will stay around, helping to minimize impact of transfer.
>
> Thanks for the update. Tables updated.
Thanks! ...
... for the log: We've updated the project's codebase to kill three more
bugs:
-- snip --
6857344 /usr/bin/hash core dump with invalid arguments
6866676 Need test suite module to test the kernel support for compiled
shell scripts
6881017 Subshell doesn't exit, holds pipe open preventing callers from
exiting
-- snip --
Additonally CR #6877392 ("ksh93 regresses uniq performance") should be
fixed now (BTW: Can someone update the title to "ksh93 regresses 'uniq
-c' performance", please ? It was only the "-c" option which caused
trouble, in the normal mode the new "uniq" implementation both
outperformed the old "uniq" implementation and the GNU coreutils one...)
but we have to wait for the perf team to officially confirm this...
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
