After thinking about my observation last night, it dawned on me that the
script has to reach down
through the directory structure of the host computer before negotiating the
directory structure of
the flash drive. Let's articulate that structure in the scripts as though
they were being run from
arbitrary working directories:
grep -f /home/george/Desktop/May2020/nMapScans/Pattern-File-A.txt
/home/george/FlashDrive/...4 steps.../Target-File-A.txt > Output-File-A.txt
versus the unsuccessful script:
grep -f
/home/george/Desktop/January2020/DataSets/MB/Multi-addressed-HNs/Counts/Pattern-File-C.txt
/home/george/FlashDrive/...4 steps.../Target-File-B.txt > Output-File-B.txt
and after moving the target file:
cd /home/george/Desktop/January2020/DataSets/MB/Multi-addressed-HNs/Counts ;
grep -f Pattern-File-C.txt Target-File-B.txt > Output-File-C.txt
Analogously to moving a multi-gigabyte file:
mv hugefileA.txt /home/george/someplaceelse/folderB/folderC/hugefileA.txt
which takes just the blink of an eye so long as the move takes place within
the file structure of
the storage medium, all that really matters is the number of characters in
the path statement.
The multi-megabyte target file moved in just a few blinks of an eye and can
be moved back to its
flash drive just as quickly ... I actually copied the file, so I can just
delete it and then
clear the trash file.
In the present case it was painfully obvious that the unsuccessful script
wasn't inaccurate or
noisy but plainly wholly unsuccessful instead, as the output file was the
exact same size as the
target file. This is not a bug; it's a feature that is necessary for an
historic or practical
reason, whatever that may be.
