-q: suppress filename headers when multiple files are used
-v: print filename headers even when only one file is used
head already supports the same arguments, which originated in GNU head.
GNU tail also has the same flags.
Add tac, a hard link to 'tail -rq'.
Prints a file in reverse line order.
Similar to GNU tac, but lacking any options.
Add accompanying documentation.
correctly, in particular %%f does not contain the %f format, and like
all strftime conversions, %f can occur more than once (not that it is
likely to happen, but just in case...)
+ add a -d <destdir> option, which allows the versions of programs
in a directory tree rooted at "<destdir>" to be reported on, rather
than the programs and libraries rooted under /. This is useful, for
example, for finding out the versions of utilities and libraries
after a build.sh run:
% sys_info
awk-20121220
bind-9.10.5pl2
bozohttpd-20170201
bzip2-1.0.6
calendar-20160601
dhcpcd-7.0.0-rc1
dtc-1.4.4
ftpd-20110904
g++-5.4.0
gcc-5.4.0
grep-2.5.1anb1
gzip-20170803
libc-12.208
...
% sys_info -d /data/8/build/dest/x86_64
awk-20121220
bind-9.10.5pl1
bozohttpd-20170201
bzip2-1.0.6
calendar-20160601
dhcpcd-7.0.0-rc1
ftpd-20110904
g++-5.4.0
gcc-5.4.0
grep-2.5.1anb1
gzip-20150113
libc-12.207
...
%
so it only applies to -x (in particular, not to -s) and only if another
time format has not been explicitly selected (earlier in the arg list).
With luck, this will make lots of tests, which depended upon "stat -s"
actually generating correct sh assignment statements, go back to working again.
Option name from FreeBSD. While here, make it possible to use a
combination of -T -E and -R to display timestamps in several formats.
Idea also from FreeBSD.
Note that on 32-bit platforms it probably never worked anyway because
header size changed from v1 to v2 when time_t became 64 bit.
ok christos@
CVS: ----------------------------------------------------------------------
CVS: CVSROOT cvs.NetBSD.org:/cvsroot
CVS: please use "PR category/123" to have the commitmsg appended to PR 123
CVS:
CVS: Please evaluate your changes and consider the following.
CVS: Abort checkin if you answer no.
CVS: => For all changes:
CVS: Do the changed files compile?
CVS: Has the change been tested?
CVS: => If you are not completely familiar with the changed components:
CVS: Has the change been posted for review?
CVS: Have you allowed enough time for feedback?
CVS: => If the change is major:
CVS: => If the change adds files to, or removes files from $DESTDIR:
CVS: => If you are changing a library or kernel interface:
CVS: Have you successfully run "./build.sh release"?
impossible to support component names containing embedded \n's (the
similar embedded space problem would have been trivial to fix.)
Deleting the sorting makes those issues moot, the args are no longer
processed, hence can be anything.
An alternative would be to sort the results - but that would separate
the -v output from the real output (-v stuff is not rationally sortable)
and also makes it much more difficult to get the error code for an
unknown component (like one containing an embedded \n !) as the pipe
to strt that would be used would cause the while loop to run in a sub-shell
(effectively.)
CVS's $ Date $ expansion to calculate the date, whilst being more
accurate, runs into issues with reproducible builds, and alternate
repository software. Simplicity wins here.
Add yacc to the list of utilities to report on
Add -L and -P flags to allow the library/cmd search paths to be set.
Add support for getting vers info from sh, dhcpcd, and userland (/etc/release).
Stop abusing "sh -x" to support -v - do it properly. Get rid of the duplicate
list of components used when there are no args, instead make better use of sh
capabilities to just process everything. Better use of what sh can do for us
other places too. Add a (more or less random) set of libraries to include
in output when no args are given.
OK agc (well, earlier version...)
+ get rid of -a argument, which was superfluous since no arguments
means provide information on everything known
+ add the shell function to check for the path of a program. Taken
from pkgsrc bootstrap script, modified for return values, and "not
found" action
+ use this shell function for tcsh and unbound, both of which may not
exist on systems
+ go back to using standard shell construct for parsing options now,
since there is only 1 option with no optargs
+ from a suggestion from Paul Goyette, run the provided arguments
through sort | uniq
+ add sys_info itself to the list of programs to report
This is an experiment with a handful of macros for writing the
checks, most of which are compile-time:
MUL_OK(t, a, b) Does a*b avoid overflow in type t?
ADD_OK(t, a, b) Does a + b avoid overflow in type t?
TOOMANY(t, x, b, m) Are there more than m b-element blocks in x in type t?
(I.e., does ceiling(x/b) > m?)
Addenda that might make sense but are not needed here:
MUL(t, a, b, &p) Set p = a*b and return 0, or return ERANGE if overflow.
ADD(t, a, b, &s) Set s = a+b and return 0, or return ERANGE if overflow.
Example:
uint32_t a = ..., b = ..., y = ..., z = ..., x, w;
/* input validation */
error = MUL(size_t, a, b, &x);
if (error)
fail;
if (TOOMANY(uint32_t, x, BLKSIZ, MAX_NBLK))
fail;
y = HOWMANY(x, BLKSIZ);
if (z > Z_MAX)
fail;
...
/* internal computation */
__CTASSERT(MUL_OK(uint32_t, Z_MAX, MAX_NBLK));
w = z*y;
Obvious shortcomings:
1. Nothing checks your ctassert matches your subsequent arithmetic.
(Maybe we could have BOUNDED_MUL(t, x, xmax, y, ymax) with a
ctassert inside.)
2. Nothing flows the bounds needed by the arithmetic you use back
into candidate definitions of X_MAX/Y_MAX.
But at least the reviewer's job is only to make sure that (a) the
MUL_OK matches the *, and (b) the bounds in the assertion match the
bounds on the inputs -- in particular, the reviewer need not derive
the bounds from the context, only confirm they are supported by the
paths to it.
This is not meant to be a general-purpose proof assistant, or even a
special-purpose one like gfverif <http://gfverif.cryptojedi.org/>.
Rather, it is an experiment in adding a modicum of compile-time
verification with a simple C API change.
This also is not intended to serve as trapping arithmetic on
overflow. The goal here is to enable writing the program with
explicit checks on input and compile-time annotations on computation
to gain confident that overflow won't happen in the computation.
