Prefix Problem

QNX Newsgroups (Archives) qdn.public.qnx4
1

Hi,

I am trying to do a:
qnx_prefix_Attach( “/from”, “/to”, 0 );
after I do it if I type:
prefix
it shows a line that says:
/from=/to

But, . . . . if I type:
ls -l /from
I get:
No such file or directory (/from)
and if I type:
ls -l /to
I get a valid list of files (/to is a directory).

Also, if I type:
prefix -A /from=/to
and then do a:
ls -l /from
it also works as expected.

Obviously, the qnx_prefix_attach() function is broke.
What must I replace to get this to work?

My system running Proc32 V 4.24G Aug 25, 1997 and Slib32 V 4.24A Feb 4,
1997. I am running Watcom V10.6 with Patch Level B dated 22-Apr-99.

Is there any other version information that you need?

2

Bill at Sierra Design <BC@sierradesign.com> wrote:

Hi,

I am trying to do a:
qnx_prefix_Attach( “/from”, “/to”, 0 );
after I do it if I type:
prefix
it shows a line that says:
/from=/to

But, . . . . if I type:
ls -l /from
I get:
No such file or directory (/from)
and if I type:
ls -l /to
I get a valid list of files (/to is a directory).

Also, if I type:
prefix -A /from=/to
and then do a:
ls -l /from
it also works as expected.

Obviously, the qnx_prefix_attach() function is broke.
What must I replace to get this to work?

If you take a look of the result of “prefix -A /from=/to” you
will see the resulting prefix is actually:

/from=//node_id/to

That is, on my machine when I did the prefix -A command, I got:

/from=//88/to

Whereas when I did the C code you suggested, I got:

/from=/to

That would seem to be the difference. I tried:

prefix( “/from”, “//0/to”, 0 );

And that also worked as expected, since //0 means the current node.

So, you can either use //0 or, as the prefix utility does, you can
use nidtostr(osdata.nodename,NULL, 0) to get your current node id.

-David

3

Thank you. I never noticed this before.

Although I have successfully used the qnx_prefix_attach() function I did not
realize that the file://node was mandatory. I can see from the helpviewer
page that their example uses it. It does NOT come right out and say that a
file://node is necessary.

Steve?!?!


David Gibbs <dagibbs@qnx.com> wrote in message
news:8tkapc$49i$1@nntp.qnx.com…

Bill at Sierra Design <> BC@sierradesign.com> > wrote:
Hi,

I am trying to do a:
qnx_prefix_Attach( “/from”, “/to”, 0 );
after I do it if I type:
prefix
it shows a line that says:
/from=/to

But, . . . . if I type:
ls -l /from
I get:
No such file or directory (/from)
and if I type:
ls -l /to
I get a valid list of files (/to is a directory).

Also, if I type:
prefix -A /from=/to
and then do a:
ls -l /from
it also works as expected.

Obviously, the qnx_prefix_attach() function is broke.
What must I replace to get this to work?

If you take a look of the result of “prefix -A /from=/to” you
will see the resulting prefix is actually:

/from=//node_id/to

That is, on my machine when I did the prefix -A command, I got:

/from=//88/to

Whereas when I did the C code you suggested, I got:

/from=/to

That would seem to be the difference. I tried:

prefix( “/from”, “file://0/to”, 0 );

And that also worked as expected, since file://0 means the current node.

So, you can either use file://0 or, as the prefix utility does, you can
use nidtostr(osdata.nodename,NULL, 0) to get your current node id.

-David

4

Bill at Sierra Design <BC@sierradesign.com> wrote:

Thank you. I never noticed this before.

Although I have successfully used the qnx_prefix_attach() function I did not
realize that the file://node was mandatory. I can see from the helpviewer
page that their example uses it. It does NOT come right out and say that a
file://node is necessary.

I didn’t know it was neccessary either – I just noticed the difference
between the one that worked and the one that didn’t. I’ll bet it has
to do with the order things are resolved inside Proc32.

Steve?!?!

If you’re looking for confirmation from Steve McPolin, you’re unlikely
to get it… he is no longer works for QNX.

-David

David Gibbs <> dagibbs@qnx.com> > wrote in message
news:8tkapc$49i$> 1@nntp.qnx.com> …
Bill at Sierra Design <> BC@sierradesign.com> > wrote:
Hi,

I am trying to do a:
qnx_prefix_Attach( “/from”, “/to”, 0 );
after I do it if I type:
prefix
it shows a line that says:
/from=/to

But, . . . . if I type:
ls -l /from
I get:
No such file or directory (/from)
and if I type:
ls -l /to
I get a valid list of files (/to is a directory).

Also, if I type:
prefix -A /from=/to
and then do a:
ls -l /from
it also works as expected.

Obviously, the qnx_prefix_attach() function is broke.
What must I replace to get this to work?

If you take a look of the result of “prefix -A /from=/to” you
will see the resulting prefix is actually:

/from=//node_id/to

That is, on my machine when I did the prefix -A command, I got:

/from=//88/to

Whereas when I did the C code you suggested, I got:

/from=/to

That would seem to be the difference. I tried:

prefix( “/from”, “file://0/to”, 0 );

And that also worked as expected, since file://0 means the current node.

So, you can either use file://0 or, as the prefix utility does, you can
use nidtostr(osdata.nodename,NULL, 0) to get your current node id.

-David

5

No. I thought that Steve Reid was in charge of documentation.

David Gibbs <dagibbs@qnx.com> wrote in message
news:8tkhqp$7eg$1@nntp.qnx.com…

Bill at Sierra Design <> BC@sierradesign.com> > wrote:
Thank you. I never noticed this before.

Although I have successfully used the qnx_prefix_attach() function I did
not
realize that the file://node was mandatory. I can see from the
helpviewer
page that their example uses it. It does NOT come right out and say
that a
file://node is necessary.

I didn’t know it was neccessary either – I just noticed the difference
between the one that worked and the one that didn’t. I’ll bet it has
to do with the order things are resolved inside Proc32.

Steve?!?!

If you’re looking for confirmation from Steve McPolin, you’re unlikely
to get it… he is no longer works for QNX.

6

Bill at Sierra Design <BC@sierradesign.com> wrote:
: No. I thought that Steve Reid was in charge of documentation.

Wow! I’m famous! :slight_smile:

: David Gibbs <dagibbs@qnx.com> wrote in message
: news:8tkhqp$7eg$1@nntp.qnx.com…
:> Bill at Sierra Design <BC@sierradesign.com> wrote:
:> > Thank you. I never noticed this before.
:>
:> > Although I have successfully used the qnx_prefix_attach() function I did
: not
:> > realize that the file://node was mandatory. I can see from the
: helpviewer
:> > page that their example uses it. It does NOT come right out and say
: that a
:> > file://node is necessary.
:>
:> I didn’t know it was neccessary either – I just noticed the difference
:> between the one that worked and the one that didn’t. I’ll bet it has
:> to do with the order things are resolved inside Proc32.
:>

I’ll try to confirm this, and update the docs if necessary.

:> > Steve?!?!
:>
:> If you’re looking for confirmation from Steve McPolin, you’re unlikely
:> to get it… he is no longer works for QNX.

A pity…

Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems

7

Bill at Sierra Design <BC@sierradesign.com> wrote:

No. I thought that Steve Reid was in charge of documentation.

Ah, addressing a different Steve. My wrong.

Of course, Steve – like David – is not a unique identifier around here. :slight_smile:
(And, Steve Reid posts as stever, whereas Steve McPolin used to post as
steve.)

-David

David Gibbs <> dagibbs@qnx.com> > wrote in message
news:8tkhqp$7eg$> 1@nntp.qnx.com> …
Bill at Sierra Design <> BC@sierradesign.com> > wrote:
Thank you. I never noticed this before.

Although I have successfully used the qnx_prefix_attach() function I did
not
realize that the file://node was mandatory. I can see from the
helpviewer
page that their example uses it. It does NOT come right out and say
that a
file://node is necessary.

I didn’t know it was neccessary either – I just noticed the difference
between the one that worked and the one that didn’t. I’ll bet it has
to do with the order things are resolved inside Proc32.

Steve?!?!

If you’re looking for confirmation from Steve McPolin, you’re unlikely
to get it… he is no longer works for QNX.