mukesh <mukeshm...@gmail.com> writes: >Hello, >catopen() function behaves in different ways on solaris-sparc and >solaris-opteron O/S platforms. >If NLSPATH is exported pointing to NLSPATH=/home/expert/msg/%N and >test.cat file is in /home/expert/msg/ folder in that case >if we call : > rc = catopen("test", 0) >then on solaris-sparc it returns -1 whereas on solaris-opteron >platform it succeed. >which is the correct behavior ... ??
What are the permissions of the files?
Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth.
> mukesh <mukeshm...@gmail.com> writes: > >Hello, > >catopen() function behaves in different ways on solaris-sparc and > >solaris-opteron O/S platforms. > >If NLSPATH is exported pointing to NLSPATH=/home/expert/msg/%N and > >test.cat file is in /home/expert/msg/ folder in that case > >if we call : > > rc = catopen("test", 0) > >then on solaris-sparc it returns -1 whereas on solaris-opteron > >platform it succeed. > >which is the correct behavior ... ??
> What are the permissions of the files?
> Casper > -- > Expressed in this posting are my opinions. They are in no way related > to opinions held by my employer, Sun Microsystems. > Statements on Sun products included here are not gospel and may > be fiction rather than truth.
catalog file has read permission on both the pltaforms(sparc and opteron).
mukesh <mukeshm...@gmail.com> writes: >On Nov 6, 3:32=A0pm, Casper H.S. Dik <Casper....@Sun.COM> wrote: >> mukesh <mukeshm...@gmail.com> writes: >> >Hello, >> >catopen() =A0function behaves in different ways on solaris-sparc and >> >solaris-opteron O/S platforms. >> >If NLSPATH is exported pointing to NLSPATH=3D/home/expert/msg/%N and >> >test.cat file is in /home/expert/msg/ folder in that case >> >if we call : >> > =A0 rc =3D catopen("test", 0) >> >then on solaris-sparc it returns =A0 -1 whereas on solaris-opteron >> >platform it succeed. >> >which is the correct behavior ... ??
>> What are the permissions of the files? >catalog file has read permission on both the pltaforms(sparc and >opteron).
What does truss reveal?
Perhaps the files are machine dependent.
Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth.
> mukesh <mukeshm...@gmail.com> writes: > >On Nov 6, 3:32=A0pm, Casper H.S. Dik <Casper....@Sun.COM> wrote: > >> mukesh <mukeshm...@gmail.com> writes: > >> >Hello, > >> >catopen() =A0function behaves in different ways on solaris-sparc and > >> >solaris-opteron O/S platforms. > >> >If NLSPATH is exported pointing to NLSPATH=3D/home/expert/msg/%N and > >> >test.cat file is in /home/expert/msg/ folder in that case > >> >if we call : > >> > =A0 rc =3D catopen("test", 0) > >> >then on solaris-sparc it returns =A0 -1 whereas on solaris-opteron > >> >platform it succeed. > >> >which is the correct behavior ... ??
> >> What are the permissions of the files? > >catalog file has read permission on both the pltaforms(sparc and > >opteron).
> What does truss reveal?
> Perhaps the files are machine dependent.
> Casper > -- > Expressed in this posting are my opinions. They are in no way related > to opinions held by my employer, Sun Microsystems. > Statements on Sun products included here are not gospel and may > be fiction rather than truth.
The catopen files are binary files and they can only be used on system with same-endian.
Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth.
On Nov 6, 7:17 pm, Casper H.S. Dik <Casper....@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 > -- > Expressed in this posting are my opinions. They are in no way related > to opinions held by my employer, Sun Microsystems. > Statements on Sun products included here are not gospel and may > be fiction rather than truth.
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) ?
In article <7a46ae7d-621a-4b82-bff8-2aba41b01...@l2g2000yqd.googlegroups.com>,
mukesh <mukeshm...@gmail.com> wrote: > On Nov 6, 7:17 pm, Casper H.S. Dik <Casper....@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...@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 ***
> In article > <7a46ae7d-621a-4b82-bff8-2aba41b01...@l2g2000yqd.googlegroups.com>,
> mukesh <mukeshm...@gmail.com> wrote: > > On Nov 6, 7:17 pm, Casper H.S. Dik <Casper....@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...@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.
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.
Barry Margolin <bar...@alum.mit.edu> writes: >In article ><7a46ae7d-621a-4b82-bff8-2aba41b01...@l2g2000yqd.googlegroups.com>, > mukesh <mukeshm...@gmail.com> wrote: >> On Nov 6, 7:17 pm, Casper H.S. Dik <Casper....@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?
I didn't react to that posting; but yes, it looks like the file wasn't even there.
>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.
But why does it work differently between Solaris SPARC & x86?
Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth.
mukesh <mukeshm...@gmail.com> wrote: > On Nov 7, 7:17 am, Barry Margolin <bar...@alum.mit.edu> wrote: > > In article > > <7a46ae7d-621a-4b82-bff8-2aba41b01...@l2g2000yqd.googlegroups.com>,
> > mukesh <mukeshm...@gmail.com> wrote: > > > On Nov 6, 7:17 pm, Casper H.S. Dik <Casper....@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...@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...@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 ***
> In article > <d1b7169a-a57c-44db-8b6d-571415ff3...@j24g2000yqa.googlegroups.com>,
> mukesh <mukeshm...@gmail.com> wrote: > > On Nov 7, 7:17 am, Barry Margolin <bar...@alum.mit.edu> wrote: > > > In article > > > <7a46ae7d-621a-4b82-bff8-2aba41b01...@l2g2000yqd.googlegroups.com>,
> > > mukesh <mukeshm...@gmail.com> wrote: > > > > On Nov 6, 7:17 pm, Casper H.S. Dik <Casper....@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...@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...@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 ***
++++++++++++++ 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.
|
