On Sat, 09 Aug 2025 12:55:28 +0000, [email protected] wrote:
> August 8, 2025 at 5:24 PM, "Dan" <[email protected]
> mailto:[email protected]?to=%22Dan%22%20%3Cdan%40nnnne-o-o-o.com%3E
>> wrote:
>
>
>
>>
>> Try it yourself, pls
>>
>> wiz# man /usr/lib/libform.so.6.0
>>
>> the result could vary according to the shell binary sup
>>
>> Dan
>>
>> ------
>> Blog: https://bsd.gaoxio.com/ - Repo: https://code.5mode.com/
>>
>> Please reply to the mailing-list, leveraging technical stuff.
>
>
> I'm lost....what does that command do?
Best guess: man defaults to -l if given a bare filename (man -l
produces identical output), so man mandoc, and we discover that if you
pass garbage (binary content instead of a file containing mandoc
instructions), what you get out is expected: it dumps it unprocessed to
$PAGER. To test: got a text file in $HOME? man $HOME/txtfilename. man
-l $HOME/txtfilename. mandoc $HOME/txtfilename. This won't work with a
barename, though ./ works fine.
Ingo, would it be worth noting in man man, that if given a path (a
'name' containing one or more path separators), that it will assume you
meant "look at this mandoc file over here" [and if they meant "give me
documentation on what's in this library here, I dunno how to
strings(1)" just let them look at the binary slop until they get tired
(well, some people can actually read that mess, so it might be useful
during recovery that somehow ate everything from a-l* in bin or
/usr/bin, improbable as that seems)]. It might actually already be
there, mind, and I simply overlooked it. I was looking for things that
would conceptually accept a pathname instead of a name, and skipping
over most of the rest.
Verification: note that output for an unmodified input is consistent
for man /path/file.name, man -l /path/file.name, and considering the
greater compactness of avoiding the pager, mandoc /path/file.name.
Amy!
--
Amelia A. Lewis amyzing {at} talsever.com
A hundred thousand lemmings can't be wrong.
