Bug 223526 - man(1) expands page names which contains wildcards
Summary: man(1) expands page names which contains wildcards
Status: Closed FIXED
Alias: None
Product: Documentation
Classification: Unclassified
Component: Manual Pages (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-08 11:41 UTC by Wolfram Schneider
Modified: 2024-10-26 13:23 UTC (History)
4 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Wolfram Schneider freebsd_committer freebsd_triage 2017-11-08 11:41:48 UTC 
I tried to search a manpage with an asterix and surprisely it returns a manpage.

The man(1) page says:

SYNOPSIS
     man  [mansect] page ...



$ man -w 'm*n'
/usr/share/man/man1/man.1.gz

$ man -a -w '*[nM]*[nN]*'
/usr/share/man/man1/continue.1.gz
/usr/local/man/man1/FvwmBanner.1.gz
/usr/local/lib/perl5/5.24/perl/man/man1/perlintern.1.gz
/usr/share/man/man8/ancontrol.8.gz
/usr/local/man/man8/avahi-dnsconfd.8.gz
/usr/share/man/man2/clock_nanosleep.2.gz
/usr/share/man/man3/ATOMIC_VAR_INIT.3.gz
/usr/local/man/man3/CURLINFO_NUM_CONNECTS.3.gz
/usr/share/openssl/man/man3/ASN1_TIME_print.3.gz
/usr/local/lib/erlang/man/man3/CosEventChannelAdmin.3
/usr/local/lib/perl5/site_perl/man/man3/Authen::NTLM.3.gz
/usr/local/lib/perl5/5.24/perl/man/man3/CPAN::HandleConfig.3.gz
/usr/share/man/man4/acpi_panasonic.4.gz
/usr/share/man/man5/dhclient.conf.5.gz
/usr/local/man/man5/avahi-daemon.conf.5.gz
/usr/share/man/man6/banner.6.gz
/usr/share/man/man7/environ.7.gz
/usr/local/man/man7/ALTER_DOMAIN.7.gz
/usr/local/lib/erlang/man/man7/SNMP-COMMUNITY-MIB.7
/usr/share/man/man9/DB_COMMAND.9.gz



On debian I get a result as expected:

$ man -w 'm*n'
No manual entry for m*n
Comment 1 Gordon Tetlow freebsd_committer freebsd_triage 2017-12-04 17:23:04 UTC 
Not sure if I would really call this a bug. I would have to check the old man implementation to see if the behavior was the same.

Just curious, is this really an issue that's worth solving? We specifically do things with globbing when searching for manpages, so it's unlikely this would be easily solved.
Comment 2 Baptiste Daroussin freebsd_committer freebsd_triage 2017-12-04 17:41:41 UTC 
I agree with Gordon here
Comment 3 Wolfram Schneider freebsd_committer freebsd_triage 2017-12-05 19:08:35 UTC 
I'm using man(1) for more than 2 decades. I was not aware that man(1) is using pattern matching for a page. Lesson learned. At least this is surprising, not what I expected. Looking at the results, they are often random and make less sense.

I see no reference in the man(1) manpage about regex, glob or pattern matching for a page. Did I miss something here?
Comment 4 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:49:39 UTC 
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Comment 5 Mark Linimon freebsd_committer freebsd_triage 2024-10-10 22:10:42 UTC 
^Triage: committer's bit was taken into safekeeping some time ago.

With bugmeister hat, I'm going to close this as there does not seem to be
anything actionable here.
Comment 6 Wolfram Schneider freebsd_committer freebsd_triage 2024-10-26 13:23:23 UTC 
(In reply to Mark Linimon from comment #5)

I don't understand what you mean with "committer's bit was taken into safekeeping some time ago".

Anyway, the issue is fixed and I get the expected results now:

man -w 'm*n'
No manual entry for "m*n"

man -a -w '*[nM]*[nN]*'
No manual entry for "*[nM]*[nN]*"