build: fix dependencies of man/sha*sum.1

Although the above man pages depend on src/md5sum.c as a shared
source, the build of the man pages directly requires their own
executables to exist.

* man/local.mk (man/sha1sum.1): Change the dependency from
'src/md5sum' to 'src/sha1sum'.
(man/sha224sum.1): s/md5sum/sha224sum/
(man/sha256sum.1): s/md5sum/sha256sum/
(man/sha384sum.1): s/md5sum/sha384sum/
(man/sha512sum.1): s/md5sum/sha512sum/

Reported by Pádraig Brady in
http://lists.gnu.org/archive/html/coreutils/2013-11/msg00006.html
maint: simplify printing of md5sum file names

* src/md5sum.c (main): Add a comment as to why we continue
to escape names that do not have '\n' but do have '\\' chars.
(print_filename): Use the predetermined boolean to decide
whether to escape or not, so that in the common case we
can output the file name directly, rather than inspecting each char.
* tests/misc/md5sum.pl: Add case to show '\\' chars cause escaping.
* tests/misc/sha1sum.pl: Likewise.
md5sum, sha*sum: improve help for --check related options

* src/md5sum.c (usage): s/three/four/ in the message pertaining
to the --check related options.  Also clarify that --strict
is just significant for the formatting of the checksum lines.
Also since we're changing both strings, move the --strict description
in with the description of the other options and order alphabetically.
* THANKS.in: Added reporter: Daniel Mach
shred: enable direct I/O when possible

Commit v5.92-1057-g43d487b introduced a regression
in coreutils 6.0 where it removed the page alignment
of the buffer to write, thus disabling direct I/O.
We want to use direct I/O when possible to avoid
impacting the page cache at least, as we know we don't
want to cache the data we're writing.

* src/shred.c (dopass): Allocate the buffer on the heap,
while using a more general calculation to allow to have
the output size independent from the fillpattern() size
constraint of a multiple of 3.  Also we dispense with the
union as it's no longer needed given we're aligning on
a page boundary and thus don't need to explicitly handle
uint32_t alignment.
shred: write larger chunks when possible

* src/shred.c (dopass): When not needing to write periodic patterns,
use a 64KiB block size to reduce the number of write system calls.
cp: fix --link regarding the dereferencing of symbolic links

* src/copy.c (create_hard_link): Add a bool 'dereference' parameter,
and pass AT_SYMLINK_FOLLOW as 'flags' to linkat() when dereference
is true.
(should_dereference): Add new 'bool' function to determine if a
file should be dereferenced or not.
(copy_internal): Use the above new should_dereference() and remember
its return value in a new local bool 'dereference' variable.  Use that
in all three calls to create_hard_link().
* src/cp.c (main): after parsing the options, if x.dereference is
still DEFEF_UNDEFINED and the x.recursive is true, then only set
x.dereference to DEREF_NEVER iff --link was not specified.
* doc/coreutils.texi (cp invocation): Mention that cp(1) does not
follow symbolic links in the source when --link is specified.
Likewise in the description of the -R option when used together with
that option.
* tests/cp/same-file.sh: Adapt the expected results for the -fl,
the -bl and the -bfl tests.
* tests/cp/link-deref.sh: Add a new test.
* tests/local.mk (all_tests): Reference the above new test.
* NEWS (Changes in behavior): Mention the change.

This fixes http://bugs.gnu.org/15173

Co-authored-by: Bernhard Voelker <mail@bernhard-voelker.de>
shred: fix direct I/O failures for last write to file

Since direct I/O is now enabled with commit v8.21-139-gebaf961
we must handle the case where we write an odd size at the
end of a file (with --exact), or we specify an odd --size that
is larger than 64KiB, or in the very unlikely case of a device
with an odd size.  This issue was present since direct I/O
support was first added in v5.3.0, but latent since v6.0.
Theoretically this could have also been an issue after that on
systems which didn't have alignment constraints, but did have
size constraints for direct I/O.

* src/shred.c (dopass): On the first pass for a file, always
retry a write that fails with EINVAL, so we handle direct I/O
failure at either the start or end of the file.  Adjust the comment
as the original case is out of date and implicitly handled
by this more general fix.
* tests/misc/shred-exact.sh: Add a test case.
* NEWS: Add a "bug fix" entry for shred since there are
two related issues now fixed.
shred: increase I/O block size for periodic pattern case

* src/shred.c (dopass): In the periodic pattern case increase the
I/O block size from 12KiB to 60KiB (also a multiple of 3 and 4096).
* NEWS: Adjust accordingly.
shred: avoid data write pass with --size=0

* src/shred.c (dopass): Exit early to avoid redundant heap
allocation, and more importantly avoiding a file sync
when we're writting no data, as this can have side effects.
Also with --verbose, this avoids printing of "pass status"
which could be confusing as to whether data was actually written.
* tests/misc/shred-passes.sh: Ensure the status for data
passes are not written when not doing any data writes.
base64: improve encoding I/O efficiency

Since the I/O overhead is significant to the relatively
simple processing done by this utility, use fputs() rather
than fputc() to output '\n'.
Time to process a 100MiB file was measured to
decrease from 0.417s to 0.383s, i.e. an 8% improvement.

Related to these changes, is a processing improvement in
gnulib, which increases throughput by 60% when processing
full buffers, which improves processing of a 100MiB file
with standard wrapped output, down to 0.256s.
http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commit;h=43fd1e7b

Also increase the encoding buffer size from 3 to 30KiB.
This was seen to give a further 8% improvement, taking
processing time down to 0.235s in the wrapped output case.
The decoding size buffer is not adjusted,
due to the noted caveat with --ignore-garbage.

* src/base64.c (BLOCKSIZE): Split into ENC_ and DEC_ variants,
with the former increased from 3KiB to 30KiB.
(wrap_write): Use the simpler fputc() rather than fputs()
to output the '\n' character.  Also check against EOF
rather than < 0 for errors.
(do_encode): Likewise.
* NEWS: Mention the large increase in performance, which
with the I/O improvements in coreutils and the processing
improvement in gnulib, amount to about a 60% throughput increase.
stty: add support for mark/space parity

This adds support for using a constant or "stick" parity bit.

* src/stty.c (usage): Mention the new flag.
* tests/misc/stty.sh: Adjust for the new flag.
* NEWS: Mention the improvement.
* docs/coreutils.texi (stty invocation): Mention the new flag.
tests: fix false rm -I test failure when run as root

Fix a recent regression introduced in commit v8.21-127-g5ee7d8f

Also related to this is the recent query about root run `rm -I`
ignoring the mode bits of a file: https://bugzilla.redhat.com/1013171

* tests/rm/interactive-once.sh: Avoid the messages and
corresponding file presence checks with write protected files
when running as root.