vfs/shell: Add more send/append methods

[tuffnatty]

Proposed changes

This patch adds more receive methods to send/append scripts, according to what's available, with the following priorities:

1. If dd supports iflag=fullblock, a POSIX 2004 option, dd iflag=fullblock is used to avoid partial network/pipe reads.
2. If head supports -c option and does not consume the rest of the input, head -c is used as the simplest option.
3. If Perl is available (we arrive here on SunOS 5.8+), it can be used as well.
4. The last resort is the original pre-iflag=fullblock dd prone to short reads. This condition is detected and reported by the test scripts, as it manifests in having to call dd repeatedly a lot of times.

• Requires: vfs/shell: handle remote errors on send #5157.

Checklist

• I have referenced the issue(s) resolved by this PR (if any)
• I have signed-off my contribution with git commit --amend -s
• Lint and unit tests pass locally with my changes (make indent && make check)
• I have added tests that prove my fix is effective or that my feature works
• I have added the necessary documentation (if appropriate)

[ossilator]

please don't post PRs that have inter-dependencies. it's extremely hard to follow these.
if the commits are independent, then keep them in separate branches (you can use tools that support "stacked branches" to manage this conveniently).
if the commits are dependent, then just keep them in the same PR. at least as far as i'm concerned, the unit of interest is the commit, not the PR, so it's fine to lump together changes that are only mildly related.

[tuffnatty]

Then I have another suggestion: if a contributor has put some non-negligible amount of work in splitting his change to a logical patch series, don't force-squash the PR on merging (force-squashing seems to be the policy in this repo).

[ossilator]

yes, absolutely.
i thought we changed the default a while ago? force-squashing is supposed to be used only when the PR is a mess the contributor is not willing to clean up themselves.

[tuffnatty]

Ah, ok then. But this functionality does not really belong in the scope of #5157, although is dependent on it. So I guess I just had to wait until #5157 gets merged, and only submit this PR then. I'll just let it hang here for now. Sorry!

[tuffnatty]

P.S. This is a separate branch, which is branched off the other PR's branch. I have never dealt with "stacked branches" software, does it offer something different?

[ossilator]

the most basic implementation i'm aware of is https://git.sr.ht/~krobelus/git-branchstack .
my own gpush script does pretty much the same, but targeting gerrit instead of github (adding support for the latter would be certainly possible).
there are other tools that work with "proper" branches, but work hard to keep them correctly stacked, e.g. https://github.com/arxanas/git-branchless, https://github.com/abhinav/git-spice, and about a dozen others.
https://github.com/jj-vcs/jj is a somewhat more radical take on the matter.

complementary to that, TIL that github nowadays actually supports stacked PRs natively (when the repo enables it), which makes what you did totally legit when used correctly. https://github.com/github/gh-stack is supposed to help with that.

[tuffnatty]

@ossilator Thanks, I'll have a look!

[zyv]

Then I have another suggestion: if a contributor has put some non-negligible amount of work in splitting his change to a logical patch series, don't force-squash the PR on merging (force-squashing seems to be the policy in this repo).

I'm very confused about this. I don't think we ever squashed upon merging, especially if the patch set is organized as a logical series of commits. The normal current process is to rebase on top of master to get a linear history and merge the entire patch set with the merge commit. Is there any specific instance I should be aware of? Thank you.

[tuffnatty]

@zyv My bad. Probably I had some other project in mind.