Paul:
Good question from you.
for executables I used
$ find . -executable -print
at the root level "/" on my hard drive hosting the linux OS (using root
permissions)
Then I had to filter these by doing a
file {found name} to actually narrow to the executable
Example:
localhost:/home/owner/math/Diophantine/m-tuples # file nex
nex: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=a51414fed84b7f7c3229756342b3ae0b30abc182, for GNU/Linux
3.2.0, with debug_info, not stripped
I only consider the ELF executable as the actual file which needed
documentation.
Hope this answers your question?
Randall
On 3/23/24 08:24, Paul Heinlein wrote:
On Fri, 22 Mar 2024, American Citizen wrote:
A few years ago, I took my Linux OS which is openSuse Leap v15.3 or
so and ran a check on the documentation such as the man1 through man9
pages (run the %man man command to pull all this up) versus the
actual executables on the system.
I was surprised to find < 15% of the command executables were
documented. Naturally I was hoping for something like 50% to 75%.
If I am going to talk to an AI program, such as ChatBot or one of the
newer popular AI program and ask it to generate the documentation for
the complete OS, what AI chatbot would you choose?
My idea is to clue the AI program into the actual OS, then ask it to
finish documenting 100% of all the executables, or report to me all
executables which have no available documentation at all, period.
I'd be interested to know your definition of "command executables." Is
it everything in /bin, /usr/bin, /sbin, and /usr/sbin, with perhaps
/usr/libexec thrown in for good measure? If not, can you provide your
criteria for inclusion?
Presumably, you ruled out all hard and symbolic links, and you
accounted for documentation in Texinfo format, not just man pages.
I have no hands-on AI experience, but I do offer couple alternative
strategies that might assist:
First, try invoking each executable with common help options: -h,
--help, -?, or even 'help' itself. If there's good output, I suspect
you could pipe it into txt2man or a similar utility to generate a
basic man page.
Second, on rpm-based systems, the package might catalog other
documentation (likely, but not necessarily, in /usr/share/doc). The
shell-ish logic to unwrap this might be something like
for PROG in /usr/bin/* /usr/sbin/*; do
# rule out symlinks, though this is debatable
if test -L $PROG; then continue; fi
# see if rpm thinks a package owns $PROG
PKG=$(rpm -qf $PROG 2>/dev/null)
# if so, do a cursory look for documentation
if test -n "$PKG"; then
rpm -qd $PKG | grep -i $PROG
fi
done
The "grep" in there might be a bit limiting, but "rpm -qd" can be
quite verbose for some packages. Season to taste.
