Re: Reducing the number of executables to one
> On 3. Mar 2022, at 01:51, madmurphy 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-" 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 and get the list of
> commands available – the same way as you can currently type make 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
> 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-" 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
Re: Reducing the number of executables to one
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-" 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 and get the
list of commands available – the same way as you can currently type make
and get the list of make targets available…
--madmurphy
On Wed, Mar 2, 2022 at 11:01 PM Christian Grothoff
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-" 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
> >
>
>
Re: Reducing the number of executables to one
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-" 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
>
