| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As regards the test(1) utility, the POSIX.1-2024 specification defines
the -nt and -ot primaries as standard features. Given that the
specification in question was only recently published, this would not
normally be an adequate reason for using them in gentoo-functions, in
and as of itself. However, I was already aware that the these primaries
are commonly implemented and have been so for years.
So, I decided to evaluate a number of shells and see how things stand
now. Here is a list of the ones that I tested:
- ash (busybox 1.36.1)
- dash 0.5.12
- bash 5.2.26
- ksh 93u+
- loksh 7.5
- mksh 59c
- oksh 7.5
- sh (FreeBSD 14.1)
- sh (NetBSD 10.0)
- sh (OpenBSD 7.5)
- yash 2.56.1
Of these, bash, ksh93, loksh, mksh, oksh, OpenBSD sh and yash appear to
conform with the POSIX-1.2024 specification. The remaining four fail to
conform in one particular respect, which is as follows.
$ touch existent
$ set -- existent nonexistent
$ [ "$1" -nt "$2" ]; echo "$?" # should be 0
1
$ [ "$2" -ot "$1" ]; echo "$?" # should be 0
1
To address this, I discerned a reasonably straightforward workaround
that involves testing both whether the file under consideration exists
and whether the variable keeping track of the newest/oldest file has yet
been assigned to.
As far as I am concerned, the coverage is more than adequate for both
primaries to be used by gentoo-functions. As such, this commit adjusts
the following three functions so as to do exactly that.
- is_older_than()
- newest()
- oldest()
It also removes the following functions, since they are no longer used.
- _find0()
- _select_by_mtime()
With this, GNU findutils is no longer a required runtime dependency. Of
course, should a newly introduced feature of gentoo-functions benefit
from the presence of findutils in the future, there is no reason that it
cannot be brought back in that capacity.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As mentioned by the previous commit, the Shell Command Language leaves
it unspecified as to whether variable assignments affecting the
execution environment of a simple command charged with executing a
function (that is not the implementation of a standard utility) shall
persist after the completion of the function.
It transpires that modifying gentoo-functions so as to steer clear of
this pitfall isn't particularly difficult so this commit does exactly
that. Most of the changes are in test-functions but functions/rc.sh also
required some minor changes regarding the use of the GENFUN_CALLER
variable.
With this, loksh very nearly passes the test suite. There is one
individual test that continues to fail, although it looks as though that
may be caused by a genuine bug on the part of the shell. That will
require investigating in its own right.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
| |
|
|
|
|
|
| |
It would be sensible to conduct a survey to determine whether - and
where - it is being used beforehand.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
|
| |
|
|
|
|
|
| |
I'm not yet ready to commit to it being among the core functions for the
inaugural API level.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Consider the value of EINFO_LOG to be false in the event that it is
equal to the value of RC_SERVICE. The reason for this is that, as of the
time of writing, openrc-run(8) defines and uses EINFO_LOG in a way that
is at odds with gentoo-functions. Ideally, the behaviour of OpenRC would
be modified so that it becomes possible to jettison this workaround.
Fixes: 0dd8364c03c6f8737150ee4f146ddeeec57efee9
Bug: https://bugs.gentoo.org/936613
Signed-off-by: Kerin Millar <kfm@plushkava.net>
|
| |
|
|
|
|
|
|
|
|
|
| |
The function is a simple wrapper around GNU find(1) which presumes the
intent to use the -files0-from option to read NUL-delimited path names
from the standard input. The benefit in having it is twofold. Firstly,
the _select_by_mtime() and is_older_than() functions are thereby made a
little easier to read. Secondly, the genfun_bin_find variable is now
initialised lazily.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
|
| |
|
|
|
|
|
| |
I'm not yet ready to commit to it being among the core functions for the
inaugural API level.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
|
| |
|
|
|
|
|
| |
Though it works very well, I'm not yet ready to commit to it being among
the core functions for the inaugural API level.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
|
| |
|
|
| |
Signed-off-by: Kerin Millar <kfm@plushkava.net>
|
| |
|
|
|
|
| |
As based on the implementation in Maarten Billemont's bashlib library.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The idea is to be able to write new functions without having to
initially commit to their being in the core library or, indeed, any of
the other modules. Experimental functions may be promoted or simply
dropped without warning if it is decided that they are insufficiently
useful to merit incorporation.
This initial commit defines the is_interactive() and prepend_ts()
functions.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Firstly, the "." builtin is not specified to support the passing of
arguments; such is a bashism. It is rather presumptuous to act as if the
present contents of the positional parameters are for the benefit of
gentoo-functions at the time of its initialisation.
Secondly, there exists a de-facto standard for suppressing colored
output, which is to define NO_COLOR as a non-empty string, per
https://no-color.org.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
|
|
|
For many years, the implied purpose of gentoo-functions has been to
provided parallel implementations of utilities provided by OpenRC, along
with a handful of peripheral functions. It is probably also fair to say
that it has not seen much in the way of maintenance until comparatively
recently. As of the present day, the status quo is not ideal. For one
thing, the library has never been particularly useful beyond this
definition. It is my hope that some of the recently added functions will
be well received by those needing to write effective shell scripts in
Gentoo for a number of relevant tasks. Certainly, there remains ample
room for improvement in that regard.
For another thing, the implementation of gentoo-functions is presently
inflexible. For instance, it is impossible to source the functions from
an OpenRC runscript without overriding the OpenRC implementations. Nor
may one source the functions from an ebuild or eclass without overriding
the Portage implementations. Indeed, it is has become something of a
mess. Not only does gentoo-functions implement a number of functions
that shadow the OpenRC implementations but so does Portage, owing to the
existence of its "isolated-functions.sh" unit. What's more, the various
implementations are of varying quality and do not necessarily behave in
the same manner.
This commit aims to address some of these issues by rendering
gentoo-functions modular in nature. It establishes the premise of having
a core library, with collections of additional functions being
optionally declarable. As such, all of the functions that shadow OpenRC
have been relocated to a unit named "rc.sh". This first change
encompasses the following public functions:
- ebegin
- eend
- eerrorn
- eindent
- einfon
- eoutdent
- esyslog
- ewarnn
- ewend
- get_bootparam
- is_older_than
- veend
- vewend
- yesno
Similarly, all of the functions that exclusively shadow Portage have
been relocated to a unit named "portage.sh". This second change
encompasses the following public functions:
- die
- edo
- eqatag
- eqawarn
The functions that remain in the "functions.sh" unit may now be
considered as core functions. To accommodate all of this, a new
GENFUN_MODULES variable is supported, whose behaviour is described
herewith.
If GENFUN_MODULES is found to be set at the time of "functions.sh" being
sourced, it shall be taken as a list of zero or more blank-separated
words. In turn, these words shall be taken as the basenames of
potentially available modules - not including the .sh suffix.
Presently, the only supported module names are "rc" and "portage".
Should either or both of these names be present, their respective units
shall be automatically sourced. If neither are present, no additional
units shall be sourced. Consequently, it becomes possible for a consumer
of gentoo-functions to request that only the core functions be declared
by writing:
GENFUN_MODULES= . /lib/gentoo/functions.sh
If, on the other hand, GENFUN_MODULES is found not to be set then
heuristics shall be employed to determine which of the additional units
should be sourced. The intent of these heuristics is twofold. Firstly,
to maintain an adequate degree of backward-compatibility and, secondly,
to act as is appropriate based on the characteristics of the operating
environment. The exact behaviour of these heuristics is as follows.
If the present shell is neither executing a runscript nor a subprocess
of one, the ensuing behaviour shall be as if "rc" had initially been
among the names defined by the GENFUN_MODULES variable.
If the present shell is not a subprocess of portage, the ensuing
behaviour shall be as if "portage" had initially been among the names
defined by the GENFUN_MODULES variable.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
|
Kerin Millar
GitWeb