Re: Reducing the number of executables to one

[madmurphy]

Hi Martin,

I am relatively unpassionate about this but: Isn't this kind of completion shell-specific?
As in, wouldn't you have to provide different shell scripts for different shells?

Yes, we would need a script for every shell. But we would have to do it once (the list of the available executables would be generated automatically), and online there are many autocompletion templates for most shells ready to use.

On Thu, Mar 3, 2022 at 7:00 AM Schanzenbach, Martin <mschanzenbach@posteo.de> wrote:

> On 3. Mar 2022, at 01:51, madmurphy <madmurphy333@gmail.com> wrote:
>
> 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…

I am relatively unpassionate about this but: Isn't this kind of completion shell-specific?
As in, wouldn't you have to provide different shell scripts for different shells?

BR

>
> --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
> >
>