Very minor nits, ok to ignore.

Excuse me, but I only have stylistic questions.

Absolutely.

Correct me if I'm wrong but since we're downstream, we want both this and D23944 to get pushed upstream first?

First of all, sorry about this - I believe I caused this issue by bumping WARNS to default without first testing the change with gcc. I have now installed gcc9 in order to test future changes like this, in the hope that I can avoid making mess like this.

In D30341#727179, @phil wrote:

I haven't tested it, but I imagine many people would like to use this, me included.

@tavianator_tavianator.com this worked for me, could you check?

atf_test_case find_depth_error
find_depth_error_head()
{
	atf_set "descr" "Verifies that unreadable directories are still " \
	    "reported in -depth mode"
	atf_set "require.user" "unprivileged"
}
find_depth_error_body()
{
	atf_check -s exit:0 mkdir -p test/dir
	atf_check -s exit:0 chmod -r test

Looks good to me.

Swim or surrender!

The message, if it is to become a commit message, could use some word-smithing. Here's my try at improving it:

@0mp do you plan to work on this?

@jhb wrote:

Should we only support decimal since that is what humanize_number(3) generates?

My answer would be a no. Input might come from elsewhere and this is true for code that possibly exists now and also code that might be written in the future.

Should we support negative numbers?

It would be a nice feature, but seems out of scope of this change.

One more question, should we fail for trailing garbage? I think we should but we don't currently.

I think we should, as it seems that a consumer would still be able to accept the result regardless (by reading num and ignoring the returned -1). But I'd suggest doing that via separate review/commit in order avoid blocking this one.

This appears to have been committed as 46a6b5c4513e6e32e5ee7104ac97b8352d466805.

Would you like to add some tests to cp_test.sh?

I thought about this more and I have a question. What should the result of ps -uxaa -U $(id -un) be? Should it only list my processes (-U) or all of them (-a)? I think we might need an additional change like this:

Looks good to me.

While these are simila to snprintf, it's not ultimately helpful to say they are the same.

Looks good to me.

Added a test to find_test.sh. The test fails when run as root though.

In D31706#715350, @bapt wrote:

In D31706#715342, @jilles wrote:

OK, but perhaps this fix should be in libedit instead. The same issue can be seen in other libedit clients such as ftp(1).

my plan is to first commit in sh(1) and have behaving correctly, then I will work on fixing libedit. (and discuss with upstream) for sure I will drop those lines from sh(1) once they are in libedit for long enough.

I thought about this problem more. I think it would satisfy all scenarios if we made the history save dependent on whether the load was successful or not. Something similar to this (compiled, untested):

I may be confused about tests and suits, but I think we have our own test suite for indent which NetBSD has taken and modified together with the program - and it seems to be coming back like a boomerang with this differential. I think theirs are not compatible unless we take in their changes. And it may be problematic, because I remember thinking that some of their changes would have to be improved before importing back to FreeBSD.

I made some stylistic changes and rebased this patch on top of it. I also modified it to clear color (especially background color) before newlines.
Are you OK with me committing your change like this?

By the way, since this is in histedit(), the binding won't survive bind -e which ultimately does keymacro_reset() and the binding from histedit() never get the chance to be restored. I think bindcmd() should call histedit() somewhere near the INTON. histedit() should be clever enough to do only the if (el) { part that is expanded in this patch.

#0  keymacro_reset (el=el@entry=0x800a41000) at /usr/src/contrib/libedit/keymacro.c:165
#1  0x000000080028e30d in map_init_emacs (el=el@entry=0x800a41000) at /usr/src/contrib/libedit/map.c:1068
#2  0x000000080028eae1 in map_bind (el=0x800a41000, argc=1, argv=<optimized out>) at /usr/src/contrib/libedit/map.c:1296
#3  0x000000080028f1eb in el_wparse (el=<optimized out>, el@entry=0x800a41000, argc=argc@entry=2, argv=0x800ad12a0) at /usr/src/contrib/libedit/parse.c:130
#4  0x000000080028624a in el_parse (el=0x800a41000, argc=argc@entry=2, argv=<optimized out>, argv@entry=0x800aa3480) at /usr/src/contrib/libedit/eln.c:97
#5  0x00000000002166dd in bindcmd (argc=2, argv=0x800aa3480) at /usr/src/bin/sh/histedit.c:557

And I'm leaning towards never being the default here, like in ls(1).