From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: ** X-Spam-Status: No, score=2.6 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MISSING_HEADERS, NML_ADSP_CUSTOM_MED,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 19906 invoked from network); 29 Apr 2023 23:25:55 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 29 Apr 2023 23:25:55 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id da1a3a00 for ; Sat, 29 Apr 2023 18:25:50 -0500 (EST) Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 7b2b64a3 for ; Sat, 29 Apr 2023 18:25:49 -0500 (EST) Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-1aaebed5bd6so1066385ad.1 for ; Sat, 29 Apr 2023 16:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682810748; x=1685402748; h=mime-version:message-id:in-reply-to:date:subject:cc:from:user-agent :references:from:to:cc:subject:date:message-id:reply-to; bh=Qq7CI4GoTZEPx6zNHk7uj9cbXlTsPjMY8fm3aqpAfHM=; b=E7L+n13hGL+pIYeYZC1rZtKdIJxA8PN2Ds2bubklkXUmLgjoBTrtobnURIkUEstDZ7 uWbGBGieOsNw4g1t3J2qJyf+BD1VG7BMyswp+6xwzJ0znoKeOIP0GAe7Ap1or2ftO4GT SnBFwVgchcxODBNbDlyZqVrn7AkReeU1HvLEwQAyaxSxt6Gfzijk1ZC1QUQRvsWfKS3R SwHZnI8pbgVh3vFIrb6eO+em99Cl8HWT95iuMN9FNqA6/4WLtaKHzlT5Sk4l3ptbKiF2 +yijaR3zjlOek8n+jDyLgeJU7aSD1BWZpTO10OqBpA9YY6oNtC5qI2oRILemNIRA8JLt F6EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682810748; x=1685402748; h=mime-version:message-id:in-reply-to:date:subject:cc:from:user-agent :references:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Qq7CI4GoTZEPx6zNHk7uj9cbXlTsPjMY8fm3aqpAfHM=; b=fOFngCm0nBx0lIqkUtZycnQ6YCzclHkuY3mWEHHZawwE0pBOwBqyus+wL0bZmO7XSN OZcMuYLu/2ep/9SKQtafi5FlhpAmQikKgvIwcbxxaNeu8AW8nG7k1WHWo93Wvz/l4RD7 c3b9VxvIu4HCpeNQzWY1xZvghGAFTvetThBH1ZIJB+NOCkldjpDTOZOCxD+0COeUk5m6 Ewhq1ow1K6bSZt31m1HwZXLyGQ3AUMGGHBrAqiy+HNuogNmbx7fyluObp07hSs7jxbMt VZ2CZJP2MT9WE982hG4kfcDIXmfgbsJrM+rBLQtT8thyhpkqpjqPZL9hzUXG+c0LIySk PFkQ== X-Gm-Message-State: AC+VfDw1tbnnBFwmZ0U3Bc6y2oh4/akitiBLNw783/JBPGgwBEbgnbti 19R5WLlpfg+BER9qRipTAi/fQ/WhhUA= X-Google-Smtp-Source: ACHHUZ4hgWFeIjLDYYjKC0aN8tDySXY7+Kpi3kcl2rzrnOCbK9C2WjEG4VJmUIEAsYcq1V6LOqX3Uw== X-Received: by 2002:a17:903:230e:b0:1aa:e1f0:7d60 with SMTP id d14-20020a170903230e00b001aae1f07d60mr1961469plh.19.1682810747966; Sat, 29 Apr 2023 16:25:47 -0700 (PDT) Received: from localhost ([2405:6e00:294:9b84:3085:642d:94e5:ba0]) by smtp.gmail.com with ESMTPSA id j17-20020a170902759100b001a6e3e3dbc3sm15246891pll.22.2023.04.29.16.25.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 29 Apr 2023 16:25:47 -0700 (PDT) References: <87ildo5xlr.fsf@ada> User-agent: mu4e 1.8.14; emacs 28.3 From: Alexis Cc: discuss@mandoc.bsd.lv, groff@gnu.org, man-db-devel@nongnu.org Subject: Re: Behaviour of .so differs between mandoc and groff Date: Sun, 30 Apr 2023 09:24:42 +1000 In-reply-to: <87ildo5xlr.fsf@ada> Message-ID: <87edo2z2x3.fsf@ada> X-Mailinglist: mandoc-discuss Reply-To: discuss@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; format=flowed Ping. Does anyone have any thoughts on this? It's a small but persistent irritation on my system. :-) Alexis writes: > [1. text/plain] > > Hi all, > > On my Gentoo system, awk.1 simply contains an .so request whose > argument is the man page for the actual awk implementation in > use, > i.e. just: > > .so gawk.1 > > However, although this works when using man-db, it doesn't when > one is > using mandoc instead, as on my system. Instead of gawk.1 being > sourced, processed and displayed, i get output along the lines > of: > > () () > See the file gawk.1. > > > () > > However, if i change the request in awk.1 to: > > .so man1/gawk.1 > > then everything works as expected. > > The example in the entry for .so in mandoc_roff(7) is what led > me to > try the preceding, but there's no further indication that the > requirement for a leading section directory is consciously > different > from any other roff implementation, or from groff in > particular. A > comment in roff_so() in mandoc/roff.c[a] says: > > /* > /* Handle `so'. Be EXTREMELY careful, as we shouldn't be > * opening anything that's not in our cwd or anything beneath > * it. Thus, explicitly disallow traversing up the > file-system > * or using absolute paths. > */ > > i couldn't find any discussion about .so in the mandoc TODO > list[b]. > > i've no idea what the 'correct' behaviour 'should' be, from > whatever > perspective (historical / security / groff-compatibility / > etc.), so > am cross-posting to what i believe to be the relevant lists. > > > Alexis. > > [a] > https://cvsweb.bsd.lv/mandoc/roff.c?rev=1.395&content-type=text/x-cvsweb-markup > > [b] > https://cvsweb.bsd.lv/mandoc/TODO?rev=1.327&content-type=text/x-cvsweb-markup -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv