announce: executable name and weird behaviour

[James Morris]

hi,

a user reported strange behaviour in my implementation of nsm support in
petri-foo (pf). he said when adding pf as a client, two entries appear
in nsm, the first never leaves the olive/launch state, and the second
proceeds to green/ready state and works as normal.

i couldn't reproduce this until the op showed he was starting pf from a
subdir in his home directory. after some experimenting i discovered the
strange behaviour arose whenever i specified a path to petri-foo.

eventually figured the problem arises with the executable name of
"petri-foo" i'd provided to nsm_send_announce. when petri-foo was
started by nsm without a specific path this was fine, but as soon as a
path is specified there's a mismatch in executable names.

just thought i'd share this as it was rather perplexing for some time,
but also i don't know if it's something you might want to know about.

cheers,
james.

[J. Liles]

Post by James Morris
hi,
a user reported strange behaviour in my implementation of nsm support in
petri-foo (pf). he said when adding pf as a client, two entries appear
in nsm, the first never leaves the olive/launch state, and the second
proceeds to green/ready state and works as normal.
i couldn't reproduce this until the op showed he was starting pf from a
subdir in his home directory. after some experimenting i discovered the
strange behaviour arose whenever i specified a path to petri-foo.
eventually figured the problem arises with the executable name of
"petri-foo" i'd provided to nsm_send_announce. when petri-foo was
started by nsm without a specific path this was fine, but as soon as a
path is specified there's a mismatch in executable names.
just thought i'd share this as it was rather perplexing for some time,
but also i don't know if it's something you might want to know about.
cheers,
james.

Thanks. Yeah. Client executables should always be in the user's $PATH. I
need to add some code to nsmd to throw an error if the user tries to
specify the path.

[James Morris]

Post by J. Liles

Post by James Morris
hi,
a user reported strange behaviour in my implementation of nsm
support in petri-foo (pf). he said when adding pf as a client, two
entries appear in nsm, the first never leaves the olive/launch
state, and the second proceeds to green/ready state and works as
normal.
i couldn't reproduce this until the op showed he was starting pf
from a subdir in his home directory. after some experimenting i
discovered the strange behaviour arose whenever i specified a path
to petri-foo.
eventually figured the problem arises with the executable name of
"petri-foo" i'd provided to nsm_send_announce. when petri-foo was
started by nsm without a specific path this was fine, but as soon as
a path is specified there's a mismatch in executable names.
just thought i'd share this as it was rather perplexing for some
time, but also i don't know if it's something you might want to know
about.
cheers,
james.

Thanks. Yeah. Client executables should always be in the user's $PATH.
I need to add some code to nsmd to throw an error if the user tries to
specify the path.

Just curious, passing argv[0] seems to work, so why disallow?

[James Morris]

Post by James Morris

Post by J. Liles
Thanks. Yeah. Client executables should always be in the user's
$PATH. I need to add some code to nsmd to throw an error if the
user tries to specify the path.

Just curious, passing argv[0] seems to work, so why disallow?

Not sure I get your meaning, but it's bad to have paths in the session
file because it affects portability... Also, say you move something
from ~/bin to /usr/local/bin or /usr/bin... Then you'd have to update
all your session files too. People should just learn to use the $PATH
environment variable properly.

I decided to "fix" the "problem" by doing this:

nsm_send_announce(s->nsm_client, "Petri-Foo", ":switch:",argv[0]);

Which works, but as you say, it breaks portability. Will unfix!

[Diego Simak]

Post by J. Liles

Post by James Morris
hi,
a user reported strange behaviour in my implementation of nsm support in
petri-foo (pf). he said when adding pf as a client, two entries appear
in nsm, the first never leaves the olive/launch state, and the second
proceeds to green/ready state and works as normal.
i couldn't reproduce this until the op showed he was starting pf from a
subdir in his home directory. after some experimenting i discovered the
strange behaviour arose whenever i specified a path to petri-foo.
eventually figured the problem arises with the executable name of
"petri-foo" i'd provided to nsm_send_announce. when petri-foo was
started by nsm without a specific path this was fine, but as soon as a
path is specified there's a mismatch in executable names.
just thought i'd share this as it was rather perplexing for some time,
but also i don't know if it's something you might want to know about.
cheers,
james.

Thanks. Yeah. Client executables should always be in the user's $PATH. I
need to add some code to nsmd to throw an error if the user tries to
specify the path.

Hi, I'm not sure if it is OK or not but I'm using scripts with 'exec' to
execute for example hydrogen to open a specific song and put that script in
NSM.
That script is not in $PATH so I added it using entire path. I know that
hydrogen is not supported in NSM.

Thanks.