Re: Reducing the number of executables to one

[Schanzenbach, Martin]

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

signature.asc
Description: Message signed with OpenPGP