shred: move help strings to markdown files

src/uu/shred/shred.md

@@ -0,0 +1,47 @@
+# shred
+
+<!-- spell-checker:ignore writeback -->
+
+```
+shred [OPTION]... FILE...
+```
+
+Overwrite the specified FILE(s) repeatedly, in order to make it harder for even
+very expensive hardware probing to recover the data.
+
+## After help
+
+Delete FILE(s) if `--remove` (`-u`) is specified.  The default is not to remove
+the files because it is common to operate on device files like /dev/hda, and
+those files usually should not be removed.
+
+CAUTION: Note that shred relies on a very important assumption: that the file
+system overwrites data in place.  This is the traditional way to do things, but
+many modern file system designs do not satisfy this assumption.  The following
+are examples of file systems on which shred is not effective, or is not
+guaranteed to be effective in all file system modes:
+
+ * log-structured or journal file systems, such as those supplied with
+   AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)
+
+ * file systems that write redundant data and carry on even if some writes
+   fail, such as RAID-based file systems
+
+ * file systems that make snapshots, such as Network Appliance's NFS server
+
+ * file systems that cache in temporary locations, such as NFS
+   version 3 clients
+
+ * compressed file systems
+
+In the case of ext3 file systems, the above disclaimer applies (and shred is
+thus of limited effectiveness) only in `data=journal` mode, which journals file
+data in addition to just metadata.  In both the `data=ordered` (default) and
+`data=writeback` modes, shred works as usual. Ext3 journal modes can be changed
+by adding the `data=something` option to the mount options for a particular
+file system in the `/etc/fstab` file, as documented in the mount man page (`man
+mount`).
+
+In addition, file system backups and remote mirrors may contain copies of
+the file that cannot be removed, and that will allow a shredded file to be
+recovered later.

src/uu/shred/src/shred.rs

@@ -6,7 +6,7 @@
 // * For the full copyright and license information, please view the LICENSE
 // * file that was distributed with this source code.
 
-// spell-checker:ignore (words) writeback wipesync
+// spell-checker:ignore (words) wipesync
 
 use clap::{crate_version, Arg, ArgAction, Command};
 use rand::prelude::SliceRandom;
@@ -21,9 +21,8 @@ use std::os::unix::fs::PermissionsExt;
 use std::path::{Path, PathBuf};
 use uucore::display::Quotable;
 use uucore::error::{FromIo, UResult, USimpleError, UUsageError};
-#[cfg(unix)]
 use uucore::libc::S_IWUSR;
-use uucore::{format_usage, show, show_if_err, util_name};
+use uucore::{format_usage, help_about, help_section, help_usage, show, show_if_err, util_name};
 
 // This block size seems to match GNU (2^16 = 65536)
 const BLOCK_SIZE: usize = 1 << 16;
@@ -189,47 +188,9 @@ impl BytesWriter {
     }
 }
 
-static ABOUT: &str = "Overwrite the specified FILE(s) repeatedly, in order to make it harder\n\
-for even very expensive hardware probing to recover the data.
-";
-const USAGE: &str = "{} [OPTION]... FILE...";
-
-static AFTER_HELP: &str =
-    "Delete FILE(s) if --remove (-u) is specified.  The default is not to remove\n\
-     the files because it is common to operate on device files like /dev/hda,\n\
-     and those files usually should not be removed.\n\
-     \n\
-     CAUTION: Note that shred relies on a very important assumption:\n\
-     that the file system overwrites data in place.  This is the traditional\n\
-     way to do things, but many modern file system designs do not satisfy this\n\
-     assumption.  The following are examples of file systems on which shred is\n\
-     not effective, or is not guaranteed to be effective in all file system modes:\n\
-     \n\
-     * log-structured or journal file systems, such as those supplied with\n\
-     AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)\n\
-     \n\
-     * file systems that write redundant data and carry on even if some writes\n\
-     fail, such as RAID-based file systems\n\
-     \n\
-     * file systems that make snapshots, such as Network Appliance's NFS server\n\
-     \n\
-     * file systems that cache in temporary locations, such as NFS\n\
-     version 3 clients\n\
-     \n\
-     * compressed file systems\n\
-     \n\
-     In the case of ext3 file systems, the above disclaimer applies\n\
-     and shred is thus of limited effectiveness) only in data=journal mode,\n\
-     which journals file data in addition to just metadata.  In both the\n\
-     data=ordered (default) and data=writeback modes, shred works as usual.\n\
-     Ext3 journal modes can be changed by adding the data=something option\n\
-     to the mount options for a particular file system in the /etc/fstab file,\n\
-     as documented in the mount man page (man mount).\n\
-     \n\
-     In addition, file system backups and remote mirrors may contain copies\n\
-     of the file that cannot be removed, and that will allow a shredded file\n\
-     to be recovered later.\n\
-     ";
+const ABOUT: &str = help_about!("shred.md");
+const USAGE: &str = help_usage!("shred.md");
+const AFTER_HELP: &str = help_section!("after help", "shred.md");
 
 pub mod options {
     pub const FORCE: &str = "force";