Most tar implementations (GNU, BusyBox, toybox, libarchive) recognize
leading spaces as equivalent to leading zeroes in numeric fields. This
leads to some archives begin recognized as malformed. This fixes it
by replacing leading spaces by leading zeroes in sanitize().
Considering numeric fields ar
Most tar implementations (GNU, BusyBox, toybox, libarchive) recognize
leading spaces as equivalent to leading zeroes in numeric fields. This
leads to some archives begin recognized as malformed. This fixes it
by replacing leading spaces by leading zeroes in sanitize(), and in
chktar(), too.
---
ta
Some tar archives (eg. ftp://ftp.gnu.org/gnu/shtool/shtool-2.0.8.tar.gz)
use leading spaces instead of leading zeroes for numeric fields.
Although it is not allowed by the ustar specification, most tar
implementations recognize it as correct. But since 3ef6d4e4, we
replace all spaces by NULs here,
Upon closer inspection of the toybox roadmap,
it appears some not-out-of-scope items are missing
from the TODO, most importantly dc and file. Moreover,
install is listed in sbase-box since 3c36fb41773,
so the corresponding TODO item was removed.
---
TODO | 13 +
1 file changed, 9 inse
---
.gitignore | 1 +
Makefile | 1 +
README | 1 +
libutil/getlines.c | 3 +-
tac.1 | 22 +++
tac.c | 68 ++
text.h | 3 +-
7 files changed, 97 insertions(+), 2 deletio
usage: strptime fmt timestamp
Most other userspace implementations allow in date(1) the parsing
of dates. That way, one can use a date string, and manipulate it
in scripts. However, the current date(1) implementation only accepts
Unix epochs to describe date and time. Rather than patching date(
The -m flag is not compliant to either the OpenBSD or the moreutils
implementation of ts(1), but closer to the toybox one. It allows
the user to add in nanoseconds, like toybox, but allows to specify
how many digits are printed.
---
.gitignore | 1 +
Makefile | 1 +
README | 1 +
ts.1
---
.gitignore | 1 +
Makefile | 1 +
README | 1 +
shuf.1 | 43 +
shuf.c | 110 +
5 files changed, 156 insertions(+)
create mode 100644 shuf.1
create mode 100644 shuf.c
diff --git a/.gitignore b/.gitig
I'm not sure why we're doing malloc() then memcpy() here, when
we could just make col->line.data point to start.data. This is costy
for huge sorts (3 time slower than other implementations with no real
reason). Since we are now working with the original line.data we need
to revert the s/\n/\0/ that
Some programs need a good PRNG, such as shuf(1), or cron(1). This adds
to libutil a random_uniform function which simply solves the problem of
creating integers uniformly in a range. random_seed seeds the
generator. arc4random would probably be a better PRNG than random, but
it is less portable
---
shuf.c | 37 +
1 file changed, 1 insertion(+), 36 deletions(-)
diff --git a/shuf.c b/shuf.c
index 2655d08..3d8ec51 100644
--- a/shuf.c
+++ b/shuf.c
@@ -7,41 +7,6 @@
#include "text.h"
#include "util.h"
-/*
- * Uniformity is achieved by generating new ran
This patch heavily simplifies the parsing logic of parsefield(), and
makes the grammar more standards-compliant. Before, this cron
implementation would only recognize repeats ("/n" at the end of a
range, or of a wildcar) for wildcars, and list elements could only
be numbers. Now, the basic type i
"Roberto E. Vargas Caballero" wrote:
> I know that there are some pending patches for sbase and ubase,
> but I am a bit busy these days and I will not be able to look
> a bit deeper on them until next week. Be patient until then :)
>
> Thank you
Sure, no problem! I've sent most of the patches I'
In parserange(), we tested wether range was null, to test wether or
not the repeat number was the end of the string (to test if we had
something like "*/3/34"). But it is str that we should be testing,
not range, as its value as a pointer doesn't mean anything in the
current context.
This makes t
In parserange(), we tested wether range was null, to test wether or
not the repeat number was the end of the string (to test if we had
something like "*/3/34"). But it is str that we should be testing,
not range, as its value as a pointer doesn't mean anything in the
current context.
This makes t
localtime() provides the necessary informations to make mktime() work
even in the absence of most informations.
That way, strptime "%d/%m" 26/08 outputs a timestamp corresponding to
the 26th of August of the current year, rather than the 1st January of
1900.
---
strptime.c | 15 ---
1
usage: strptime timestamp fmt
Most other userspace implementations allow in date(1) the parsing
of dates. That way, one can use a date string, and manipulate it
in scripts. However, the current date(1) implementation only accepts
Unix epochs to describe date and time. Rather than patching date(1
---
.gitignore | 1 +
Makefile | 1 +
README | 1 +
libutil/getlines.c | 3 +-
tac.1 | 22 +++
tac.c | 68 ++
text.h | 3 +-
7 files changed, 97 insertions(+), 2 deletio
---
.gitignore | 1 +
Makefile | 2 ++
README | 1 +
libutil/random.c | 46 +
shuf.1 | 43 +++
shuf.c | 77
util.h | 3 ++
7 files changed,
Hello,
Some patches I've sent are orphaned in the mailing list.
These are:
> strptime: tm should be initialized as the current time
and
> shuf: use libutil/random functions instead of custom ones
Moreover, some patches I believed to have sent, weren't actually
sent, due to bugs of my mail client.
Elie Le Vaillant wrote:
> cron(1) depends on the shuf(1) patch for libutil/random. This was
> not made a standalone patch, which was a mistake on my part.
Actually, libutil/random _was_ made a standalone patch, but it appears
not to have been sent either.
Also I'm not sure whether
libutil/random.c now includes a custom PRNG, which is the PCG family.
It also overhauls random_uniform(), making it way faster. Names were
changed (s/random/rng32/g), and reentrant versions added.
The PRNG is faster than libc's random().
It is way faster than the previous version, which used
---
l
---
shuf.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/shuf.c b/shuf.c
index 36b3898..21210de 100644
--- a/shuf.c
+++ b/shuf.c
@@ -47,11 +47,11 @@ main(int argc, char *argv[])
}
}
- random_seed();
+ rng32_seed();
if (!rf
---
cron.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cron.c b/cron.c
index 126ebf1..e95c661 100644
--- a/cron.c
+++ b/cron.c
@@ -294,7 +294,7 @@ parserange(char *str, long low, long high, struct range *r)
if (random) {
/* random replaces low in
decomp() needs the force flag -f too.
---
tar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tar.c b/tar.c
index 5f73c26..0361b63 100644
--- a/tar.c
+++ b/tar.c
@@ -593,7 +593,7 @@ main(int argc, char *argv[])
if (filtertool) {
fd =
---
.gitignore | 1 +
Makefile | 1 +
realpath.c | 34 ++
3 files changed, 36 insertions(+)
create mode 100644 realpath.c
diff --git a/.gitignore b/.gitignore
index e789e24..f1ce1c2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -57,6 +57,7 @@
/printf
/pwd
/re
---
readlink.1 | 1 +
realpath.1 | 20
2 files changed, 21 insertions(+)
create mode 100644 realpath.1
diff --git a/readlink.1 b/readlink.1
index 46b4cad..d5993ce 100644
--- a/readlink.1
+++ b/readlink.1
@@ -28,5 +28,6 @@ by recursively following every symlink in its path c
Thanks NRK
---
libutil/random.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libutil/random.c b/libutil/random.c
index 780ba29..6b795a9 100644
--- a/libutil/random.c
+++ b/libutil/random.c
@@ -1,4 +1,5 @@
#include
+#include
#include
static uint64_t globalstate;
@@
---
cron.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/cron.c b/cron.c
index e95c661..9da0c8a 100644
--- a/cron.c
+++ b/cron.c
@@ -287,19 +287,17 @@ parserange(char *str, long low, long high, struct range
*r)
r->repeat = strtol(repeat, &e, 10);
Thanks Steve Ward
---
libutil/random.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libutil/random.c b/libutil/random.c
index 6b795a9..d5214ae 100644
--- a/libutil/random.c
+++ b/libutil/random.c
@@ -67,7 +67,7 @@ rng32_seed_r(uint64_t *state)
{
struct timespec ts;
getline isn't useful here, because we just need to read then output
lines. We do not need anything more complex than counting '\n's, so
we shouldn't use a buffer like we currently do.
---
head.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/head.c b/head.c
ind
---
tar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tar.c b/tar.c
index 0361b63..405b8d9 100644
--- a/tar.c
+++ b/tar.c
@@ -423,7 +423,7 @@ chktar(struct header *h)
goto bad;
}
memcpy(tmp, h->chksum, sizeof(tmp));
- for (i = 0; i < si
---
TODO | 8
1 file changed, 8 insertions(+)
diff --git a/TODO b/TODO
index 6a0968e..a924aee 100644
--- a/TODO
+++ b/TODO
@@ -73,6 +73,14 @@ tr
* When a character class is present, all other characters in the
string are ignored.
+libutil
+---
+* unescape: NUL ('\0') escapes sh
Thanks NRK
---
libutil/random.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libutil/random.c b/libutil/random.c
index d5214ae..aa98d61 100644
--- a/libutil/random.c
+++ b/libutil/random.c
@@ -67,7 +67,7 @@ rng32_seed_r(uint64_t *state)
{
struct timespec ts;
'~' after number was recognized as abnormal.
---
cron.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cron.c b/cron.c
index 9da0c8a..18ee8b1 100644
--- a/cron.c
+++ b/cron.c
@@ -252,7 +252,7 @@ parserange(char *str, long low, long high, struct range *r)
errn
---
Makefile | 1 +
libutil/random.c | 87
util.h | 5 +++
3 files changed, 93 insertions(+)
create mode 100644 libutil/random.c
diff --git a/Makefile b/Makefile
index 4e20cb3..35c4c25 100644
--- a/Makefile
+++ b/Makefile
@@ -8
This patch heavily simplifies the parsing logic of parsefield(), and
makes the grammar more standards-compliant. Before, this cron
implementation would only recognize repeats ("/n" at the end of a
range, or of a wildcar) for wildcars, and list elements could only
be numbers. Now, the basic type i
patches should I send?
With the sbase-ubase branch/unification, the project has somewhat
shifted in scope (a bit broader). Would it be adapted for this
branch?
I'm willing to work on a dc(1) implementation. Should I use
libzahl?
Cheers,
Elie Le Vaillant
---
rev.c | 2 +-
tail.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/rev.c b/rev.c
index 2d89df1..9ac1da6 100644
--- a/rev.c
+++ b/rev.c
@@ -25,7 +25,7 @@ rev(FILE *fp)
lf = n && line[n - 1] == '\n';
i = n -= lf;
for (n =
e Twister and its 19968 bits of
state, but again, I do not believe this to be a very good argument.
- It's more code (9 SLOC to be precise).
In the end, I believe consistent behavior is somewhat referrable over
avoiding 9 SLOC in libutil/random.
I have a slight preference for a custom PRNG. I'm open to using random()
too.
Cheers,
Elie Le Vaillant
---
libutil/random.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/libutil/random.c b/libutil/random.c
index 72385fb..15082e5 100644
--- a/libutil/random.c
+++ b/libutil/random.c
@@ -21,7 +21,7 @@ rng32(void)
}
void
-rng32_randomseed()
+rng32_see
vert, or to apply the latest version of my patch.
Cheers,
Elie Le Vaillant
).
>
> So this is just more code to get nothing in return. Not very suckless.
> And not sensible in general either IMO.
I agree.
Elie Le Vaillant
43 matches
Mail list logo