Re: [i18n-discuss] Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

I've checked the behaviour on s10u4_05 and have filed a bug "6548326 texttools from /usr/bin cannot work correctly in UTF-8 locales". The behaviour is still the same. Alexander Kuzmin James Carlson napsal(a): Alexander Kuzmin writes: Because int this case it would be probably closed as a d

Re: Packaging issues - was Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

Bart Smaalders writes: > Darren J Moffat wrote: > > Bart Smaalders wrote: > >> Packages should represent a minimization boundary; e.g. they > >> are either installed or not installed depending on the > >> proposed use of the system. > >> > >> Solaris has areas where packages are too fine-grained, >

Re: Packaging issues - was Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

Darren J Moffat wrote: Bart Smaalders wrote: Packages should represent a minimization boundary; e.g. they are either installed or not installed depending on the proposed use of the system. Solaris has areas where packages are too fine-grained, it also has areas where the packages are much too l

Re: Packaging issues - was Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

Bart Smaalders wrote: Packages should represent a minimization boundary; e.g. they are either installed or not installed depending on the proposed use of the system. Solaris has areas where packages are too fine-grained, it also has areas where the packages are much too large to be useful in thi

Re: Packaging issues - was Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

Peter Tribble wrote: On 4/11/07, John Plocher <[EMAIL PROTECTED]> wrote: Or, looking at it the other way, packages map to the output of an independent, distributed development team. They are the ultimate "consolidation" boundary - everything within a package is delivered together as a unit and

Re: Packaging issues - was Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

On 4/11/07, John Plocher <[EMAIL PROTECTED]> wrote: Peter Tribble wrote: > No, we have far too many packages. And I still stand by this statement. As background for anyone wishing to address this perceived problem, the theory goes like this: Developers develop features by writing source

Re: [i18n-discuss] Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

James Carlson a écrit : > Please be specific, and file a bug. What system script has that > problem? I'm going to chime in on that particular part of your answer, as a French user who has reported locale-related bugs many times. As a rule, Sun support does not give a damn about my bugs affecting

Re: [i18n-discuss] Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

Hi Laurent, As a rule, Sun support does not give a damn about my bugs affecting non-C locales. They usually get closed as «Will not fix», with no explanation. Without me being even informed they were closed, actually. I tried to search for bugs that you submitted on bugs.opensolaris.org as

Re: [i18n-discuss] Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

Alexander Kuzmin writes: > Because int this case it would be probably closed as a duplicate of this > solved problem. If you think that's an incorrect procedure, I'll file a > new CR and can cite you in the comments, in case the bug gets closed as > a duplicate. Please do. Having multiple putb

Re: [i18n-discuss] Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

Because int this case it would be probably closed as a duplicate of this solved problem. If you think that's an incorrect procedure, I'll file a new CR and can cite you in the comments, in case the bug gets closed as a duplicate. James Carlson napsal(a): Alexander Kuzmin writes: No, that's

Re: [i18n-discuss] Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

Alexander Kuzmin writes: > No, that's exactly the issue seen 12 years ago. I've opened an MR for a > different Solaris release - that's the correct procedure that ensures > that the bug history on the original release can be easily followed. I strongly disagree. The problem was fixed. We shoul

Re: [i18n-discuss] Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

No, that's exactly the issue seen 12 years ago. I've opened an MR for a different Solaris release - that's the correct procedure that ensures that the bug history on the original release can be easily followed. James Carlson napsal(a): Alexander Kuzmin writes: One example is here: *1200693

Re: [i18n-discuss] Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

Alexander Kuzmin writes: > One example is here: > *1200693-2140649 /usr/bin/tr and /usr/xpg4/bin/tr still don't work > correctly in UTF-8 locale This looks to me like an incorrect usage of the bug tracking system. 1200693 was closed 12 years ago in Solaris 2.5. If there's a problem here, the pro

Re: [i18n-discuss] Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

One example is here: *1200693-2140649 /usr/bin/tr and /usr/xpg4/bin/tr still don't work correctly in UTF-8 locale * Bart Smaalders napsal(a): I. Szczesniak wrote: Ask yourself: What will happen if a system script encounters a file name with multibyt

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

I like it the way it is. I routinely deliberately install SUNWxcu4. I routinely deliberately use some of the xpg4 binaries. I share James Carlson's lack of understanding into the problem. But then I'm a native US English speaker and basically never have to deal with i18n except for message catalo

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

I. Szczesniak wrote: Ask yourself: What will happen if a system script encounters a file name with multibyte characters. Well, mostly they just work. Sometimes there are bugs, just as there are bugs when filenames have spaces in them. Do you have a specific example of a problem? - Bart --

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

I. Szczesniak writes: > On 4/11/07, James Carlson <[EMAIL PROTECTED]> wrote: > > I'm confused. They *do* have the same level of support. Can you > > explain why you think they're supported differently? > > SUNWxcu4 is a separate package which is IMO wrong. The package should > be merged into SUN

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

On 4/11/07, James Carlson <[EMAIL PROTECTED]> wrote: I. Szczesniak writes: > On 4/11/07, James Carlson <[EMAIL PROTECTED]> wrote: > > I. Szczesniak writes: > > > I explained this in another mail. Our statistics show that lots of > > > customers do not have SUNWxcu4 installed. The system scripts d

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

>Peter C. Norton wrote: >> On Wed, Apr 11, 2007 at 01:36:59PM -0500, Shawn Walker wrote: >>> On 11/04/07, I. Szczesniak <[EMAIL PROTECTED]> wrote: I don't think this will happen without a major shift to a more customer-friendly policy at Sun. >>> When is "break my customer's stuff" seen

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

Peter C. Norton wrote: On Wed, Apr 11, 2007 at 01:36:59PM -0500, Shawn Walker wrote: On 11/04/07, I. Szczesniak <[EMAIL PROTECTED]> wrote: I don't think this will happen without a major shift to a more customer-friendly policy at Sun. When is "break my customer's stuff" seen as friendly? Can

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

On Wed, Apr 11, 2007 at 01:36:59PM -0500, Shawn Walker wrote: > On 11/04/07, I. Szczesniak <[EMAIL PROTECTED]> wrote: > >I don't think this will happen without a major shift to a more > >customer-friendly policy at Sun. > > When is "break my customer's stuff" seen as friendly? Can you quantify:

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

Hi, On st, 2007-04-11 at 22:38, Peter Tribble wrote: > On 4/11/07, Bart Smaalders <[EMAIL PROTECTED]> wrote: > > Peter Tribble wrote: > > > I like the second idea - remove the package entirely and make sure > > > the files are always available under any conditions. > > > > > > (One could also ask

Packaging issues - was Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

Peter Tribble wrote: No, we have far too many packages. As background for anyone wishing to address this perceived problem, the theory goes like this: Developers develop features by writing source code. Features evolve at different rates, have different resources available and are

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

On 4/11/07, Bart Smaalders <[EMAIL PROTECTED]> wrote: Peter Tribble wrote: > I like the second idea - remove the package entirely and make sure > the files are always available under any conditions. > > (One could also ask why SUNWesu is a separate package.) > I was under the impression that man

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

On 11/04/07, I. Szczesniak <[EMAIL PROTECTED]> wrote: I don't think this will happen without a major shift to a more customer-friendly policy at Sun. When is "break my customer's stuff" seen as friendly? -- "Less is only more where more is no good." --Frank Lloyd Wright Shawn Walker, Software

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

On Wed, Apr 11, 2007 at 07:37:11PM +0200, Bart Blanquart wrote: > Claiming that incompatibly changing /usr/bin is customer-friendly seems a bit > odd, considering that > it'd break things for a fair number of Solaris users: it'd be > customer-hostile to them... > This needs to be quantified a

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

> > What would satisfy your complaint? > > Make sure that the tools in /usr/xpg4/bin are treated with the same > level of support as the tools in /usr/bin and merge the SUNWxcu4 > package into SUNWcsu. I'm not sure what you mean: from a support perspective both SUNWxcu4 and SUNWcsu have the sam

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

I. Szczesniak writes: > On 4/11/07, James Carlson <[EMAIL PROTECTED]> wrote: > > I. Szczesniak writes: > > > I explained this in another mail. Our statistics show that lots of > > > customers do not have SUNWxcu4 installed. The system scripts do not > > > require this package and customers tend to

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

On 4/11/07, James Carlson <[EMAIL PROTECTED]> wrote: I. Szczesniak writes: > I explained this in another mail. Our statistics show that lots of > customers do not have SUNWxcu4 installed. The system scripts do not > require this package and customers tend to remove unused packages from > their sy

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

Bart Smaalders writes: > Peter Tribble wrote: > > On 4/11/07, James Carlson <[EMAIL PROTECTED]> wrote: > >> > >> We could make the system less configurable by forcing SUNWxcu4 into > >> SUNWCmreq or by just removing SUNWxcu4 and putting the binaries into > >> SUNWcsu. Would that help? > > > > I l

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

Peter Tribble wrote: On 4/11/07, James Carlson <[EMAIL PROTECTED]> wrote: We could make the system less configurable by forcing SUNWxcu4 into SUNWCmreq or by just removing SUNWxcu4 and putting the binaries into SUNWcsu. Would that help? I like the second idea - remove the package entirely an

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

On 4/11/07, James Carlson <[EMAIL PROTECTED]> wrote: We could make the system less configurable by forcing SUNWxcu4 into SUNWCmreq or by just removing SUNWxcu4 and putting the binaries into SUNWcsu. Would that help? I like the second idea - remove the package entirely and make sure the files

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

"I. Szczesniak" <[EMAIL PROTECTED]> wrote: > > Solaris has been certified for POSIX compliance. > > It appears that the certification does not include a test whether the > POSIX support is usable in production environments. > > > Where is your problem? > > I explained this in another mail. Our sta

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

I. Szczesniak writes: > I explained this in another mail. Our statistics show that lots of > customers do not have SUNWxcu4 installed. The system scripts do not > require this package and customers tend to remove unused packages from > their systems. What would satisfy your complaint? We could ma

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

On 4/11/07, Joerg Schilling <[EMAIL PROTECTED]> wrote: "I. Szczesniak" <[EMAIL PROTECTED]> wrote: > > What other platforms are you speaking of? Linux isn't POSIX compliant, > > and most of the BSDs aren't. So which ones? > > Linux isn't POSIX compliant but the tools in /usr/bin are closer to > t

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

"I. Szczesniak" <[EMAIL PROTECTED]> wrote: > > What other platforms are you speaking of? Linux isn't POSIX compliant, > > and most of the BSDs aren't. So which ones? > > Linux isn't POSIX compliant but the tools in /usr/bin are closer to > the POSIX standard (compared to the tools in Solaris 10).

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

On 4/6/07, Shawn Walker <[EMAIL PROTECTED]> wrote: On 06/04/07, I. Szczesniak <[EMAIL PROTECTED]> wrote: > On 4/3/07, Steven Xie <[EMAIL PROTECTED]> wrote: > > Is this mean We should use Solaris original utilities under > > /usr/bin > > instead of posix ones under /usr/xpg/bin. > > It's really su

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

Shawn Walker wrote: On 06/04/07, I. Szczesniak <[EMAIL PROTECTED]> wrote: On 4/3/07, Steven Xie <[EMAIL PROTECTED]> wrote: > Is this mean We should use Solaris original utilities under > /usr/bin > instead of posix ones under /usr/xpg/bin. > It's really surprising. Well, we can live with it. We

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

On 06/04/07, I. Szczesniak <[EMAIL PROTECTED]> wrote: On 4/3/07, Steven Xie <[EMAIL PROTECTED]> wrote: > Is this mean We should use Solaris original utilities under > /usr/bin > instead of posix ones under /usr/xpg/bin. > It's really surprising. Well, we can live with it. We can barely live with

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

On 4/3/07, Steven Xie <[EMAIL PROTECTED]> wrote: Is this mean We should use Solaris original utilities under /usr/bin instead of posix ones under /usr/xpg/bin. It's really surprising. Well, we can live with it. We can barely live with it. Solaris is a very delicate platform when you try to rely

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

On 4/3/07, James Carlson <[EMAIL PROTECTED]> wrote: Steven Xie writes: > Is this mean We should use Solaris original utilities under > /usr/bin > instead of posix ones under /usr/xpg/bin. > It's really surprising. Well, we can live with it. I wouldn't say that. It comes down to engineering and

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

Oops, I thought that message was from SUN. that's why I was supprised at the first place. It looks like it's not from SUN. Thanks James for clarifying. James Carlson wrote: Steven Xie writes: Is this mean We should use Solaris original utilities under /usr/bin instead of posix ones under

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

Steven Xie writes: > Is this mean We should use Solaris original utilities under > /usr/bin > instead of posix ones under /usr/xpg/bin. > It's really surprising. Well, we can live with it. I wouldn't say that. It comes down to engineering and marketing analysis. You (as a third party software de

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

Is this mean We should use Solaris original utilities under /usr/bin instead of posix ones under /usr/xpg/bin. It's really surprising. Well, we can live with it. Thanks, I. Szczesniak wrote: On 3/29/07, Bart Smaalders <[EMAIL PROTECTED]> wrote: I. Szczesniak wrote: > /usr/bin/tr is one of

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

On 3/29/07, Bart Smaalders <[EMAIL PROTECTED]> wrote: I. Szczesniak wrote: > /usr/bin/tr is one of the big problems in Solaris - the behaviour is > nonstandard and Sun declared long ago that fixes to support multibyte > locales are off limits because they would break backwards > compatibility.

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

Scott Rotondo writes: > Steven Xie wrote: > > echo EFG|/usr/xpg4/bin/tr '[EFG]' '[pBC]' > > Segmentation Fault (core dumped) > > > > echo EFG|/usr/xpg6/bin/tr '[EFG]' '[pBC]' > > Segmentation Fault (core dumped) [...] > This is crazy. Has anybody filed a bug yet? Done -- it's CR 6540973. -- Jam

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

Steven Xie wrote: echo EFG|/usr/xpg4/bin/tr '[EFG]' '[pBC]' Segmentation Fault (core dumped) echo EFG|/usr/xpg6/bin/tr '[EFG]' '[pBC]' Segmentation Fault (core dumped) echo EFG|/usr/bin/tr '[EFG]' '[pBC]' pBC hard to pick now. This is crazy. Has anybody filed a bug yet? Scott _

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

echo EFG|/usr/xpg4/bin/tr '[EFG]' '[pBC]' Segmentation Fault (core dumped) echo EFG|/usr/xpg6/bin/tr '[EFG]' '[pBC]' Segmentation Fault (core dumped) echo EFG|/usr/bin/tr '[EFG]' '[pBC]' pBC hard to pick now. Bart Smaalders wrote: I. Szczesniak wrote: /usr/bin/tr is one of the big problems

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

Hi Casper, I did try it. It works perfect! Howerver, the issue is not about case convert. It's tr sending unexpected output. sometimes even core dumped. I 'm not sure SUN would take it as a bug or not. e.g echo EFG|/usr/xpg6/bin/tr '[EFG]' '[pBC]' Thanks, [EMAIL PROTECTED] wrote: [EMAI

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

[EMAIL PROTECTED] wrote: Here are unexpected outputs echo EFG|/usr/xpg6/bin/tr '[A-Z]' '[a-z]' FGH echo EFG|/usr/xpg4/bin/tr '[A-Z]' '[a-z]' FGH Th correct output echo EFG|/usr/bin/tr '[A-Z]' '[a-z]' efg I only see this issue on SPARC solaris. both 06/06 11/06. The x86 one seems to be

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

I. Szczesniak wrote: /usr/bin/tr is one of the big problems in Solaris - the behaviour is nonstandard and Sun declared long ago that fixes to support multibyte locales are off limits because they would break backwards compatibility. So use the one in /usr/xpg4/bin. - Bart -- Bart Smaalders

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

On 3/28/07, Shawn Walker <[EMAIL PROTECTED]> wrote: On 28/03/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > >Hi Casper, > >I did try it. It works perfect! > >Howerver, the issue is not about case convert. It's tr sending > >unexpected output. sometimes even core dumped. > >I 'm not sure SUN

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

On 28/03/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >Hi Casper, >I did try it. It works perfect! >Howerver, the issue is not about case convert. It's tr sending >unexpected output. sometimes even core dumped. >I 'm not sure SUN would take it as a bug or not. >e.g >echo EFG|/usr/xpg6/bin/tr

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

>Hi Casper, >I did try it. It works perfect! >Howerver, the issue is not about case convert. It's tr sending >unexpected output. sometimes even core dumped. >I 'm not sure SUN would take it as a bug or not. >e.g >echo EFG|/usr/xpg6/bin/tr '[EFG]' '[pBC]' Well, the fact that I get: Segmentation

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

> > >[EMAIL PROTECTED] wrote: > >>>Here are unexpected outputs >>>echo EFG|/usr/xpg6/bin/tr '[A-Z]' '[a-z]' >>>FGH >>>echo EFG|/usr/xpg4/bin/tr '[A-Z]' '[a-z]' >>>FGH >>>Th >>>correct output >>>echo EFG|/usr/bin/tr '[A-Z]' '[a-z]' >>>efg >>>I only see this issue on SPARC solaris. both 06/06

Re: [osol-discuss] xpg/bin/tr unexpect output on Sparc?

>Here are unexpected outputs >echo EFG|/usr/xpg6/bin/tr '[A-Z]' '[a-z]' >FGH >echo EFG|/usr/xpg4/bin/tr '[A-Z]' '[a-z]' >FGH >Th >correct output >echo EFG|/usr/bin/tr '[A-Z]' '[a-z]' >efg >I only see this issue on SPARC solaris. both 06/06 11/06. The x86 one seems >to be fine. You need t

[osol-discuss] xpg/bin/tr unexpect output on Sparc?

Here are unexpected outputs echo EFG|/usr/xpg6/bin/tr '[A-Z]' '[a-z]' FGH echo EFG|/usr/xpg4/bin/tr '[A-Z]' '[a-z]' FGH Th correct output echo EFG|/usr/bin/tr '[A-Z]' '[a-z]' efg I only see this issue on SPARC solaris. both 06/06 11/06. The x86 one seems to be fine. This message posted