gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reducing the number of executables to one


From: madmurphy
Subject: Re: Reducing the number of executables to one
Date: Thu, 3 Mar 2022 00:51:17 +0000

Hi Christian,

As I said, it is more of a long term planning. The main argument in favor is that (hopefully!) the number of “gnunet-XXX” utilities is only destined to grow, so eventually at some point it will be needed anyway. I can try to be the devil's advocate and answer point by point…

It just makes it less obvious how to run the binaries under valgrind/gdb, adds just another process as overhead

It will always be possible to run the binaries directly. They will still exist, they will only be outside /usr/bin. Already now GNUnet does something similar with /usr/lib/gnunet/libexec.

may require re-writing documentation.

That yes, will be required. But can be done slowly. If people see in the documentation gnunet-peerinfo instead of gnunet peerinfo they are going to understand anyway. It could even become an opportunity to do a very much needed documentation review.

It also removes the ability to get a list of possible invocations via 'tab' easily (right now, you can type "gnunet-<TAB><TAB>" and get a list of all available gnunet-commands).

That no, it is not a problem. It is possible to add command completion to the gnunet script/program (depending on whether we decide that it is a script or a C program), so that a user can type gnunet <TAB> and get the list of commands available – the same way as you can currently type make <TAB> and get the list of make targets available…

--madmurphy


On Wed, Mar 2, 2022 at 11:01 PM Christian Grothoff <grothoff@gnunet.org> wrote:
Personally, I'm not a fan of this style. It just makes it less obvious
how to run the binaries under valgrind/gdb, adds just another process as
overhead, and may require re-writing documentation. It also removes the
ability to get a list of possible invocations via 'tab' easily (right
now, you can type "gnunet-<TAB><TAB>" and get a list of all available
gnunet-commands).

So overall, the "benefit" of being able to remove the hyphen seems,
well, questionable. But I'm aware that it is the current fashion. But I
personally don't get that fashion.

On 2/27/22 11:20 AM, madmurphy wrote:
> This is more like a long term plan and nothing really important…
>
> I saw that the amount of command line utilities that GNUnet ships is
> quite sizeable and is probably only destined to grow (I have counted 70
> executables in |/usr/bin|); so I was thinking that GNUnet could follow
> git's approach, that of having one single executable in |/usr/bin|, and
> do something like |gnunet COMMAND OPTIONS ARGUMENTS|.
>
> As all the executables are named |gnunet-SOMETHING|, this would
> basically only remove the hyphen. For example, |gnunet-search 'commons'|
> would become |gnunet search 'commons'|.
>
> It can be done with a shell script as simple as:
>
> #!/bin/sh
> #
> # /usr/bin/gnunet
> #
>
> _GNUNET_UTIL_DIR_='/foo/bar'
>
> if [[ -f "${_GNUNET_UTIL_DIR_}/gnunet-${1}" ]]; then
>       "${_GNUNET_UTIL_DIR_}/gnunet-${1}" "${@:2}"
> else
>       echo "Unknown command \"${1}\"."
> fi
>
> (where |/foo/bar| is the directory where the executables are actually
> installed.)
>
> What do you think?
>
> --madmurphy
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]