Re: [hackers] [sbase] [PATCH 11/11] tail: Process bytes with -c option, and add -m option for runes

[Michael Forney]

On 12/27/16, Evan Gates  wrote:
> On Tue, Dec 27, 2016 at 5:55 AM, Laslo Hunhold  wrote:
>> well-spotted! Still, it's _very_ counterintuitive to call the flag
>> "-c". Instead of adding a non-portable m-flag, it would even sound
>> better to me to add a b-flag for byte-offsets.

Yes, it's a bit counter-intuitive, but conflicting with POSIX for this
alone seems like a really bad idea. I always consult POSIX when
writing shell scripts to ensure that they will run on any conforming
system. If sbase decided that the option character name was not the
best choice, then reasonable, valid, and portable scripts may start
operating unexpectedly with no indication as to why.

Also, wc(1) (even sbase's implementation) uses -c to refer to bytes,
and -m to refer to characters. It wouldn't be self-consistent to make
tail use -b for bytes and -c for characters. (Just to clarify, I also
think it would be a really bad idea to make wc use -b for bytes and -c
for characters).

>> It all depends on how many scripts rely on this behaviour. Can you give
>> an example?

Sure. gcc's build system uses tail to skip the first 16 bytes of the
binaries to check that stage2 and stage3 are the same. Granted, it
does use non-standard syntax tail +16c, and I don't know that there
are any bytes in there with the high bit set, but still, tail *does*
get invoked on binary files, and treating the byte offsets as
characters will break things in strange ways that are difficult to
debug.

>> I thought cut(1) was the tool of choice for extracting
>> headers and such things.

How do you use cut(1) to strip the first 512 bytes of a binary file?
It operates on lines.

> I think deviating from POSIX here is a bad idea. Every deviation from
> POSIX means that our tools cannot be used in another situation and
> pushes prospective users away. If the user wants characters instead of
> bytes we have tools to do that, don't surprise the user by doing
> something different than every other implementation.
>
> P.S. I too found -c confusing the first time I expected utf8
> characters, but remembering these tools were created with ascii in
> mind, I think of -c as char and it all works out...

Agreed.

Re: [hackers] [sbase][Patch] date: add date/time setting capability

[Michael Forney]

On 12/27/16, Laslo Hunhold  wrote:
> I am unsure how to deal with this patch. I personally have an
> NTD-daemon running and it does all my time-manipulations. I can imagine
> that maybe manually setting your time is a good thing for debugging,
> testing, joking, whatever, but is it really worth the added complexity?
>
> What do the others think?

I think we should apply the patch because
- It is behavior specified by POSIX.
- It allows you to set your system clock without running an NTP
daemon, or without internet access.
- The patch is pretty straightforward and not too complex.

One suggestion I can think of, since the date format is simple and
uses fixed sizes, it to just parse into struct tm manually rather than
restructuring the date string into a new buffer with spaces.

For example (untested):
static int date_field(char *s, size_t i) {
  return (s[i] - '0') * 10 + (s[i+1] - '0');
}

char *s = argv[0];
tm->tm_mon = date_field(s, 0) - 1;
tm->tm_day = date_field(s, 2);
tm->tm_hour = date_field(s, 4);
tm->tm_min = date_field(s, 6);
switch (len) {
case 8:
  tm->tm_year = now->tm_year;
  break;
case 10:
  tm->tm_year = date_field(s, 8);
  if (tm->tm_year < 69)
tm->tm_year += tm->year < 69 ? 2000 : 1900;
  break;
case 12:
  tm->tm_year = date_field(s, 8) * 100 + date_field(s, 10);
  break;
}

Re: [hackers] [sbase][Patch] date: add date/time setting capability

[John Vogel]

On Tue, 27 Dec 2016 12:20:41 +0100
Laslo Hunhold  wrote:

> I am unsure how to deal with this patch. I personally have an
> NTD-daemon running and it does all my time-manipulations. I can imagine
> that maybe manually setting your time is a good thing for debugging,
> testing, joking, whatever, but is it really worth the added complexity?
> 
> What do the others think?

I need to set date during boot on my raspberrypis. Since posix specifies
setting the date with date, I thought it would be helpful to add it to
sbase. I can always supply my own date setting utility (which I do now)
if the patch is deemed to bloat the code unduly.

Re: [hackers] [sbase][PATCH] basename, dirname, printf: recognise -- and fail if options are used.

[Michael Forney]

On 12/27/16, Evan Gates  wrote:
>> I respect your opinion and have to admit that this is not an easy
>> discussion. Let's wait for some feedback and see what the others think
>> about it.
>
> I side with Mattias on this one. Accepting -- even in utilities that
> don't have flags has the benefits of 1) complying with POSIX so we can
> be a drop in replacement 2) consistency with all the other tools.

Actually, POSIX talks about '--' in guideline 10 of the Utility Syntax
Guidelines[0]

Many tools, for example cp, say

  The cp utility shall conform to XBD Utility Syntax Guidelines .

But this is not mentioned for printf. So, the current implementation
does comply with POSIX (at least in this respect).

However, I did run into an issue with musl-cross-make which was
passing '--' to printf. This has been fixed[1] in the latest release
though. Are there many other places where scripts use -- with printf?
Can we fix those instead?

[0] 
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02
[1] 
https://github.com/richfelker/musl-cross-make/commit/3ac08b98c1c947043df489a760135ccb7f8b783d

Re: [hackers] [sbase][PATCH] basename, dirname, printf: recognise -- and fail if options are used.

[Evan Gates]

On Tue, Dec 27, 2016 at 7:05 AM, Laslo Hunhold  wrote:
> On Tue, 27 Dec 2016 15:48:56 +0100
> Mattias Andrée  wrote:
>
> Hey Mattias,
>
>> Okay, I personally do not agree with this and see echo(1)
>> as an abomination, it treats any unrecognised flags as
>> strings, but if had debate on it, keep to want you agreed
>> to.

I agree echo is an abomination. Especially with POSIX saying things
like "If the first operand is -n, or if any of the operands contain a
 character, the results are implementation-defined." The
best thing we can do is not use echo in any scripts.

I think from a philosophical standpoint sbase echo should not include
-n, to be simpler and still POSIX compliant. However pragmatically
many scripts use echo -n so I think it makes sense to keep it.

>
> I respect your opinion and have to admit that this is not an easy
> discussion. Let's wait for some feedback and see what the others think
> about it.

I side with Mattias on this one. Accepting -- even in utilities that
don't have flags has the benefits of 1) complying with POSIX so we can
be a drop in replacement 2) consistency with all the other tools.

Re: [hackers] [sbase] [PATCH 11/11] tail: Process bytes with -c option, and add -m option for runes

[Evan Gates]

On Tue, Dec 27, 2016 at 5:55 AM, Laslo Hunhold  wrote:
> well-spotted! Still, it's _very_ counterintuitive to call the flag
> "-c". Instead of adding a non-portable m-flag, it would even sound
> better to me to add a b-flag for byte-offsets.
>
> It all depends on how many scripts rely on this behaviour. Can you give
> an example? I thought cut(1) was the tool of choice for extracting
> headers and such things.

I think deviating from POSIX here is a bad idea. Every deviation from
POSIX means that our tools cannot be used in another situation and
pushes prospective users away. If the user wants characters instead of
bytes we have tools to do that, don't surprise the user by doing
something different than every other implementation.

P.S. I too found -c confusing the first time I expected utf8
characters, but remembering these tools were created with ascii in
mind, I think of -c as char and it all works out...

Re: [hackers] [sbase] [patch] ed: Treat addresses of 0 as 1 for insert

[Evan Gates]

On Tue, Dec 27, 2016 at 4:31 AM, Laslo Hunhold  wrote:
> On Thu, 3 Nov 2016 15:19:35 +
> Thomas Mannay  wrote:
>
> Hey Thomas,
>
>> From 6665eaa1d2c25a95b44a4f4fb3d24a3bd5c1180f Mon Sep 17 00:00:00 2001
>> From: Thomas Mannay 
>> Date: Thu, 3 Nov 2016 15:16:32 +
>> Subject: [PATCH] Treat addresses of 0 as 1 for insert
>
> this patch looks logical to me, but what do the others say?
>
> Cheers
>
> Laslo
>
> --
> Laslo Hunhold 
>

POSIX says: "Address 0 shall be valid for this command; it shall be
interpreted as if address 1 were specified."

Re: [hackers] [sbase][PATCH] grep: remove = flag from readme

[Mattias Andrée]

On Tue, 27 Dec 2016 09:26:34 -0800
Evan Gates  wrote:

> On Tue, Dec 27, 2016 at 3:09 AM, Laslo Hunhold
>  wrote:
> > On Wed, 30 Mar 2016 19:01:16 +0200
> > Mattias Andrée  wrote:
> >
> > Hey Mattias,
> >  
> >>   $ echo äö | ./grep [å]
> >>   äö
> >>
> >> This is not want one expects from
> >> a program that supports UTF-8.  
> >
> > as a general note, we may think about adding a
> > setlocale() when we access the regex-engine. What do
> > you guys think?
> >
> > Cheers
> >
> > Laslo
> >
> > --
> > Laslo Hunhold 
> >  
> 
> Given the two options of using setlocale() or writing our
> own regex engine, I think using setlocale() is the less
> sucky solution. If we want to revisit it in the future we
> can but it'll give us working tools now.
> 

We still need a new regex-engine to support NUL bytes,
but perhaps that can be circumvented. We also need a
faster engine, currently both musl and glibc is too
slow for any serious grepping.


pgpygnwUm5fjW.pgp
Description: OpenPGP digital signature

Re: [hackers] [sbase][PATCH] ls: add -1 option to manpage

[Evan Gates]

On Tue, Dec 27, 2016 at 4:20 AM, Laslo Hunhold  wrote:
> I am not 100% sure how to approach this, but -1 effectively does not do
> anything for our ls(1), except also implicitly activating the q-flag as
> mandated by Posix.
>
> What do the others think?
>
> Cheers
>
> Laslo
>
> --
> Laslo Hunhold 
>

As far as I can tell POSIX does not mandate the q-flag for -1. All
implementations I've seen do not do so and the point of POSIX is to
describe those common implementations. I could submit a report to the
austin group list for clarification...

Re: [hackers] [sbase][PATCH] grep: remove = flag from readme

[Evan Gates]

On Tue, Dec 27, 2016 at 3:09 AM, Laslo Hunhold  wrote:
> On Wed, 30 Mar 2016 19:01:16 +0200
> Mattias Andrée  wrote:
>
> Hey Mattias,
>
>>   $ echo äö | ./grep [å]
>>   äö
>>
>> This is not want one expects from
>> a program that supports UTF-8.
>
> as a general note, we may think about adding a setlocale() when we
> access the regex-engine. What do you guys think?
>
> Cheers
>
> Laslo
>
> --
> Laslo Hunhold 
>

Given the two options of using setlocale() or writing our own regex
engine, I think using setlocale() is the less sucky solution. If we
want to revisit it in the future we can but it'll give us working
tools now.

Re: [hackers] [sbase][PATCH] Add base64(1), base32(1), and base16(1)

[Mattias Andrée]

On Tue, 27 Dec 2016 12:01:01 +0100
Laslo Hunhold  wrote:

> On Tue, 29 Mar 2016 18:59:24 +0200
> Mattias Andrée  wrote:
> 
> Hey Mattias,
> 
> what justifies the existence of base16(1), base32(1) and
> base64(1)? I think there need to be good reasons, given
> it would add almost 500 lines of code to maintain to
> sbase.
> 
> I think I am not the only one here who really appreciates
> your work on sbase. So, maybe in the future, if you plan
> on working something, maybe you could post your ideas
> here, so you are not wasting time on things that get
> rejected anyway.
> 
> Cheers
> 
> Laslo
> 

I cannot remember right now, but think it's necessary
for sbase (but that doesn't make it less code to maintain).

But I guess base64(1) can be used for obfuscation or
escaping binary data in text files.


pgpI8x4XeBqug.pgp
Description: OpenPGP digital signature

Re: [hackers] [sbase][PATCH] Add nologin(8) (from ubase) and simplify it

[Mattias Andrée]

On Tue, 27 Dec 2016 12:14:58 +0100
Laslo Hunhold  wrote:

> On Mon,  4 Apr 2016 13:22:05 +0200
> Mattias Andrée  wrote:
> 
> Hey Mattias,
> 
> >  
> 
> do we really need the option to specify an "input file"?
> Even the shadow-utils do not support an input file.

util-linux support /etc/nologin.txt, but it doesn't
look like other implementations do. I can't think of
any use case that cannot be solved better with
existing tools, so it can be removed.

> 
> Cheers
> 
> Laslo
> 



pgpTkMvtaBB00.pgp
Description: OpenPGP digital signature

Re: [hackers] [sbase][PATCH] Add tac(1)

[Mattias Andrée]

On Tue, 27 Dec 2016 16:07:01 +0100
Laslo Hunhold  wrote:

> On Tue, 27 Dec 2016 16:05:19 +0100
> Mattias Andrée  wrote:
> 
> Hey Mattias,
>  
> > I actually use tac(1) a lot, but I can't think of
> > anything I have used it for right now. However, it can
> > be used for reversing the output after sort(1), however
> > POSIX specifies -r for sort(1p) which does this, but
> > chances are your common user is not aware of this.  
> 
> but sort(1) requires sorted input, whereas tac(1) can
> operate on any input.

You sort(1) sorts the input. And yes, tac(1) is more
flexible, but that was the only use case I could think
of off the top of my head. But now I remember that I
have used it a number of times to reverse the output
of find(1) to get directories listed after the files
without the directories.

> 
> > I can't see the rationale for adding this behaviour to
> > tail(1). If it is added to tail, the flag would do two
> > things instead of one thing: reversing the output, and
> > output the entire file. It would make more sense to add
> > it to cat(1), perhaps you men to write “cat”. I would
> > think that this is a good idea, but since tac(1)
> > already exists and -r for cat(1) doesn't, I think it is
> > better to go with tac(1), but I'm flexible.  
> 
> What do the others think?
> 
> Cheers
> 
> Laslo
> 



pgpa7gSNsKEh0.pgp
Description: OpenPGP digital signature

Re: [hackers] [ubase] [PATCH] install: ignore -s

[Mattias Andrée]

On Tue, 27 Dec 2016 13:56:07 +0100
Laslo Hunhold  wrote:

> On Sat,  3 Dec 2016 12:51:14 +0100
> Mattias Andrée  wrote:
> 
> Hey Mattias,
> 
> > The -s flag previously called strip(1) on the installed
> > file. This patch changes install(1)'s behaviour to
> > ignore -s.
> > 
> > Many makefiles use the -s flag, so it has to be
> > recognised for compatibility, however it does not have
> > to do anything because symbols do not negatively affect
> > the functionallity of binaries.
> > 
> > Ignoring -s have the added benefit that the user do not
> > need to edit makefiles if they want the symbols that
> > are useful for debugging. If the user wants to strip
> > away symbols, it can be done manually or automatically
> > by the package manager.  
> 
> thanks, applied! I favor just not documenting the s-flag
> in xinstall.1, but understand both sides of the argument.
> We have many examples in sbase, like sort -m, but also as
> we can see install -c and others.
> 
> Maybe we can discuss this here. Another alternative would
> be to put that in a NOTES section. I really don't want to
> see the manpages filled up with ignored options, making
> them harder to read. On the other hand, a manpage should
> reflect the code and no matter how we put it, we do
> handle the c and s flags specially here.
> 
> Cheers
> 
> Laslo
> 

What about adding an IGNORED OPTIONS section after OPTIONS,
where it is stated what the ignored options were intended
to do, and perhaps a rationale for why it is ignored? This
way users can be sure that it is safe to use a flag and
that we will not add a behaviour to it in the future that
they did not foresee.


pgp9TFQD_MCf0.pgp
Description: OpenPGP digital signature

Re: [hackers] [sbase][PATCH] Add tac(1)

[Mattias Andrée]

On Tue, 27 Dec 2016 11:29:58 +0100
Laslo Hunhold  wrote:

> On Sat, 26 Mar 2016 12:08:28 +0100
> Mattias Andrée  wrote:
> 
> Hey Mattias,
> 
> > Signed-off-by: Mattias Andrée 
> > ---
> >  Makefile   |  1 +
> >  README |  1 +
> >  libutil/getlines.c |  3 ++-
> >  tac.1  | 20 
> >  tac.c  | 69
> > + +
> > text.h |  3 ++-  
> 
> wouldn't it be better to add the r-flag to tail(1)? I
> personally don't see tac(1) at all in the wild, but prove
> me wrong in case I'm missing something.

I actually use tac(1) a lot, but I can't think of anything
I have used it for right now. However, it can be used for
reversing the output after sort(1), however POSIX specifies
-r for sort(1p) which does this, but chances are your common
user is not aware of this.

I can't see the rationale for adding this behaviour to tail(1).
If it is added to tail, the flag would do two things instead
of one thing: reversing the output, and output the entire file.
It would make more sense to add it to cat(1), perhaps you
men to write “cat”. I would think that this is a good idea,
but since tac(1) already exists and -r for cat(1) doesn't, I
think it is better to go with tac(1), but I'm flexible.

> 
> Cheers
> 
> Laslo
> 



pgpPapyJswiXV.pgp
Description: OpenPGP digital signature

Re: [hackers] [sbase][PATCH] basename, dirname, printf: recognise -- and fail if options are used.

[Laslo Hunhold]

On Tue, 27 Dec 2016 15:48:56 +0100
Mattias Andrée  wrote:

Hey Mattias,

> Okay, I personally do not agree with this and see echo(1)
> as an abomination, it treats any unrecognised flags as
> strings, but if had debate on it, keep to want you agreed
> to.

I respect your opinion and have to admit that this is not an easy
discussion. Let's wait for some feedback and see what the others think
about it.

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase][PATCH] Improvements to sleep(1):

[Mattias Andrée]

On Tue, 27 Dec 2016 11:45:39 +0100
Laslo Hunhold  wrote:

> On Sat, 26 Mar 2016 18:31:57 +0100
> Mattias Andrée  wrote:
> 
> Hey Mattias,
> 
> > - Add support for floating pointer numbers,
> >   which you will find in other implementations.  
> 
> I do not favor this aspect, as Dimitris already
> established well.
> 
> > - Add support for suffixes [s|m|h|d], as
> >   found in GNU sleep, which is very useful.  
> 
> This is the only thing I could remotely live with, but
> this would require us to hand-fiddle with strtod() and
> have a "lookup-table" for residuums and multiplication
> factors (in seconds), e.g.
> 
>   "s" -> 1
>   "m" -> 60
>   "h" -> 60 * 60
>   "d" -> 24 * 60 * 60
> 
> and then do a
> 
>   for (... i ...) {
>   if (strcmp(endptr, lookuptable[i].str)) {
>   sleeptime *= lookuptable[i].fac
>   }
>   }
> 
> However, anything involving longer "waiting" times than 1
> hour should be done with cron(1). I assume that a naïve
> programmer would get the idea of having a rc-script that
> just idles for 24 hours in an infinite loop, and having
> flags in sleep encouraging this is not helpful to break
> this premise.
> 
> > - Add support for multiple arguments. Not
> >   really necessary, but brings compatibility
> >   at barely any cost.  
> 
> What is the purpose of this aspect?
> 
> Cheers
> 
> Laslo
> 

I have withdrawn this proposal.

But the idea of having multiple arguments is that you
can write for example “1h 30m”, of course, this is not
important is you can just as well write “90m”, and in
case where the calculations are that simple you can
use expr(1), but implementing it didn't really complicate
anything and brings compatibility.

Waits shorted that 1s is useful in things like rc-scripts
that need to wait for a short period. And longer waits
are useful in cases like if you are setting up a simple
alarm if you want to take a short rest, or if you have
a lot of things running in different terminals (because
you want to see the output of each) but you don't want
all of the to run a the same time.


pgpOf4LqtK14w.pgp
Description: OpenPGP digital signature

Re: [hackers] [ubase][PATCH] Add setsid(1) from sbase with -c added

[Mattias Andrée]

On Tue, 27 Dec 2016 12:05:37 +0100
Laslo Hunhold  wrote:

> On Tue, 29 Mar 2016 20:39:37 +0200
> Mattias Andrée  wrote:
> 
> Hey Mattias,
> 
> >  
> 
> can you give some motivation for adding the c-flag?

My sh-based getty replacement requires it.

> 
> Cheers
> 
> Laslo
> 



pgpi14s7D8bN8.pgp
Description: OpenPGP digital signature

Re: [hackers] [sbase][PATCH] test: add -E

[Mattias Andrée]

It is not use elsewhere, and I have learned that shells
implement their own version of if test(1) because they
add flags that can only be implemented inside the shell,
so adding new functionality to test(1) is meaningless
even if the functionality is useful.

On Tue, 27 Dec 2016 11:52:14 +0100
Laslo Hunhold  wrote:

> On Mon, 28 Mar 2016 23:50:42 +0200
> Mattias Andrée  wrote:
> 
> Hey Mattias,
> 
> > This is an non-standard extension.
> > 
> > It tests with a file exists, is a directory, and is
> > empty. Tests against non-existing files,
> > non-directories and non-empty directories causes exit
> > status 1.
> > 
> > It is a sane alternative to writing
> > 
> >   test -z "$(ls -A "$1")"  
> 
> I think as with any discussion about adding nonstandard
> extensions, the relevant question is wether this is
> widely used out there. Can you give some examples were it
> is used?
> 
> Cheers
> 
> Laslo
> 



pgpry0VN1CELp.pgp
Description: OpenPGP digital signature

Re: [hackers] [sbase][PATCH] basename, dirname, printf: recognise -- and fail if options are used.

[Laslo Hunhold]

On Tue, 27 Dec 2016 15:26:09 +0100
Mattias Andrée  wrote:

Hey Mattias,

> POSIX explicitly states that echo(1) shall treat “--”
> as a string operand and not as a delimiter. My guess
> is that this is for historical reason, much like the
> existence of echo(1) itself.

ah now I remember, thanks. You know, sbase takes the liberty of moving
away from Posix where consistency is a concern. In this case I think
our result from a long debate was to say: Well, we just treat "--" as a
normal string for tools that do not accept any flags.

For instance, if echo does not interpret --, why doesn't printf also
follow echo in this behaviour?

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase][PATCH] basename, dirname, printf: recognise -- and fail if options are used.

[Mattias Andrée]

On Tue, 27 Dec 2016 15:21:11 +0100
Laslo Hunhold  wrote:

> On Tue, 27 Dec 2016 15:14:44 +0100
> Mattias Andrée  wrote:
> 
> Hey Mattias,
> 
> > POSIX says “--” should be supported unless stated
> > otherwise. I interpret that standard saying that this
> > also applies utilities that do not take any flags. And
> > to be on the safe side I think it is a good idea to
> > support “--” for two reasons: (1) existing scripts may
> > require it, and (2) if POSIX adds a flag to the utility
> > in the future we must support “--” now, otherwise
> > compatibility will be broken.  
> 
> so what about "echo --"?
> 
> Cheers
> 
> Laslo
> 

POSIX explicitly states that echo(1) shall treat “--”
as a string operand and not as a delimiter. My guess
is that this is for historical reason, much like the
existence of echo(1) itself.


pgpkMrgLX4Pr4.pgp
Description: OpenPGP digital signature

Re: [hackers] [sbase][PATCH] basename, dirname, printf: recognise -- and fail if options are used.

[Laslo Hunhold]

On Tue, 27 Dec 2016 15:14:44 +0100
Mattias Andrée  wrote:

Hey Mattias,

> POSIX says “--” should be supported unless stated otherwise.
> I interpret that standard saying that this also applies utilities
> that do not take any flags. And to be on the safe side I think
> it is a good idea to support “--” for two reasons: (1) existing
> scripts may require it, and (2) if POSIX adds a flag to the
> utility in the future we must support “--” now, otherwise
> compatibility will be broken.

so what about "echo --"?

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase][PATCH] basename, dirname, printf: recognise -- and fail if options are used.

[Mattias Andrée]

On Tue, 27 Dec 2016 11:26:07 +0100
Laslo Hunhold  wrote:

> On Fri, 25 Mar 2016 21:31:37 +0100
> Mattias Andrée  wrote:
> 
> Hey Mattias,
> 
> >  basename.c |  5 -
> >  dirname.c  |  6 +-
> >  printf.c   | 12 
> >  3 files changed, 17 insertions(+), 6 deletions(-)  
> 
> I do not support this patch, as "--" only makes sense for
> tools that actually take flags.
> I pity that GNU basename(1), dirname(1) and printf(1)
> take flags, however, see great value in being able to do
> 
>   $ printf --
> 
> and get what you asked for instead of some error message
> 
>   printf: usage: printf [-v var] format [arguments]
> 
> Cheers
> 
> Laslo
> 

POSIX says “--” should be supported unless stated otherwise.
I interpret that standard saying that this also applies utilities
that do not take any flags. And to be on the safe side I think
it is a good idea to support “--” for two reasons: (1) existing
scripts may require it, and (2) if POSIX adds a flag to the
utility in the future we must support “--” now, otherwise
compatibility will be broken.


pgpNxFM3rLXhu.pgp
Description: OpenPGP digital signature

Re: [hackers] [sbase][PATCH] Remove unused parameters from libutil/concat and update all calls thereof.

[Laslo Hunhold]

On Sun, 25 Dec 2016 09:50:30 -0700
quicon...@arascio.xyz wrote:

>

Let's keep it as is. Not because of the pending patch, but because of
the general better logging abilities that might arise one day. We don't
gain anything by stripping it down so far.

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase] [PATCH 10/11] cp: Also preserve atime/mtime for symlinks

[Laslo Hunhold]

On Tue,  6 Dec 2016 02:17:02 -0800
Michael Forney  wrote:

Hey Michael,

> 

applied with a small modification. Thanks!

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase] [PATCH 04/11] Don't use buffered IO (fread) when not appropriate

[Laslo Hunhold]

On Tue,  6 Dec 2016 02:16:56 -0800
Michael Forney  wrote:

Hey Michael,

> fread reads the entire requested size (BUFSIZ), which causes tools to
> block if only small amounts of data are available at a time. At best,
> this causes unnecessary copies and inefficiency, at worst, tools like
> tee and cat are almost unusable in some cases since they only display
> large chunks of data at a time.

sbase uses FILE-pointers exclusively and mixing both "logics" is not
very helpful for the clarity of the expressed code.
The writeall() function looks like an util function that could be
introduced to completely convert sbase from fp to fd stream handling.

I think this is not the place here to discuss this, but I would be glad
if you could create a new thread here on hackers@ where you give some
examples where buffered IO is problematic.
The necessity to add functions like fshut() really made me think twice
about the advantages of buffered IO.

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase] [PATCH 11/11] tail: Process bytes with -c option, and add -m option for runes

[Laslo Hunhold]

On Tue,  6 Dec 2016 02:17:03 -0800
Michael Forney  wrote:

Hey Michael,

> POSIX says that -c specifies a number of bytes, not characters. This
> flag is commonly used by scripts that operate on binary files to do
> things like extract a header. Treating the offsets as character
> offsets will break things in mysterious ways.
> 
> Instead, add a -m option (chosen to match `wc -m`, which also operates
> on characters) to handle character offsets.
> ---
> I'm tempted to just delete the character functionality instead of
> introducing a new non-standard option. I can see the use of tail with
> codepoints, but we definitely need to make -c work on bytes so that we
> don't break scripts.
> 
> I'm also open to changing the option flag to something else. I just
> chose -m because that's what wc uses for characters.

well-spotted! Still, it's _very_ counterintuitive to call the flag
"-c". Instead of adding a non-portable m-flag, it would even sound
better to me to add a b-flag for byte-offsets.

It all depends on how many scripts rely on this behaviour. Can you give
an example? I thought cut(1) was the tool of choice for extracting
headers and such things.

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase][PATCH] paste: fix warning on indentation in parallel()

[Laslo Hunhold]

On Mon, 26 Dec 2016 16:22:36 -0800
Robert Karl  wrote:

Hey Robert,

> _Bug_
> Got the following error after cloning and running make:
> 
> paste.c: In function ‘parallel’:
> paste.c:70:4: warning: this ‘else’ clause does not guard...
> [-Wmisleading-indentation] else
> ^~~~
> paste.c:72:5: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the ‘else’ last++;
>  ^~~~
> This patch preserves the same functionality and just adjusts
> indentation to squelch the warning.
> 
> _Test plan_
> Used the following 'script' to convince myself output looked correct
> for inputs where the latter arguments to paste had fewer lines.
> 
>   make && printf "1\n2\n" > two.txt && printf "" > zero.txt
> && ./paste -d, two.txt zero.txt

good catch! I applied your patch. This probably was an artefact from
the rewrite last year.
Thanks for your contribution and well-formed patch-description.

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase] [PATCH 1/5] Remove st != NULL checks from recursor functions

[Laslo Hunhold]

On Wed, 14 Dec 2016 19:40:02 -0800
Michael Forney  wrote:

Hey Michael,

> In the description of 3111908b034c73673a2f079b2b13a88c18379baa, it
> says that the functions must be able to handle st being NULL, but
> recurse always passes a valid pointer. The only function that was
> ever passed NULL was rm(), but this was changed to go through recurse
> in 2f4ab527391135e651b256f8654b050ea4a48f3d, so now the checks are
> pointless.

have you tested this patchset extensively? I hate to admit that the
recursor-subsystem is probably the most fragile part of sbase and
really need more feedback on these patches by more people (Silvan, have
you had the chance to test this?).

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase] [PATCH] xinstall: Fix broken memmove with -t

[Laslo Hunhold]

On Thu,  1 Dec 2016 22:50:20 -0800
Michael Forney  wrote:

Hey Michael,

> memmove moves a number of bytes, not pointers, so if you passed a
> number of arguments that is larger than the pointer byte size, you
> could end up crashing or skipping the install of a file and
> installing another twice.
> 
> Also, argv was never decreased to match the moved arguments, so the -t
> parameter was added in the NULL argv slot.

after taking another look at this patch, it totally makes sense. Thanks
for your submission! I applied it, but need to note here that this is a
pretty hacky contraption. :P

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase] [PATCH 09/11] cp: Check result of utimensat

[Laslo Hunhold]

On Tue,  6 Dec 2016 02:17:01 -0800
Michael Forney  wrote:

Hey Michael,

> POSIX says that if duplicating the modification/access times fails,
> then an error should be written to stderr.

thanks, applied!

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase] [PATCH 01/11] crypt: Add some missing error checks for cryptsum

[Laslo Hunhold]

On Tue,  6 Dec 2016 02:16:53 -0800
Michael Forney  wrote:

Hey Michael,

> Previously, if a file failed to read in a checksum list, it would be
> reported as not matched rather than a read failure.
> 
> Also, if reading from stdin failed, previously a bogus checksum would
> be printed anyway.

Thanks, applied! I added a note on mdcheckline() in TODO so we don't
miss it.

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [ubase] [PATCH] install: ignore -s

[Laslo Hunhold]

On Sat,  3 Dec 2016 12:51:14 +0100
Mattias Andrée  wrote:

Hey Mattias,

> The -s flag previously called strip(1) on the installed file.
> This patch changes install(1)'s behaviour to ignore -s.
> 
> Many makefiles use the -s flag, so it has to be recognised for
> compatibility, however it does not have to do anything because
> symbols do not negatively affect the functionallity of binaries.
> 
> Ignoring -s have the added benefit that the user do not need
> to edit makefiles if they want the symbols that are useful for
> debugging. If the user wants to strip away symbols, it can be
> done manually or automatically by the package manager.

thanks, applied! I favor just not documenting the s-flag in xinstall.1,
but understand both sides of the argument. We have many examples in
sbase, like sort -m, but also as we can see install -c and others.

Maybe we can discuss this here. Another alternative would be to put
that in a NOTES section. I really don't want to see the manpages filled
up with ignored options, making them harder to read. On the other hand,
a manpage should reflect the code and no matter how we put it, we do
handle the c and s flags specially here.

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase] [PATCH 02/11] od: Fix buffer overflow if -N flag is larger than BUFSIZ

[Laslo Hunhold]

On Tue,  6 Dec 2016 02:16:54 -0800
Michael Forney  wrote:

> Previously, if max was specified, od will call read with that size,
> potentially overflowing buf with data read from the file.

Thanks, applied!

-- 
Laslo Hunhold 

Re: [hackers] [sbase] [PATCH 05/11] xinstall: Check result of fchmod

[Laslo Hunhold]

On Tue,  6 Dec 2016 02:16:57 -0800
Michael Forney  wrote:

Hey Michael,

>

good catch! Applied.

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase] [PATCH] parsemode: No need to return after eprintf

[Laslo Hunhold]

On Wed, 30 Nov 2016 23:27:59 -0800
Michael Forney  wrote:

Hey Michael,

> Also, since parsemode exits on failure, don't bother checking return
> value in xinstall (this would never trigger anyway because mode_t can
> be unsigned).

very nice! I think the legacy bit us there. I applied the patch.

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase] [patch] ed: Treat addresses of 0 as 1 for insert

[Laslo Hunhold]

On Thu, 3 Nov 2016 15:19:35 +
Thomas Mannay  wrote:

Hey Thomas,

> From 6665eaa1d2c25a95b44a4f4fb3d24a3bd5c1180f Mon Sep 17 00:00:00 2001
> From: Thomas Mannay 
> Date: Thu, 3 Nov 2016 15:16:32 +
> Subject: [PATCH] Treat addresses of 0 as 1 for insert

this patch looks logical to me, but what do the others say?

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase] [patch] remove install.1 on make uninstall

[Laslo Hunhold]

On Wed, 26 Oct 2016 14:51:55 +0200
parazyd  wrote:

Hey parazyd,

> Just a minor fix since xinstall.1 is installed as install.1

thanks, applied!

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers][sbase][ed] small changes

[Laslo Hunhold]

On Fri, 07 Oct 2016 16:32:53 +0300
"Ali H. Fardan"  wrote:

Hey Ali,

> O.o, whhops, that was the wrong patch, attached is the correct one.
> sorry for spamming the list.

I manually applied your changes with a few modifications, leaving out
the goto-removal. I loosely remember that there were plans to "change"
the error() semantics or whatnot, so maybe we should keep it like that
at first.
Also, let's still pass num to rematch().

Thanks for pointing out our use of strcpy()!

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase] [patch] ed: standards compliance, manpage, double free and infinite loop fix

[Laslo Hunhold]

On Sun, 9 Oct 2016 23:20:20 +
Thomas Mannay  wrote:

Hey Thomas,

> It took a while longer than I'd planned, but I've gone through and
> redone my patches. I found a second source of an infinite loop to do
> with joining where a variable would be -1 and the counter started at
> 0, so could never equal it. I also added a safety guard on j to
> prevent someone passing it a 0 address, which would cause a segfault.
> 
> Hopefully all's in order and my editor saved with tabs this time.

thanks for your hard work! I applied your patches and fixed a few
things with the manpage you submitted using mandoc -Tlint.

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase][PATCH] ls: add -1 option to manpage

[Laslo Hunhold]

On Fri, 21 Oct 2016 13:39:21 +0200
Petr Vaněk  wrote:

Hey Petr,

>

thing is, we always print one entry per line and expect, if people want
a columnized output, to just use cols(1) (shipped with sbase).

I am not 100% sure how to approach this, but -1 effectively does not do
anything for our ls(1), except also implicitly activating the q-flag as
mandated by Posix.

What do the others think?

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase][patch]find: copy path before using basename

[Laslo Hunhold]

On Wed, 5 Oct 2016 15:41:55 -0700
Evan Gates  wrote:

Hey Evan,

> On Mon, Oct 3, 2016 at 3:10 PM, FRIGN  wrote:
> > Please don't use VLA's. Use estrdup() in this case.
> 
> sbase-find_basename2.diff: revised patch without VLAs
> sbase-find_noVLAs.diff: path to remove all VLAs in find

thanks, applied with a few style modifications and using ereallocarray
() for overflow safety.

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase][PATCH] printf: handle \0 in %b arguments

[Laslo Hunhold]

On Mon, 24 Oct 2016 08:16:25 -0700
Evan Gates  wrote:

Hey Evan,

> The %b case was using fputs after unescape to print the argument,
> which meant that it could not handle nul bytes. Instead, store the
> length returned from unescape and use fwrite to properly handle them.

nice find! Applied, thanks!

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase] [PATCH 2/3] ed: Fix backslash expressions in RHS

[Laslo Hunhold]

On Sun, 24 Jul 2016 21:04:28 -0400
Wolfgang Corcoran-Mathe  wrote:

Hey Wolfgang,

> By stripping backslashes this code caused a number of bugs.
> '\' expressions caused literal s to be subbed-in,
> '\&' was treated identically to '&', and other escaped characters
> added garbage to the string.

that makes sense. Applied.

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase]patch: fix PHONY

[Laslo Hunhold]

On Thu, 20 Oct 2016 07:37:36 -0700
Evan Gates  wrote:

Hey Evan,

> targets must be prerequisites to PHONY, not commands

thanks, applied! Good catch.

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase] [PATCH 1/3] ed: Don't match against line 0 in search()

[Laslo Hunhold]

On Sun, 24 Jul 2016 21:04:27 -0400
Wolfgang Corcoran-Mathe  wrote:

Hey Wolfgang,

> regexec(3) happily matches /^$/ against the text of line
> zero (the null string), causing an error.

thanks, applied!

> Also update email address for Wolfgang Corcoran-Mathe

next time please put that in a separate commit.

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase][PATCH] Makefile: sort file lists

[Laslo Hunhold]

On Thu, 20 Oct 2016 09:06:18 -0700
Evan Gates  wrote:

Hey Evan,

> 

thanks, applied!

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase][Patch] date: add date/time setting capability

[Laslo Hunhold]

On Thu, 5 May 2016 15:20:35 -0400
John Vogel  wrote:

Hey John,

> From 79079cdc560d68257c110482c730ab043c7f4c0f Mon Sep 17 00:00:00 2001
> From: John Vogel 
> Date: Thu, 5 May 2016 15:01:36 -0400
> Subject: [sbase][Patch] date: add date/time setting capability

I am unsure how to deal with this patch. I personally have an
NTD-daemon running and it does all my time-manipulations. I can imagine
that maybe manually setting your time is a good thing for debugging,
testing, joking, whatever, but is it really worth the added complexity?

What do the others think?

Cheers

Laslo

-- 
Laslo Hunhold 

Re: the future of ii (was: [hackers] [PATCH] [ii] get rid of EXIT_bla crap)

[Laslo Hunhold]

On Fri, 14 Oct 2016 12:52:27 +0100
Nico Golde  wrote:

Hey Nico,

> Hiltjo Posthuma was kind enough to offer taking over the maintenance
> for this project. Thanks for that, I really appreciate this! So I'm
> leaving this change to his discretion.

so how does the future of ii look like?

@Hiltjo: What are your plans? When will you merge your ii-branch into
mainline?

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase] [PATCH 3/3] ed: Fix substitutions with non-determinate patterns

[Laslo Hunhold]

On Sun, 24 Jul 2016 21:04:29 -0400
Wolfgang Corcoran-Mathe  wrote:

Hey Wolfgang,

> Previously, greedy patterns like /.*/ overran the buffer and
> patterns with null matches (e.g. /G*/) never increased the
> offset for rematch().  In both cases, the result was an
> infinite loop.
> 
> Breaking after the first null match follows the behavior of
> GNU ed.  It has the virtue of simplicity.

so, which behaviour should we follow (looking at the discussion that
took place)? I would favor the intuïtive behaviour, but maybe there was
some feedback from the Austin ML.

In general, it's true that for 0-byte-handling, the entire architecture
needs a revamp.

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase] [patch] cp: add -i flag

[Laslo Hunhold]

On Sun, 9 Oct 2016 13:22:32 +
Thomas Mannay  wrote:

Hey Thomas,

> Ah, I had forgotten to add fs.h to the commit. Added it in this time.
> 
> I fixed the behaviour of newline as you pointed out. Should all be in
> order.

we generally frown upon interactive modes for these tools. Does your
hammer ask you every time before you hit a nail?

Joke aside, I do not favor this patch for this reason. If a user sends
off a command and overwrites files he didn't want to be overwritten, he
should've checked his usage beforehand.

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase][PATCH] grep: remove = flag from readme

[Laslo Hunhold]

On Wed, 30 Mar 2016 19:01:16 +0200
Mattias Andrée  wrote:

Hey Mattias,

>   $ echo äö | ./grep [å]
>   äö
> 
> This is not want one expects from
> a program that supports UTF-8.

as a general note, we may think about adding a setlocale() when we
access the regex-engine. What do you guys think?

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase][PATCH] [find] Better error reporting

[Laslo Hunhold]

On Fri, 10 Jun 2016 13:33:29 +0800
Ivan Tham  wrote:

Hey Ivan,

> Shows that primary or token is unknown instead of only showing that
> paths must precede expression

can you resubmit the patch with a better style? Do we really need the
comments here?

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase][PATCH] Add nologin(8) (from ubase) and simplify it

[Laslo Hunhold]

On Mon,  4 Apr 2016 13:22:05 +0200
Mattias Andrée  wrote:

Hey Mattias,

>

do we really need the option to specify an "input file"? Even the
shadow-utils do not support an input file.

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase] Remove locale-cancer from grep(1) || FRIGN

[Laslo Hunhold]

On Fri, 29 Apr 2016 12:24:18 +0100
Dimitris Papastamos  wrote:

Hey Dimitris,

> Maintain the workaround locally until we write our own regex
> engine.

I investigated a bit more and maybe we should really think about doing
the "dirty" setlocale in this context.

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase][PATCH] Add base64(1), base32(1), and base16(1)

[Laslo Hunhold]

On Tue, 29 Mar 2016 18:59:24 +0200
Mattias Andrée  wrote:

Hey Mattias,

what justifies the existence of base16(1), base32(1) and base64(1)? I
think there need to be good reasons, given it would add almost 500
lines of code to maintain to sbase.

I think I am not the only one here who really appreciates your work on
sbase. So, maybe in the future, if you plan on working something, maybe
you could post your ideas here, so you are not wasting time on things
that get rejected anyway.

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase][PATCH] Add tac(1)

[Laslo Hunhold]

On Sat, 26 Mar 2016 12:08:28 +0100
Mattias Andrée  wrote:

Hey Mattias,

> Signed-off-by: Mattias Andrée 
> ---
>  Makefile   |  1 +
>  README |  1 +
>  libutil/getlines.c |  3 ++-
>  tac.1  | 20 
>  tac.c  | 69 +
> + text.h |  3 ++-

wouldn't it be better to add the r-flag to tail(1)? I personally don't
see tac(1) at all in the wild, but prove me wrong in case I'm missing
something.

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase][PATCH] Move setsid to ubase

[Laslo Hunhold]

On Tue, 29 Mar 2016 23:13:20 +0200
Mattias Andrée  wrote:

Hey Mattias,

> The -c flag (see patch made to ubase) is not
> specified by POSIX and requires TIOCSCTTY which
> is not defined by POSIX.

I wouldn't worry about that, as any sane system offers TIOCSCTTY via
ioctl.h.
The term "portable" within sbase is a bit more "loose" than just
limiting itself to POSIX specifications. You could say that we mean
tools that are usable across Linux and *BSD systems.

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase][PATCH] Improvements to sleep(1):

[Laslo Hunhold]

On Sat, 26 Mar 2016 18:31:57 +0100
Mattias Andrée  wrote:

Hey Mattias,

> - Add support for floating pointer numbers,
>   which you will find in other implementations.

I do not favor this aspect, as Dimitris already established well.

> - Add support for suffixes [s|m|h|d], as
>   found in GNU sleep, which is very useful.

This is the only thing I could remotely live with, but this would
require us to hand-fiddle with strtod() and have a "lookup-table" for
residuums and multiplication factors (in seconds), e.g.

"s" -> 1
"m" -> 60
"h" -> 60 * 60
"d" -> 24 * 60 * 60

and then do a

for (... i ...) {
if (strcmp(endptr, lookuptable[i].str)) {
sleeptime *= lookuptable[i].fac
}
}

However, anything involving longer "waiting" times than 1 hour should
be done with cron(1). I assume that a naïve programmer would get the
idea of having a rc-script that just idles for 24 hours in an infinite
loop, and having flags in sleep encouraging this is not helpful to
break this premise.

> - Add support for multiple arguments. Not
>   really necessary, but brings compatibility
>   at barely any cost.

What is the purpose of this aspect?

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase][PATCH] test: add -E

[Laslo Hunhold]

On Mon, 28 Mar 2016 23:50:42 +0200
Mattias Andrée  wrote:

Hey Mattias,

> This is an non-standard extension.
> 
> It tests with a file exists, is a directory, and is empty.
> Tests against non-existing files, non-directories and non-empty
> directories causes exit status 1.
> 
> It is a sane alternative to writing
> 
>   test -z "$(ls -A "$1")"

I think as with any discussion about adding nonstandard extensions, the
relevant question is wether this is widely used out there.
Can you give some examples were it is used?

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [ubase][PATCH] Add setsid(1) from sbase with -c added

[Laslo Hunhold]

On Tue, 29 Mar 2016 20:39:37 +0200
Mattias Andrée  wrote:

Hey Mattias,

>

can you give some motivation for adding the c-flag?

Cheers

Laslo

-- 
Laslo Hunhold 

Re: [hackers] [sbase][PATCH] Add rev(1)

[Laslo Hunhold]

On Sat, 26 Mar 2016 17:23:03 +0100
Mattias Andrée  wrote:

Hey Mattias,

> Signed-off-by: Mattias Andrée 
> ---
>  Makefile |  1 +
>  README   |  1 +
>  rev.1| 22 +++
>  rev.c| 74 +++
> + 4 files changed, 98 insertions(+) create mode 100644 rev.1
>  create mode 100644 rev.c

nice and clean, it works! At first I thought you didn't support UTF-8,
but I gotta admit that your method to handle it is pretty elegant.
In the future, when we go forward and actually handle grapheme
clusters, we will have to act upon grapheme cluster boundaries instead,
but that requires minimal modification.

Applied.

Cheers

Laslo

-- 
Laslo Hunhold 

[hackers] [sbase] targets must be prerequisites to .PHONY not commands || Evan Gates

[git]

commit 4b5a948ceedf7c9ae7f814c5444cb8caf32d307c
Author: Evan Gates 
AuthorDate: Wed Oct 19 11:04:48 2016 -0700
Commit: Laslo Hunhold 
CommitDate: Tue Dec 27 13:15:10 2016 +0100

targets must be prerequisites to .PHONY not commands

diff --git a/Makefile b/Makefile
index 58a92a9..a2f4784 100644
--- a/Makefile
+++ b/Makefile
@@ -273,5 +273,4 @@ clean:
rm -f $(BIN) $(OBJ) $(LIB) sbase-box sbase-$(VERSION).tar.gz
rm -f getconf.h
 
-.PHONY:
-   all install uninstall dist sbase-box sbase-box-install 
sbase-box-uninstall clean
+.PHONY: all install uninstall dist sbase-box sbase-box-install 
sbase-box-uninstall clean

[hackers] [sbase] install: ignore -s || Mattias Andrée

[git]

commit 609169d60053ae94751187378303926d21f29148
Author: Mattias Andrée 
AuthorDate: Sat Dec 3 12:51:14 2016 +0100
Commit: Laslo Hunhold 
CommitDate: Tue Dec 27 13:56:27 2016 +0100

install: ignore -s

The -s flag previously called strip(1) on the installed file.
This patch changes install(1)'s behaviour to ignore -s.

Many makefiles use the -s flag, so it has to be recognised for
compatibility, however it does not have to do anything because
symbols do not negatively affect the functionallity of binaries.

Ignoring -s have the added benefit that the user do not need
to edit makefiles if they want the symbols that are useful for
debugging. If the user wants to strip away symbols, it can be
done manually or automatically by the package manager.

Laslo: Update the man-date and remove -s from usage()

Signed-off-by: Mattias Andrée 

diff --git a/xinstall.1 b/xinstall.1
index 1a727d3..8799dbb 100644
--- a/xinstall.1
+++ b/xinstall.1
@@ -1,4 +1,4 @@
-.Dd 2016-02-12
+.Dd 2016-24-27
 .Dt INSTALL 1
 .Os sbase
 .Sh NAME
@@ -12,7 +12,7 @@
 .Po
 .Fl d Ar dir ...
 |
-.Op Fl sD
+.Op Fl D
 .Po
 .Fl t Ar dest
 .Ar source ...
@@ -62,10 +62,6 @@ is copied with
 Change the installed files' owner to
 .Ar owner .
 This may be a user name or a user identifier.
-.It Fl s
-Remove unnecessary symbols using
-.Xr strip 1 .
-Failure to strip a file does not imply failure to install the file.
 .It Fl t Ar dest
 Copy files into the directory
 .Ar dest .
@@ -79,8 +75,7 @@ notation is used, the base mode is .
 .Xr chmod 1 ,
 .Xr chown 1 ,
 .Xr cp 1 ,
-.Xr mkdir 1 ,
-.Xr strip 1
+.Xr mkdir 1
 .Sh STANDARDS
 The
 .Nm
diff --git a/xinstall.c b/xinstall.c
index 38636f1..4cd5122 100644
--- a/xinstall.c
+++ b/xinstall.c
@@ -13,7 +13,6 @@
 #include "text.h"
 
 static int Dflag = 0;
-static int sflag = 0;
 static gid_t group;
 static uid_t owner;
 static mode_t mode = 0755;
@@ -41,22 +40,6 @@ make_dirs(char *dir, int was_missing)
make_dir(dir, was_missing);
 }
 
-static void
-strip(const char *filename)
-{
-   pid_t pid = fork();
-   switch (pid) {
-   case -1:
-   eprintf("fork:");
-   case 0:
-   execlp("strip", "strip", "--", filename, (char *)0);
-   eprintf("exec: strip:");
-   default:
-   waitpid(pid, NULL, 0);
-   break;
-   }
-}
-
 static int
 install(const char *s1, const char *s2, int depth)
 {
@@ -125,9 +108,6 @@ install(const char *s1, const char *s2, int depth)
eprintf("fclose %s:", s2);
if (fclose(f1) == EOF)
eprintf("fclose %s:", s1);
-
-   if (sflag)
-   strip(s2);
}
 
if (lchown(s2, owner, group) < 0)
@@ -139,7 +119,7 @@ install(const char *s1, const char *s2, int depth)
 static void
 usage(void)
 {
-   eprintf("usage: %s [-g group] [-o owner] [-m mode] (-d dir ... | [-Ds] 
(-t dest source ... | source ... dest))\n", argv0);
+   eprintf("usage: %s [-g group] [-o owner] [-m mode] (-d dir ... | [-D] 
(-t dest source ... | source ... dest))\n", argv0);
 }
 
 int
@@ -166,7 +146,7 @@ main(int argc, char *argv[])
Dflag = 1;
break;
case 's':
-   sflag = 1;
+   /* no-op for compatibility */
break;
case 'g':
gflag = EARGF(usage());
@@ -184,7 +164,7 @@ main(int argc, char *argv[])
usage();
} ARGEND
 
-   if (argc < 1 + (!tflag & !dflag) || dflag & (Dflag | sflag | !!tflag))
+   if (argc < 1 + (!tflag & !dflag) || dflag & (Dflag | !!tflag))
usage();
 
if (gflag) {

[hackers] [sbase] printf: handle \0 in %b arguments || Evan Gates

[git]

commit 123f784ccc9138ce09176cdc2d3eae23af454941
Author: Evan Gates 
AuthorDate: Mon Oct 24 08:16:25 2016 -0700
Commit: Laslo Hunhold 
CommitDate: Tue Dec 27 13:25:38 2016 +0100

printf: handle \0 in %b arguments

The %b case was using fputs after unescape to print the argument, which
meant that it could not handle nul bytes. Instead, store the length
returned from unescape and use fwrite to properly handle them.

diff --git a/printf.c b/printf.c
index 7bf6fe5..4bc645b 100644
--- a/printf.c
+++ b/printf.c
@@ -19,7 +19,7 @@ int
 main(int argc, char *argv[])
 {
Rune *rarg;
-   size_t i, j, argi, lastargi, formatlen;
+   size_t i, j, argi, lastargi, formatlen, blen;
long long num;
double dou;
int cooldown = 0, width, precision, ret = 0;
@@ -112,12 +112,12 @@ main(int argc, char *argv[])
case 'b':
if ((tmp = strstr(arg, "\\c"))) {
*tmp = 0;
-   unescape(arg);
-   fputs(arg, stdout);
+   blen = unescape(arg);
+   fwrite(arg, sizeof(*arg), blen, stdout);
return 0;
}
-   unescape(arg);
-   fputs(arg, stdout);
+   blen = unescape(arg);
+   fwrite(arg, sizeof(*arg), blen, stdout);
break;
case 'c':
unescape(arg);

[hackers] [sbase] parsemode: No need to return after eprintf || Michael Forney

[git]

commit 87f40834a329f4f526fd17b1be36c75da0323573
Author: Michael Forney 
AuthorDate: Wed Nov 30 23:27:59 2016 -0800
Commit: Laslo Hunhold 
CommitDate: Tue Dec 27 13:33:35 2016 +0100

parsemode: No need to return after eprintf

Also, since parsemode exits on failure, don't bother checking return
value in xinstall (this would never trigger anyway because mode_t can be
unsigned).

diff --git a/libutil/mode.c b/libutil/mode.c
index 365b9ad..187c7a3 100644
--- a/libutil/mode.c
+++ b/libutil/mode.c
@@ -1,3 +1,4 @@
+/* See LICENSE file for copyright and license details. */
 #include 
 #include 
 #include 
@@ -23,10 +24,8 @@ parsemode(const char *str, mode_t mode, mode_t mask)
 
octal = strtol(str, , 8);
if (*end == '\0') {
-   if (octal < 0 || octal > 0) {
+   if (octal < 0 || octal > 0)
eprintf("%s: invalid mode\n", str);
-   return -1;
-   }
mode = 0;
if (octal & 04000) mode |= S_ISUID;
if (octal & 02000) mode |= S_ISGID;
@@ -78,7 +77,6 @@ next:
break;
default:
eprintf("%s: invalid mode\n", str);
-   return -1;
}
 
perm = 0;
diff --git a/xinstall.c b/xinstall.c
index bf921fb..70d7097 100644
--- a/xinstall.c
+++ b/xinstall.c
@@ -215,11 +215,8 @@ main(int argc, char *argv[])
owner = getuid();
}
 
-   if (mflag) {
+   if (mflag)
mode = parsemode(mflag, mode, 0);
-   if (mode < 0)
-   return 1;
-   }
 
if (tflag) {
memmove(argv - 1, argv, argc);

[hackers] [sbase] ed: Use strlcpy() instead of strcpy() and other minor things || Laslo Hunhold

[git]

commit e2f886c7e225a38113d3b332a106d176721fa5c3
Author: Laslo Hunhold 
AuthorDate: Tue Dec 27 13:07:02 2016 +0100
Commit: Laslo Hunhold 
CommitDate: Tue Dec 27 13:07:02 2016 +0100

ed: Use strlcpy() instead of strcpy() and other minor things

Based on contribution by Ali H. Fardan, thanks!

diff --git a/ed.c b/ed.c
index 17b925b..72248ab 100644
--- a/ed.c
+++ b/ed.c
@@ -322,7 +322,7 @@ inject(char *s, int j)
 }
 
 static void
-clearbuf()
+clearbuf(void)
 {
if (scratch)
close(scratch);
@@ -334,7 +334,7 @@ clearbuf()
 }
 
 static void
-setscratch()
+setscratch(void)
 {
int r, k;
char *dir;
@@ -421,6 +421,7 @@ rematch(int num)
lastmatch += off;
return 1;
}
+
return 0;
 }
 
@@ -547,7 +548,7 @@ invalid:
 }
 
 static void
-getlst()
+getlst(void)
 {
int ln, c;
 
@@ -595,7 +596,7 @@ deflines(int def1, int def2)
 }
 
 static void
-dowrite(char *fname, int trunc)
+dowrite(const char *fname, int trunc)
 {
FILE *fp;
int i, line;
@@ -610,13 +611,14 @@ dowrite(char *fname, int trunc)
curln = line2;
if (fclose(fp))
error("input/output error");
-   strcpy(savfname, fname);
+   if (strlcpy(savfname, fname, sizeof(savfname)) >= sizeof(savfname))
+   error("file name too long");
modflag = 0;
curln = line;
 }
 
 static void
-doread(char *fname)
+doread(const char *fname)
 {
size_t cnt;
ssize_t n;
@@ -741,9 +743,11 @@ getfname(char comm)
} else {
*bp = '\0';
if (savfname[0] == '\0' || comm == 'e' || comm == 'f')
-   strcpy(savfname, fname);
+   if (strlcpy(savfname, fname, sizeof(savfname)) >= 
sizeof(savfname))
+   error("file name too long");
return fname;
}
+
return NULL; /* not reached */
 }
 

[hackers] [sbase] cp: Check result of utimensat || Michael Forney

[git]

commit e03a57df92f92a4388f7b78bcf3ce4bb46f39e66
Author: Michael Forney 
AuthorDate: Tue Dec 6 02:17:01 2016 -0800
Commit: Laslo Hunhold 
CommitDate: Tue Dec 27 14:46:11 2016 +0100

cp: Check result of utimensat

POSIX says that if duplicating the modification/access times fails, then
an error should be written to stderr.

diff --git a/libutil/cp.c b/libutil/cp.c
index c398962..7d4c174 100644
--- a/libutil/cp.c
+++ b/libutil/cp.c
@@ -156,8 +156,10 @@ cp(const char *s1, const char *s2, int depth)
if (!S_ISLNK(st.st_mode)) {
times[0] = st.st_atim;
times[1] = st.st_mtim;
-   utimensat(AT_FDCWD, s2, times, 0);
-
+   if (utimensat(AT_FDCWD, s2, times, 0) < 0) {
+   weprintf("utimensat %s:", s2);
+   cp_status = 1;
+   }
if (chown(s2, st.st_uid, st.st_gid) < 0) {
weprintf("chown %s:", s2);
cp_status = 1;

[hackers] [sbase] od: Fix buffer overflow if -N flag is larger than BUFSIZ || Michael Forney

[git]

commit 5e4e6aeb3ee843f1fb1bc3de1c2e682f20c61625
Author: Michael Forney 
AuthorDate: Tue Dec 6 02:16:54 2016 -0800
Commit: Laslo Hunhold 
CommitDate: Tue Dec 27 14:32:04 2016 +0100

od: Fix buffer overflow if -N flag is larger than BUFSIZ

Previously, if max was specified, od will call read with that size,
potentially overflowing buf with data read from the file.

diff --git a/od.c b/od.c
index 9b83501..27a7104 100644
--- a/od.c
+++ b/od.c
@@ -129,23 +129,25 @@ od(FILE *fp, char *fname, int last)
 {
static unsigned char *line;
static size_t lineoff;
-   size_t i;
-   unsigned char buf[BUFSIZ];
static off_t addr;
-   size_t buflen;
+   unsigned char buf[BUFSIZ];
+   size_t i, n, size = sizeof(buf);
 
while (skip - addr > 0) {
-   buflen = fread(buf, 1, MIN(skip - addr, BUFSIZ), fp);
-   addr += buflen;
+   n = fread(buf, 1, MIN(skip - addr, sizeof(buf)), fp);
+   addr += n;
if (feof(fp) || ferror(fp))
return;
}
if (!line)
line = emalloc(linelen);
 
-   while ((buflen = fread(buf, 1, max >= 0 ?
-  max - (addr - skip) : BUFSIZ, fp))) {
-   for (i = 0; i < buflen; i++, addr++) {
+   for (;;) {
+   if (max >= 0)
+   size = MIN(max - (addr - skip), size);
+   if (!(n = fread(buf, 1, size, fp)))
+   break;
+   for (i = 0; i < n; i++, addr++) {
line[lineoff++] = buf[i];
if (lineoff == linelen) {
printline(line, lineoff, addr - lineoff + 1);

[hackers] [sbase] cp: Also preserve atime/mtime for symlinks || Michael Forney

[git]

commit 24810426519a002749016cbb04e6c21cd2d890cb
Author: Michael Forney 
AuthorDate: Tue Dec 27 14:49:57 2016 +0100
Commit: Laslo Hunhold 
CommitDate: Tue Dec 27 14:50:58 2016 +0100

cp: Also preserve atime/mtime for symlinks

Laslo: Fixed style a bit and added comment

diff --git a/libutil/cp.c b/libutil/cp.c
index 7d4c174..9bb517a 100644
--- a/libutil/cp.c
+++ b/libutil/cp.c
@@ -152,14 +152,16 @@ cp(const char *s1, const char *s2, int depth)
}
 
if (cp_aflag || cp_pflag) {
-   /* timestamp and owner */
+   /* atime and mtime */
+   times[0] = st.st_atim;
+   times[1] = st.st_mtim;
+   if (utimensat(AT_FDCWD, s2, times, AT_SYMLINK_NOFOLLOW) < 0) {
+   weprintf("utimensat %s:", s2);
+   cp_status = 1;
+   }
+
+   /* owner */
if (!S_ISLNK(st.st_mode)) {
-   times[0] = st.st_atim;
-   times[1] = st.st_mtim;
-   if (utimensat(AT_FDCWD, s2, times, 0) < 0) {
-   weprintf("utimensat %s:", s2);
-   cp_status = 1;
-   }
if (chown(s2, st.st_uid, st.st_gid) < 0) {
weprintf("chown %s:", s2);
cp_status = 1;

[hackers] [sbase] paste: fix warning on indentation in parallel() || Robert Karl

[git]

commit 60da4fb049eb1168331d0754e34519af3627a2e8
Author: Robert Karl 
AuthorDate: Mon Dec 26 16:22:36 2016 -0800
Commit: Laslo Hunhold 
CommitDate: Tue Dec 27 15:02:15 2016 +0100

paste: fix warning on indentation in parallel()

_Bug_
Got the following error after cloning and running make:

paste.c: In function ‘parallel’:
paste.c:70:4: warning: this ‘else’ clause does not guard... 
[-Wmisleading-indentation]
else
^~~~
paste.c:72:5: note: ...this statement, but the latter is misleadingly 
indented as if it is guarded by the ‘else’
 last++;
 ^~~~
This patch preserves the same functionality and just adjusts indentation to 
squelch the warning.

_Test plan_
Used the following 'script' to convince myself output looked correct for 
inputs
where the latter arguments to paste had fewer lines.

make && printf "1\n2\n" > two.txt && printf "" > zero.txt && ./paste 
-d, two.txt zero.txt

diff --git a/paste.c b/paste.c
index 77fc090..1d4e9f6 100644
--- a/paste.c
+++ b/paste.c
@@ -69,7 +69,7 @@ nextline:
putchar('\n');
else
efputrune(, stdout, "");
-   last++;
+   last++;
}
}
if (last != -1)

[hackers] [sbase] Makefile: sort file lists || Evan Gates

[git]

commit d6154bd87fd04616852a286c7fd09efb4cdbfa85
Author: Evan Gates 
AuthorDate: Thu Oct 20 09:06:18 2016 -0700
Commit: Laslo Hunhold 
CommitDate: Tue Dec 27 13:16:53 2016 +0100

Makefile: sort file lists

diff --git a/Makefile b/Makefile
index a2f4784..a1d5353 100644
--- a/Makefile
+++ b/Makefile
@@ -23,10 +23,6 @@ HDR =\
 
 LIBUTF = libutf.a
 LIBUTFSRC =\
-   libutf/rune.c\
-   libutf/runetype.c\
-   libutf/utf.c\
-   libutf/utftorunestr.c\
libutf/fgetrune.c\
libutf/fputrune.c\
libutf/isalnumrune.c\
@@ -41,7 +37,11 @@ LIBUTFSRC =\
libutf/istitlerune.c\
libutf/isxdigitrune.c\
libutf/lowerrune.c\
-   libutf/upperrune.c
+   libutf/rune.c\
+   libutf/runetype.c\
+   libutf/upperrune.c\
+   libutf/utf.c\
+   libutf/utftorunestr.c
 
 LIBUTIL = libutil.a
 LIBUTILSRC =\
@@ -113,8 +113,8 @@ BIN =\
getconf\
grep\
head\
-   join\
hostname\
+   join\
kill\
link\
ln\
@@ -130,8 +130,8 @@ BIN =\
nl\
nohup\
od\
-   pathchk\
paste\
+   pathchk\
printenv\
printf\
pwd\

[hackers] [sbase] ed: giving j only one address does nothing || Thomas Mannay

[git]

commit 696520714b185ad111b33232dc2d94c281729832
Author: Thomas Mannay 
AuthorDate: Sun Oct 9 23:11:01 2016 +
Commit: Laslo Hunhold 
CommitDate: Tue Dec 27 12:50:09 2016 +0100

ed: giving j only one address does nothing

diff --git a/ed.c b/ed.c
index c4cce37..ff619d8 100644
--- a/ed.c
+++ b/ed.c
@@ -1169,9 +1169,8 @@ repeat:
case 'j':
chkprint(1);
deflines(curln, curln+1);
-   if (!line1)
-   goto bad_address;
-   join();
+   if (line1 != line2 && curln != 0)
+   join();
break;
case 'z':
if (nlines > 1)

[hackers] [sbase] remove install.1 on make uninstall || parazyd

[git]

commit aded9028919a819407ec633473d320e689f2fdb9
Author: parazyd 
AuthorDate: Tue Dec 27 13:29:15 2016 +0100
Commit: Laslo Hunhold 
CommitDate: Tue Dec 27 13:30:08 2016 +0100

remove install.1 on make uninstall

Just a minor fix since xinstall.1 is installed as install.1.

diff --git a/Makefile b/Makefile
index a1d5353..9ec9990 100644
--- a/Makefile
+++ b/Makefile
@@ -223,7 +223,7 @@ install: all
 
 uninstall:
cd $(DESTDIR)$(PREFIX)/bin && rm -f $(BIN) [ install
-   cd $(DESTDIR)$(MANPREFIX)/man1 && rm -f $(MAN)
+   cd $(DESTDIR)$(MANPREFIX)/man1 && rm -f $(MAN) install.1
 
 dist: clean
mkdir -p sbase-$(VERSION)

[hackers] [sbase] ed: Don't match against line 0 in search() || Wolfgang Corcoran-Mathe

[git]

commit f5baf2630ab0cf51306bb94311e7eed84caa730d
Author: Wolfgang Corcoran-Mathe 
AuthorDate: Sun Jul 24 21:04:27 2016 -0400
Commit: Laslo Hunhold 
CommitDate: Tue Dec 27 12:28:36 2016 +0100

ed: Don't match against line 0 in search()

regexec(3) happily matches /^$/ against the text of line
zero (the null string), causing an error.

Also update email address for Wolfgang Corcoran-Mathe

diff --git a/LICENSE b/LICENSE
index 6c0fc52..c86f70d 100644
--- a/LICENSE
+++ b/LICENSE
@@ -58,6 +58,6 @@ Authors/contributors include:
 © 2015 Tai Chi Minh Ralph Eastwood 
 © 2015 Quentin Rameau 
 © 2015 Dionysis Grigoropoulos 
-© 2015 Wolfgang Corcoran-Mathe 
+© 2015 Wolfgang Corcoran-Mathe 
 © 2016 Mattias Andrée 
 © 2016 Eivind Uggedal 
diff --git a/ed.c b/ed.c
index 184ed30..0cf9fb9 100644
--- a/ed.c
+++ b/ed.c
@@ -426,7 +426,7 @@ search(int way)
i = curln;
do {
i = (way == '?') ? prevln(i) : nextln(i);
-   if (match(i))
+   if (i > 0 && match(i))
return i;
} while (i != curln);
 

[hackers] [sbase] xinstall: Check result of fchmod || Michael Forney

[git]

commit a8a9b3bae9b021c328db27f426dcaf90e01ca030
Author: Michael Forney 
AuthorDate: Tue Dec 6 02:16:57 2016 -0800
Commit: Laslo Hunhold 
CommitDate: Tue Dec 27 14:37:20 2016 +0100

xinstall: Check result of fchmod

diff --git a/xinstall.c b/xinstall.c
index 4cd5122..d0069be 100644
--- a/xinstall.c
+++ b/xinstall.c
@@ -102,7 +102,8 @@ install(const char *s1, const char *s2, int depth)
}
concat(f1, s1, f2, s2);
 
-   fchmod(fileno(f2), mode);
+   if (fchmod(fileno(f2), mode) < 0)
+   eprintf("fchmod %s:", s2);
 
if (fclose(f2) == EOF)
eprintf("fclose %s:", s2);

[hackers] [sbase] Add rev(1) || Mattias Andrée

[git]

commit 28129a87c4db31cd43f0e4289e68587f2a01127e
Author: Mattias Andrée 
AuthorDate: Sat Mar 26 17:23:03 2016 +0100
Commit: Laslo Hunhold 
CommitDate: Tue Dec 27 11:35:27 2016 +0100

Add rev(1)

Signed-off-by: Mattias Andrée 

diff --git a/Makefile b/Makefile
index 25bab70..58a92a9 100644
--- a/Makefile
+++ b/Makefile
@@ -137,6 +137,7 @@ BIN =\
pwd\
readlink\
renice\
+   rev\
rm\
rmdir\
sed\
diff --git a/README b/README
index d60d8fc..da2e500 100644
--- a/README
+++ b/README
@@ -66,6 +66,7 @@ The following tools are implemented:
 0=*|o pwd .
 0=*|x readlink.
 0=*|o renice  .
+0#* x rev .
 0=*|o rm  (-i)
 0=*|o rmdir   .
  #sed .
diff --git a/rev.1 b/rev.1
new file mode 100644
index 000..d30c850
--- /dev/null
+++ b/rev.1
@@ -0,0 +1,22 @@
+.Dd 2016-03-26
+.Dt REV 1
+.Os sbase
+.Sh NAME
+.Nm rev
+.Nd reverse each line
+.Sh SYNOPSIS
+.Nm
+.Op Ar file ...
+.Sh DESCRIPTION
+.Nm
+reads each
+.Ar file
+in sequence and writes it to stdout, but
+with all characters in each line in reverse
+order. If no
+.Ar file
+is given
+.Nm
+reads from stdin.
+.Sh SEE ALSO
+.Xr tac 1
diff --git a/rev.c b/rev.c
new file mode 100644
index 000..2d89df1
--- /dev/null
+++ b/rev.c
@@ -0,0 +1,74 @@
+/* See LICENSE file for copyright and license details. */
+#include 
+#include 
+#include 
+
+#include "text.h"
+#include "util.h"
+
+static void
+usage(void)
+{
+   eprintf("usage: %s [file ...]\n", argv0);
+}
+
+static void
+rev(FILE *fp)
+{
+   static char *line = NULL;
+   static size_t size = 0;
+   size_t i;
+   ssize_t n;
+   int lf;
+
+   while ((n = getline(, , fp)) > 0) {
+   lf = n && line[n - 1] == '\n';
+   i = n -= lf;
+   for (n = 0; i--;) {
+   if ((line[i] & 0xC0) == 0x80) {
+   n++;
+   } else {
+   fwrite(line + i, 1, n + 1, stdout);
+   n = 0;
+   }
+   }
+   if (n)
+   fwrite(line, 1, n, stdout);
+   if (lf)
+   fputc('\n', stdout);
+   }
+}
+
+int
+main(int argc, char *argv[])
+{
+   FILE *fp;
+   int ret = 0;
+
+   ARGBEGIN {
+   default:
+   usage();
+   } ARGEND
+
+   if (!argc) {
+   rev(stdin);
+   } else {
+   for (; *argv; argc--, argv++) {
+   if (!strcmp(*argv, "-")) {
+   *argv = "";
+   fp = stdin;
+   } else if (!(fp = fopen(*argv, "r"))) {
+   weprintf("fopen %s:", *argv);
+   ret = 1;
+   continue;
+   }
+   rev(fp);
+   if (fp != stdin && fshut(fp, *argv))
+   ret = 1;
+   }
+   }
+
+   ret |= fshut(stdin, "") | fshut(stdout, "");
+
+   return ret;
+}

[hackers] [sbase] ed: remove double free in join() || Thomas Mannay

[git]

commit 30da327fbd27eee508c5492a763ea19d7cd9e281
Author: Thomas Mannay 
AuthorDate: Sun Oct 9 23:13:13 2016 +
Commit: Laslo Hunhold 
CommitDate: Tue Dec 27 12:50:25 2016 +0100

ed: remove double free in join()

diff --git a/ed.c b/ed.c
index a9aacf1..17b925b 100644
--- a/ed.c
+++ b/ed.c
@@ -809,9 +809,8 @@ join(void)
int i;
char *t, c;
size_t len = 0, cap = 0;
-   static char *s;
+   char *s;
 
-   free(s);
for (s = NULL, i = line1;; i = nextln(i)) {
for (t = gettxt(i); (c = *t) != '\n'; ++t)
s = addchar(*t, s, , );

[hackers] [sbase] ed: place newly joined lines correctly || Thomas Mannay

[git]

commit 2304df908c2f0741fb72c6d03e1f45fffdf69649
Author: Thomas Mannay 
AuthorDate: Sun Oct 9 23:12:46 2016 +
Commit: Laslo Hunhold 
CommitDate: Tue Dec 27 12:50:20 2016 +0100

ed: place newly joined lines correctly

diff --git a/ed.c b/ed.c
index ff619d8..a9aacf1 100644
--- a/ed.c
+++ b/ed.c
@@ -299,13 +299,17 @@ undo(void)
 }
 
 static void
-inject(char *s)
+inject(char *s, int j)
 {
int off, k, begin, end;
 
-   begin = getindex(curln);
-   end = getindex(nextln(curln));
-
+   if (j) {
+   begin = getindex(curln-1);
+   end = getindex(nextln(curln-1));
+   } else {
+   begin = getindex(curln);
+   end = getindex(nextln(curln));
+   }
while (*s) {
k = makeline(s, );
s += off;
@@ -636,7 +640,7 @@ doread(char *fname)
s[n-1] = '\n';
s[n] = '\0';
}
-   inject(s);
+   inject(s, 0);
}
if (optdiag)
printf("%zu\n", cnt);
@@ -753,7 +757,7 @@ append(int num)
while (getline(, , stdin) > 0) {
if (*s == '.' && s[1] == '\n')
break;
-   inject(s);
+   inject(s, 0);
}
free(s);
 }
@@ -818,7 +822,7 @@ join(void)
s = addchar('\n', s, , );
s = addchar('\0', s, , );
delete(line1, line2);
-   inject(s);
+   inject(s, 1);
free(s);
 }
 
@@ -845,7 +849,7 @@ copy(int where)
curln = where;
 
for (i = line1; i <= line2; ++i)
-   inject(gettxt(i));
+   inject(gettxt(i), 0);
 }
 
 static void
@@ -1020,7 +1024,7 @@ subline(int num, int nth)
addpost(, , );
delete(num, num);
curln = prevln(num);
-   inject(s);
+   inject(s, 0);
 }
 
 static void

[hackers] [sbase] find: estrdup before basename || Evan Gates

[git]

commit 0b27c0c9a08ac4fd23a8753f2a3ba8672cd94497
Author: Evan Gates 
AuthorDate: Wed Oct 5 15:37:34 2016 -0700
Commit: Laslo Hunhold 
CommitDate: Tue Dec 27 12:37:57 2016 +0100

find: estrdup before basename

"The basename() function may modify the string pointed to by path..."
Thanks POSIX

Laslo: Changed the style a bit

diff --git a/find.c b/find.c
index 5f75735..fb6f21e 100644
--- a/find.c
+++ b/find.c
@@ -229,7 +229,14 @@ static struct {
 static int
 pri_name(struct arg *arg)
 {
-   return !fnmatch((char *)arg->extra.p, basename(arg->path), 0);
+   int ret;
+   char *path;
+
+   path = estrdup(arg->path);
+   ret = !fnmatch((char *)arg->extra.p, basename(path), 0);
+   free(path);
+
+   return ret;
 }
 
 static int

[hackers] [sbase] find: remove VLAs || Evan Gates

[git]

commit d2bd40a5890dbedef265228701cc42ac96219262
Author: Evan Gates 
AuthorDate: Wed Oct 5 15:34:52 2016 -0700
Commit: Laslo Hunhold 
CommitDate: Tue Dec 27 12:46:06 2016 +0100

find: remove VLAs

Laslo: Use ereallocarray and fix the style a bit

diff --git a/find.c b/find.c
index fb6f21e..e095015 100644
--- a/find.c
+++ b/find.c
@@ -777,7 +777,7 @@ find_op(char *name)
 static void
 parse(int argc, char **argv)
 {
-   struct tok infix[2 * argc + 1], *stack[argc], *tok, *rpn, *out, **top;
+   struct tok *tok, *rpn, *out, **top, *infix, **stack;
struct op_info *op;
struct pri_info *pri;
char **arg;
@@ -785,6 +785,9 @@ parse(int argc, char **argv)
size_t ntok = 0;
struct tok and = { .u.oinfo = find_op("-a"), .type = AND };
 
+   infix = ereallocarray(NULL, 2 * argc + 1, sizeof(*infix));
+   stack = ereallocarray(NULL, argc, sizeof(*stack));
+
gflags.print = 1;
 
/* convert argv to infix expression of tok, inserting in *tok */
@@ -894,6 +897,9 @@ parse(int argc, char **argv)
 
toks = rpn;
root = *top;
+
+   free(infix);
+   free(stack);
 }
 
 /* for a primary, run and return result
@@ -932,8 +938,11 @@ find(char *path, struct findhist *hist)
DIR *dir;
struct dirent *de;
struct findhist *f, cur;
-   size_t len = strlen(path) + 2; /* null and '/' */
+   size_t namelen, pathcap = 0, len;
struct arg arg = { path, , { NULL } };
+   char *p, *pathbuf = NULL;
+
+   len = strlen(path) + 2; /* \0 and '/' */
 
if ((gflags.l || (gflags.h && !hist) ? stat(path, ) : lstat(path, 
)) < 0) {
weprintf("failed to stat %s:", path);
@@ -975,18 +984,20 @@ find(char *path, struct findhist *hist)
}
 
while (errno = 0, (de = readdir(dir))) {
-   size_t pathcap = len + strlen(de->d_name);
-   char pathbuf[pathcap], *p;
-
if (!strcmp(de->d_name, ".") || !strcmp(de->d_name, ".."))
continue;
-
+   namelen = strlen(de->d_name);
+   if (len + namelen > pathcap) {
+   pathcap = len + namelen;
+   pathbuf = erealloc(pathbuf, pathcap);
+   }
p = pathbuf + estrlcpy(pathbuf, path, pathcap);
if (*--p != '/')
estrlcat(pathbuf, "/", pathcap);
estrlcat(pathbuf, de->d_name, pathcap);
find(pathbuf, );
}
+   free(pathbuf);
if (errno) {
weprintf("readdir %s:", path);
closedir(dir);

[hackers] [sbase] ed: remove infinite loops in join() and getindex() || Thomas Mannay

[git]

commit 61e06396bdea2352b602a46a2ff7fcd627d073cb
Author: Thomas Mannay 
AuthorDate: Sun Oct 9 23:10:20 2016 +
Commit: Laslo Hunhold 
CommitDate: Tue Dec 27 12:50:03 2016 +0100

ed: remove infinite loops in join() and getindex()

diff --git a/ed.c b/ed.c
index 582a5a2..c4cce37 100644
--- a/ed.c
+++ b/ed.c
@@ -192,7 +192,9 @@ getindex(int line)
struct hline *lp;
int n;
 
-   for (n = 0, lp = zero; n != line; ++n)
+   if (line == -1)
+   line = 0;
+   for (n = 0, lp = zero; n != line; n++)
lp = zero + lp->next;
 
return lp - zero;
@@ -806,9 +808,11 @@ join(void)
static char *s;
 
free(s);
-   for (s = NULL, i = line1; i <= line2; i = nextln(i)) {
+   for (s = NULL, i = line1;; i = nextln(i)) {
for (t = gettxt(i); (c = *t) != '\n'; ++t)
s = addchar(*t, s, , );
+   if (i == line2)
+   break;
}
 
s = addchar('\n', s, , );

Re: [hackers] [sbase][PATCH] Add shuf(1)

[Mattias Andrée]

On Tue, 27 Dec 2016 11:32:32 +0100
Laslo Hunhold  wrote:

> On Sat, 26 Mar 2016 13:50:47 +0100
> Mattias Andrée  wrote:
> 
> Hey Mattias,
> 
> > +static int
> > +random_byte_file(void)
> > +{
> > +   unsigned char r;
> > +   ssize_t n = read(source, , 1);
> > +   if (n < 0)
> > +   eprintf("read %s:", sflag);
> > +   if (!n)
> > +   eprintf("read %s: end of file
> > reached\n");
> > +   return r;
> > +}
> > +
> > +static int
> > +random_byte_libc(void)
> > +{
> > +   double r;
> > +   r = rand();
> > +   r /= (double)RAND_MAX + 1;
> > +   r *= 256;
> > +   return (int)r;
> > +}  
> 
> is there a good reason for the existence of shuf(1)?
> Also, we may want to think about using more solid
> interfaces for randomness (like arc4random()) and remove
> the "file-source" altogether.
> 
> Cheers
> 
> Laslo
> 

Hi Laslo!

No, we don't really need shuf(1) in sbase, but I think we
should have a suckless implementation available, it can be
a useful utility. I have a few more utilities I fund useful
but I haven't bothered to set up a repository yet. I tried
to start a discussion with Dimitris some time ago, but I
didn't get a response. I think it might be a good idea to
have sextra for portable utilities and uextra for unportable
utilities, if you have any other suggestions I would like
to hear them.

For sextra I have written base16(1), base32(1), base64(1),
prune(1) which recursively removes empty directories, rev(1)
and shuf(1). For uextra I have written fsize(1) which
print the size of any regular file or block device (other
do not print the size of block devices so it can be quite
burdensome to find out how large one is), printenvx(1) which
is like printenv(1) but for other processes, and shred(1),
and I'm working on rescue(1) which is similar to ddrescue(1).

I'm not sure that arc4random() is portable, but my
understanding is that each bit in the output of rand()
have the same entropy in modern libc implementations, and
that is all that is needed in my opinion. I don't know
whether it is a good to include reading random data from
files, so it should probably be removed.


Mattias Andrée



pgpx8wQCYP9j2.pgp
Description: OpenPGP digital signature

Re: [hackers] [sbase][PATCH] Add shuf(1)

[Laslo Hunhold]

On Sat, 26 Mar 2016 13:50:47 +0100
Mattias Andrée  wrote:

Hey Mattias,

> +static int
> +random_byte_file(void)
> +{
> + unsigned char r;
> + ssize_t n = read(source, , 1);
> + if (n < 0)
> + eprintf("read %s:", sflag);
> + if (!n)
> + eprintf("read %s: end of file reached\n");
> + return r;
> +}
> +
> +static int
> +random_byte_libc(void)
> +{
> + double r;
> + r = rand();
> + r /= (double)RAND_MAX + 1;
> + r *= 256;
> + return (int)r;
> +}

is there a good reason for the existence of shuf(1)? Also, we may want
to think about using more solid interfaces for randomness
(like arc4random()) and remove the "file-source" altogether.

Cheers

Laslo

-- 
Laslo Hunhold