> On 3. Mar 2022, at 01:51, madmurphy <madmurphy...@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 <groth...@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