catopen() behavior on solaris-opetron and solaris-sparc
mukesh
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 ... ??
Thanks
Mukesh
Casper H.S. Dik
>Hello,
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
catalog file has read permission on both the pltaforms(sparc and
opteron).
Casper H.S. Dik
>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.
mukesh
truss output on solaris-opteron :
.....
....
fxstat(2, 4, 0x07E58400) = 0
close(4) = 0
open("/home/expert/msg/test", O_RDONLY) Err#2 ENOENT
brk(0x080895C0) = 0
brk(0x0808B5C0) = 0
brk(0x0808B5C0) = 0
brk(0x0808D5C0) = 0
brk(0x0808D5C0) = 0
brk(0x080955C0) = 0
brk(0x080955C0) = 0
brk(0x080A55C0) = 0
......
......
-
Mukesh
Casper H.S. Dik
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.
mukesh
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) ?
-
Mukesh
Barry Margolin
<7a46ae7d-621a-4b82...@l2g2000yqd.googlegroups.com>,
mukesh <mukes...@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 ***
mukesh
> In article
> <7a46ae7d-621a-4b82-bff8-2aba41b01...@l2g2000yqd.googlegroups.com>,
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.
-
Mukesh
Casper H.S. Dik
>In article
><7a46ae7d-621a-4b82...@l2g2000yqd.googlegroups.com>,
> mukesh <mukes...@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?
Barry Margolin
<d1b7169a-a57c-44db...@j24g2000yqa.googlegroups.com>,
mukesh <mukes...@gmail.com> wrote:
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
mukesh
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.