clib gets confused if not invoked via PATH

[bjornfor]

It seems clib gets confused if it's not invoked via PATH:

$ ./result/bin/clib search
Unsupported command "search"

This however, works:

$ PATH=./result/bin clib search | head

  clibs/buffer
  url: https://github.com/clibs/buffer
  desc: tiny c-string library

  nami-doc/trim.c
  url: https://github.com/nami-doc/trim.c
  desc: trim a string, in place

  nami-doc/strlen.c

Tested clib version 1.4.2.

[jb55]

I was testing on osx and it seemed to work, will do some more testing tonight and fix this up

[jb55]

Just realized this isn't a nixpkgs issue, lol. I think I'll still look into fixing this.

[jb55]

I can't seem to reproduce this :(

[bjornfor]

Here is strace output showing that it looks for 'clib-search' in PATH, and because I haven't installed clib yet (just running it from ./result/bin/clib), it fails:

$ strace ./result/bin/clib search |& tail -17
brk(0xe9c000)                           = 0xe9c000
access("/nix/store/rgbi7k3vnzp91zrp0p83zmmyk8adb5w5-glib-2.44.0/bin/clib-search", X_OK) = -1 ENOENT (No such file or directory)
access("/home/bfo/bin/clib-search", X_OK) = -1 ENOENT (No such file or directory)
access("/var/setuid-wrappers/clib-search", X_OK) = -1 ENOENT (No such file or directory)
access("/home/bfo/.nix-profile/bin/clib-search", X_OK) = -1 ENOENT (No such file or directory)
access("/home/bfo/.nix-profile/sbin/clib-search", X_OK) = -1 ENOENT (No such file or directory)
access("/home/bfo/.nix-profile/lib/kde4/libexec/clib-search", X_OK) = -1 ENOENT (No such file or directory)
access("/nix/var/nix/profiles/default/bin/clib-search", X_OK) = -1 ENOENT (No such file or directory)
access("/nix/var/nix/profiles/default/sbin/clib-search", X_OK) = -1 ENOENT (No such file or directory)
access("/nix/var/nix/profiles/default/lib/kde4/libexec/clib-search", X_OK) = -1 ENOENT (No such file or directory)
access("/run/current-system/sw/bin/clib-search", X_OK) = -1 ENOENT (No such file or directory)
access("/run/current-system/sw/sbin/clib-search", X_OK) = -1 ENOENT (No such file or directory)
access("/run/current-system/sw/lib/kde4/libexec/clib-search", X_OK) = -1 ENOENT (No such file or directory)
write(2, "Unsupported command \"search\"\n", 29Unsupported command "search"
) = 29
exit_group(1)                           = ?
+++ exited with 1 +++

@jb55: I guess you couldn't reproduce it because you have clib already installed?

From an end users point of view, I think the first path clib try would be the one where it was invoked from. Then fall back to a PATH search.

[stephenmathieson]

yes, at the moment, clib(1) looks up subcommands on your PATH. if you don't want to put clib and its subcommands on your PATH, you'll have to do:

$ ./result/bin/clib-search something

or

$ ./result/bin/clib-install something

we could check your cwd for clib-* executables, but i'm not sure i understand the benefit. i'd be happy to hear your argument though @bjornfor ;)

[bjornfor]

The benefit is mainly correctness, IMHO. But I understand that this is a corner-case, and not so common scenario.

The first thing I did to test clib was:

$ ./result/bin/clib

  clib <command> [options]

  Options:

    -h, --help     Output this message
    -v, --version  Output version information

  Commands:

    install [name...]  Install one or more packages
    search [query]     Search for packages
    help <cmd>         Display help for cmd

Aha, I thought. So it has a "search" command. Let's try that:

$ ./result/bin/clib search foo
Unsupported command "search"

But.. it said it supported "search"... What's wrong? Did I spell "search" wrong? No, looks right...

Yes, I know I didn't install clib (add it to PATH), but it was properly "make install"ed to ./result/, and the program printed the help text saying that it supports "search" etc. (everything seemed in order). So why did it fail then?

(That was my train of thought.)

On a more technical level, what if I have some improvement or change I want to add to clib. I patch it and install it into a tmpdir. Then I invoke it directly from the tmpdir. But if I don't pay attention to setting the correct PATH, the new clib will invoke the old clib for its sub-commands(!). Oops!

I guess we can fix this in nixpkgs[1] by putting the install dir of clib first into PATH, but it'd be nice (IMHO) if upstream paid attention to these details :-)

[1] http://nixos.org/nix/

[bjornfor]

@stephenmathieson: No, I'm not suggesting to look in the current working directory. I'm suggesting to look in the directory where clib is installed.

Btw, I think this is a case where some programs choose to put the helper tools in $PREFIX/libexec/. Then it is easy to see that a tool, say $PREFIX/bin/clib, should look in $PREFIX/libexec/ for its helpers.

Of course, if this is to extend to "plugins", then after a lookup in $PREFIX/libexec/, the tool may look in $PATH or elsewhere.

[stephenmathieson]

@bjornfor how could clib know where it's installed without assuming somewhere on $PATH or cwd?

[bjornfor]

I think there are two alternatives, compile time and run time. Compile time would be to bake in the install $PREFIX into clib so that it can look for helpers directly in e.g. $PREFIX/libexec/. Or run time, figure out path to self, e.g. $PREFIX/bin/clib and go to ../libexec/ (relative) to find the helpers.

[bjornfor]

Two useful links (regarding determining $PREFIX at runtime):

http://stackoverflow.com/questions/933850/how-to-find-the-location-of-the-executable-in-c
http://alien.cern.ch/cache/autopackage-1.0/site/docs/binreloc/

[bjornfor]

Thinking out loud.

If there is only a fixed set of helpers (clib-search, clib-install, clib-help), they don't have to be stand-alone binaries do they? There is already "clib " entry-point, so why have the additional "clib-" entry-point? Just make them libraries and call the proper function depending on the "clib " argument.

[stephenmathieson]

figuring out $PREFIX at runtime makes sense to me. thanks for the links! i'll look into adding this soon.

If there is only a fixed set of helpers

no, the idea is you're able to make your own plugins and they'll work natively with clib.

[jwerle]

Closing this as wontfix and opening a new issue (#190) as a discussion regarding the sub-commands as libraries providing entry point functions.