Re: global commands

> How can I find all globally registered commands of package foo?
> 
> 1. Take all files in /package/foo/command ?
>    Is this really the current convention or does a package exist
>    with private or local commands in it?

/package/foo/command is not even "official". You could have commands
in i.e. /package/foo/bin .
 I think using /package/foo/command is a good convention for foo's
commands, but there is no reason not to include unregistered commands.
Some of my packages export only part of the commands that are listed
in /package/foo/command .


> 2. Create a policy to use the file /package/foo/package/registered as
>    a reference with one command per line.

 That would probably be the best solution. I use the
"package/command.exported" name for that purpose, because future versions
of slashpackage may allow registration (and thus, export) of other
things than commands: documentation for slashdoc, for instance.


>    a. What to do with strange commands which contains <EOL> characters?
>       (We may restrict the commands names to (regex) [a-z0-9_\[-]* .)

 If you have the slightest bit of sanity, you won't create a name with a
'\n' in it. :)


>    b. Is /package/foo/package/command for this purpose?

 From what we can see in Dan's packages, either package/command has that
purpose, or package/command lists every command in the package, both
exported and unexported. I have built my packages according to the latter
supposition.


> 3. Create a policy to put globally registered commands in, e.g.
>    /package/foo/cmd-reg .

 That would go against existing practice: daemontools and nistp224
use /package/foo/command and nothing else.


> 4. Only the package knows which commands of /package/foo/command are
>    globally registered. Its command /package/foo/package/upgrade
>    sets the current-version link AND the symlinks from /command.
>    Thus, it must run as root to update symlinks in /command and
>    may run `rm -rf /' by accident.

 package/upgrade is just a convention, not a rule. You can separate
package/upgrade's functionality in two scripts.


> If the globally registered commands are declared in a file like in (2)
> a slash-package manager can easily use this information to update
> /command.

 Yes. I think that (2) makes the most sense. I'll be happy to comply
with such a policy.

-- 
 Ska