catopen() behavior on solaris-opetron and solaris-sparc
in [Unix Programming]
|
Prev: Printing Back tracing information during run time
Next: JOB Opening: Urgent required System software Engineers Exp:2-4 years
From: Barry Margolin on 8 Nov 2009 01:00 In article <d1b7169a-a57c-44db-8b6d-571415ff3b75(a)j24g2000yqa.googlegroups.com>, mukesh <mukeshmca2(a)gmail.com> wrote: > On Nov 7, 7:17�am, Barry Margolin <bar...(a)alum.mit.edu> wrote: > > In article > > <7a46ae7d-621a-4b82-bff8-2aba41b01...(a)l2g2000yqd.googlegroups.com>, > > > > �mukesh <mukeshm...(a)gmail.com> wrote: > > > On Nov 6, 7:17�pm, Casper H.S. Dik <Casper....(a)Sun.COM> wrote: > > > > Is the catopen() file created on SPARC or on x86? > > > > > > Both need a different file. > > > > > > The catopen files are binary files and they can only be > > > > used on system with same-endian. > > > > > > Casper > > > > Casper, did you read the truss he posted? �It got an error from open(), > > so how can the file format be relevant? > > > > > > > > > Hi Casper, > > > > > thanks for your quik response !! > > > > > the catalog files are created on the respective platform. > > > > > FYI: > > > If exported NLSPATH=/home/expert/msg/%N.cat in that case it works fine > > > on solaris-opteron. > > > > > The question here is why the catopen() library function behaving in > > > the different way on solaris-opteron and other UNIX platforms(solaris- > > > sparc, AIX, HPUX, LINUX) ? > > > > For some reason, those other platforms are adding a .cat suffix, even > > though it wasn't in your NLSPATH value. �I don't see any mention of this > > default suffix in the POSIX specification, I guess it's an extension. > > > > So if your catalog filename ends in .cat, you need to include that in > > either NLSPATH or in the name argument to catopen(), rather than depend > > on this non-portable behavior. > > > > -- > > Barry Margolin, bar...(a)alum.mit.edu > > Arlington, MA > > *** PLEASE post questions in newsgroups, not directly to me *** > > *** PLEASE don't copy me on replies, I'll read them in the group *** > > Other platforms are not adding .cat suffix rather they are returning > -1, it is succeeding only on solaris -x86 platform. That's why I > thought of posting this issue. I got confused about which platforms are behaving one way or the other. Your messages weren't very clear about it. In any case, the point is that if it works, the implementation is adding .cat automatically. > Why catopen() behaves in different way on solaris-x86 than other UNIX > platforms(including solaris-sparc). > Is there any implementaion specific issue. > if yes .. then in that case I think atleast it should consistent > across both the solaris-x86 and the solaris-sparc platforms. > I don't know. Maybe there was an earlier version of catopen() that worked this way, and it's for backward compatibility. Mac OS X's catopen() has extensions that allow other % codes in addition to POSIX's %N. > - > Mukesh -- Barry Margolin, barmar(a)alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group ***
From: mukesh on 9 Nov 2009 05:29
On Nov 8, 11:00 am, Barry Margolin <bar...(a)alum.mit.edu> wrote: > In article > <d1b7169a-a57c-44db-8b6d-571415ff3...(a)j24g2000yqa.googlegroups.com>, > > > > mukesh <mukeshm...(a)gmail.com> wrote: > > On Nov 7, 7:17 am, Barry Margolin <bar...(a)alum.mit.edu> wrote: > > > In article > > > <7a46ae7d-621a-4b82-bff8-2aba41b01...(a)l2g2000yqd.googlegroups.com>, > > > > mukesh <mukeshm...(a)gmail.com> wrote: > > > > On Nov 6, 7:17 pm, Casper H.S. Dik <Casper....(a)Sun.COM> wrote: > > > > > Is the catopen() file created on SPARC or on x86? > > > > > > Both need a different file. > > > > > > The catopen files are binary files and they can only be > > > > > used on system with same-endian. > > > > > > Casper > > > > Casper, did you read the truss he posted? It got an error from open(), > > > so how can the file format be relevant? > > > > > Hi Casper, > > > > > thanks for your quik response !! > > > > > the catalog files are created on the respective platform. > > > > > FYI: > > > > If exported NLSPATH=/home/expert/msg/%N.cat in that case it works fine > > > > on solaris-opteron. > > > > > The question here is why the catopen() library function behaving in > > > > the different way on solaris-opteron and other UNIX platforms(solaris- > > > > sparc, AIX, HPUX, LINUX) ? > > > > For some reason, those other platforms are adding a .cat suffix, even > > > though it wasn't in your NLSPATH value. I don't see any mention of this > > > default suffix in the POSIX specification, I guess it's an extension. > > > > So if your catalog filename ends in .cat, you need to include that in > > > either NLSPATH or in the name argument to catopen(), rather than depend > > > on this non-portable behavior. > > > > -- > > > Barry Margolin, bar...(a)alum.mit.edu > > > Arlington, MA > > > *** PLEASE post questions in newsgroups, not directly to me *** > > > *** PLEASE don't copy me on replies, I'll read them in the group *** > > > Other platforms are not adding .cat suffix rather they are returning > > -1, it is succeeding only on solaris -x86 platform. That's why I > > thought of posting this issue. > > I got confused about which platforms are behaving one way or the other. > Your messages weren't very clear about it. In any case, the point is > that if it works, the implementation is adding .cat automatically. > > > Why catopen() behaves in different way on solaris-x86 than other UNIX > > platforms(including solaris-sparc). > > Is there any implementaion specific issue. > > if yes .. then in that case I think atleast it should consistent > > across both the solaris-x86 and the solaris-sparc platforms. > > I don't know. Maybe there was an earlier version of catopen() that > worked this way, and it's for backward compatibility. > > Mac OS X's catopen() has extensions that allow other % codes in addition > to POSIX's %N. > > > - > > Mukesh > > -- > Barry Margolin, bar...(a)alum.mit.edu > Arlington, MA > *** PLEASE post questions in newsgroups, not directly to me *** > *** PLEASE don't copy me on replies, I'll read them in the group *** I think it's bug in sun studio on solaris-x86. From catopen manual : http://www.opengroup.org/onlinepubs/000095399/functions/catopen.html ++++++++++++++ nl_catd catopen(const char *name, int oflag); . . The full set of metacharacters is: %N The value of the name parameter passed to catopen() . RETURN VALUES Upon successful completion, catopen() returns a message catalog descriptor for use on subsequent calls to cat- gets() and catclose(). Otherwise it returns (nl_catd) -1. .... .... ERRORS The catopen() function may fail if: .... .... ENOENT The message catalogue does not exist or the name argument points to an empty string. .... ++++++++++++++++++ From above if message catalog file doesn't exist then catopen should return -1(ENOENT). So on other UNIX platforms it works as expected except solaris-x86. |