From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) by fantadrom.bsd.lv (OpenSMTPD) with ESMTP id c316a130 for ; Sat, 29 Dec 2018 20:59:01 -0500 (EST) Received: by mail-ed1-f44.google.com with SMTP id d39so20289056edb.12 for ; Sat, 29 Dec 2018 17:59:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:sender:date:from:to:subject:mime-version :content-disposition:user-agent; bh=0NeVEv56SmPL1aZZgNeQn4FL1zIane+ZSZKhoeg3g68=; b=ovTxj8qva3ZT8CD6B0a9gfTph7rAgPo1wB3ImQIkvE6nkcu6yYbU/sDr/twkebegW0 C2cIPr3tgiOZSUoK9YxvsP7eAqVBy4Zokp6NtkMmA1yuGEy4byB/NMyfQo3bsmWOdSyo hKx5gAwfCXnI7XXRZFxvztY2BgDt3fYWMUnd1SGj4tIMFbIqgJnH162jkNtaRb3pwQFO WumAdP7dGgJ/bpSX9KIgB9icyl4cVidD9UkmKS27DoNBSZ4h6m2SDYfEMTOmozqVnCYi WbpTmY+BTj32dtDIeHTTA4uwoUmWhXQbnHPd1v0xbLmPxDEiFVxYzDvBIUT0kUXfVpXY opdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:sender:date:from:to:subject :mime-version:content-disposition:user-agent; bh=0NeVEv56SmPL1aZZgNeQn4FL1zIane+ZSZKhoeg3g68=; b=FEFjxlRaQ00rXEc2nDIh8BCX8Md5+2D/VKzTmS9I1ocLoPTyjKVAtQUia4qFafotuk VqAgtnDH5F+EbeG6ExFA5fg2ZReuzpZHlzJ2XWyDbaojs+0VmviU85BqBJIp0aj/E6pp HD7nLJTnNYt5pHteS4h1ONmzZXP6s9SETLonHGJRjVlW1pR5lfGykg57AGGOHR7Zoalh Bb7pl9Q8zSUhGcGAK3SLNGPa4r+3+St+aK6CxGGkbLLkV/Nk6M51L4oULVf49RHMPTdq W/jwy9iMMNIfCt3pIEtMtnLqRpQngikGLsJzXlnfyCH25PO/4mTp1GpSOXCCb6cDjBES lgNw== X-Gm-Message-State: AA+aEWZyzNLZxO4M8MFdPxPYMzAPmkXuka5Qs5xJglUrI9U80q67o76k 25IC1CUD4Mx5GClqNyE46VytsdLVo9w= X-Google-Smtp-Source: AFSGD/V+doWdsXLjfBtzvNSv9dTFUnbjlWFmGZ8Iyuyq34gZmWsBIZO9f1TiTxRc1cy4mshuQCZM7w== X-Received: by 2002:a50:97f3:: with SMTP id f48mr26805018edb.271.1546135139882; Sat, 29 Dec 2018 17:58:59 -0800 (PST) Received: from localhost ([2602:ae:1f04:9600:da71:b6f0:bbaf:b9bf]) by smtp.gmail.com with ESMTPSA id e51sm13821873edd.35.2018.12.29.17.58.58 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 29 Dec 2018 17:58:59 -0800 (PST) Message-ID: <5c282663.1c69fb81.e8260.65b6@mx.google.com> Sender: John McKay Date: Sun, 30 Dec 2018 01:25:59 +0000 From: John McKay To: discuss@mandoc.bsd.lv Subject: Arch Linux Improvements X-Mailinglist: mandoc-discuss Reply-To: discuss@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.11.1 (2018-12-01) The man-pages package in Arch Linux has two versions of the manual page for several topics. One is the version from the Linux man-pages project and the other is from the POSIX reference. For example /usr/share/man/man3/freeaddrinfo.3p.gz /usr/share/man/man3/getaddrinfo.3.gz both contain entries for freeaddrinfo(3). This causes two difficulties when using mandoc on Arch Linux. The first is that if you type man freeaddrinfo it pulls up the POSIX version. The POSIX versions of the pages are typically not what you want as they have less detail and don't always match the implementation described in the other page. The second difficulty is that even if you specify man -s 3 freeaddrinfo it still brings up the POSIX version. While fixing the first difficulty seems to be non-trivial (I have a patch that works for me, but it's a bit of a hack and not portable to other systems), the second difficulty seems much easier to fix. I have attached a patch below. The cause is twofold. In dbadd_mlink it adds the page both with the section that is found in the containing folder and also the section that is found by scanning the file name. Also, in lstmatch the section names are compared using strcasestr. By only adding the page using the file name's section and changing lstmatch to use strcasecmp the search by section allows you to find the correct version of the page. There are two side effects. If you have a manual page that's in the correct folder but is named wrong you can no longer find it if you search by section. You also cannot truncate the architecture name when searching by architecture. None of the manual pages on my system have names that don't match the folder they are in. I never search by architecture so I don't know if it's common to shorten the name. Any comments are greatly appreciated, especially concerning a fix for the order that it uses to find the result shown. Index: mandocdb.c =================================================================== RCS file: /cvs/mandoc/mandocdb.c,v retrieving revision 1.261 diff -c -u -r1.261 mandocdb.c --- mandocdb.c 14 Dec 2018 01:18:26 -0000 1.261 +++ mandocdb.c 29 Dec 2018 23:15:01 -0000 @@ -2022,7 +2022,7 @@ dbadd_mlink(const struct mlink *mlink) { dba_page_alias(mlink->mpage->dba, mlink->name, NAME_FILE); - dba_page_add(mlink->mpage->dba, DBP_SECT, mlink->dsec); dba_page_add(mlink->mpage->dba, DBP_SECT, mlink->fsec); dba_page_add(mlink->mpage->dba, DBP_ARCH, mlink->arch); dba_page_add(mlink->mpage->dba, DBP_FILE, mlink->file); Index: mansearch.c =================================================================== RCS file: /cvs/mandoc/mansearch.c,v retrieving revision 1.80 diff -c -u -r1.80 mansearch.c --- mansearch.c 13 Dec 2018 11:55:46 -0000 1.80 +++ mansearch.c 29 Dec 2018 23:15:01 -0000 @@ -534,7 +537,8 @@ if (want == NULL || have == NULL || *have == '\0') return 1; while (*have != '\0') { - if (strcasestr(have, want) != NULL) + if (strcasecmp(have, want) == 0) return 1; have = strchr(have, '\0') + 1; } -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv