Files tree

For a number of reasons I am looking for a way of recording a list of the files (and file-like objects) on a Unix system at certain points in time. The main output would simply be sorted text with one fully-qualified file name on each line.
What follows is my first attempt at it. I'd appreciate any feedback on whether I am going about it the right way or whether it could be improved either in concept or in coding.
There are two tiny scripts. In the examples below they write to temporary files f1 and f2 to test the mechanism but the idea is that the reports would be stored in timestamped files so that comparisons between one report and another could be made later.
The first, and primary, script generates nothing other than names and is as follows.
export LC_ALL=C
sudo find /\
  -path "/proc/*" -prune -o\
  -path "/run/*" -prune -o\
  -path "/sys/*" -prune -o\
  -path "/tmp/*/*" -prune -o\
  -print0 | sort -z | tr '\0' '\n' > /tmp/f1
You'll see I made some choices such as to omit files from /proc but not from /dev, for example, to record any lost+found contents, to record mounted filesystems, to show just one level of /tmp, etc.
I am not sure I coded the command right albeit that it seems to work on test cases.
The output from that starts with lines such as
/
/bin
/boot
/boot/System.map-5.15.0-101-generic
/boot/System.map-5.15.0-102-generic
...etc...
Such a form would be ideal for input to grep and diff to look for relevant files that have been added or removed between any two runs.
The second, and less important, part is to store (in a separate file) info about each of the file names as that may be relevant in some cases. That takes the first file as input and has the following form.
cat /tmp/f1 |\
  tr '\n' '\0' |\
  xargs -0 sudo ls -ld > /tmp/f2
The output from that is such as
drwxr-xr-x  23 root   root         4096 Apr 13  2023 /
lrwxrwxrwx   1 root   root            7 Mar  7  2023 /bin -> usr/bin
drwxr-xr-x   3 root   root         4096 Apr 11 11:30 /boot
...etc...
As for run times, if anyone's interested, despite the server I ran this on having multiple locally mounted filesystems and one NFS the initial tests ran in 90 seconds to generate the first file and 5 minutes to generate the second, which would mean (as long as no faults are found) that it would be no problem to run at least the first script whenever required. Other than that, I'd probably also schedule both to run each night.
That's the idea. As I say, comments, advice and criticisms on the idea or on the coding would be appreciated!
--
James Harris