From: Tomi Ollila <tomi.ollila@iki.fi>
To: "W. Trevor King" <wking@tremily.us>
Cc: notmuch@notmuchmail.org
Subject: Re: [PATCH 5/7] doc: Allow rst2man.py as an alternative to rst2man
Date: Sun, 06 Apr 2014 11:37:09 +0300 [thread overview]
Message-ID: <m21txac0qy.fsf@guru.guru-group.fi> (raw)
In-Reply-To: <20140405191917.GF5316@odin.tremily.us>
On Sat, Apr 05 2014, "W. Trevor King" <wking@tremily.us> wrote:
> On Sat, Apr 05, 2014 at 10:05:31PM +0300, Tomi Ollila wrote:
>> On Sat, Apr 05 2014, W. Trevor King wrote:
>> > I use POSIX's 'command -v' [1] to find the path to rst2man…
>> >
>> > [1]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html
>>
>> …
>> Except the reference to _POSIX_ page. One knows how consistent these
>> specifications are; alternative:
>>
>> http://pubs.opengroup.org/onlinepubs/009695399/utilities/command.html
>>
>> mentions additionally that -v flag
>> "(On systems supporting the User Portability Utilities option.)"
>
> It's been a decade since POSIX 2004 ;). I'm not sure when the “User
> Portability Utilities” caveat was removed, but I imagine most
> POSIX-aspiring shells have -v support. Short of citing POSIX 2013, I
> think I'd have to survey likely shells, and that seems even less
> reliable. Maybe I'm missunderstanding your suggested change?
>
>> Also, we don't give such a treatment to other command either; I'd rather
>> see RST2MAN=rst2man, RST2MAN=rst2man.py *and* RST2MAN= lines used
>> instead -- the last to set RST2MAN to empty string instead of being unset.
>
> I'm fine with that. Alternatively, we could add an:
>
> if -n "${RST2MAN}"
>
> clause to the front of the detection code to allow users with oddball
> scripts (maybe a null set) to override RST2MAN at configure time:
>
> $ RST2MAN=/my/custom/rst_to_man_converter ./configure
> $ make
>
> instead of at make-invocation time:
>
> $ ./configure
> $ make RST2MAN=/my/custom/rst_to_man_converter
>
> That would consolidate configuration around the 'config' call, and
> make explicitly emptying the RST2MAN variable more clearly superfluous
> (although I'm still fine with an explicit empty).
>
> Thoughts?
If we did that, what about other commands, starting with sphinx-build
(that is harder as python -m `sphinx.writers.manpage` fails even
sphinx-build is set to something else; in case of sphinx,
make SPHINXBUILD=sphinx-1.0-build works, for example in RHEL 6.2
machines...
...doing --with-rst2man=my.custom.rst_to_man_converter and make things
look consistent would required considerable amount of development
(and review!) time...
ATM I'd just settle with plain command names and empty RST2MAN in case not
found.
>
> Trevor
>
> --
More Thoughts?
Tomi
next prev parent reply other threads:[~2014-04-06 8:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-05 17:31 [PATCH 0/7] doc: Python 3 compat, rst2man.py support, etc W. Trevor King
2014-04-05 17:31 ` [PATCH 1/7] doc/mkdocdeps.py: Convert execfile to import W. Trevor King
2014-04-05 17:31 ` [PATCH 2/7] doc/mkdocdeps.py: Use "with" statement for the output file W. Trevor King
2014-04-05 17:31 ` [PATCH 3/7] doc/prerst2man.py: Use Python-3-compatible octal notation W. Trevor King
2014-04-05 17:31 ` [PATCH 4/7] doc/prerst2man.py: Fix 'os.system' -> 'system' typo W. Trevor King
2014-04-05 17:31 ` [PATCH 5/7] doc: Allow rst2man.py as an alternative to rst2man W. Trevor King
2014-04-05 19:05 ` Tomi Ollila
2014-04-05 19:19 ` W. Trevor King
2014-04-06 8:37 ` Tomi Ollila [this message]
2014-04-05 17:31 ` [PATCH 6/7] doc/prerst2man.py: Convert execfile to import W. Trevor King
2014-04-05 17:31 ` [PATCH 7/7] doc/INSTALL: Remove rst2man reference and other updates W. Trevor King
2014-04-05 20:35 ` David Bremner
2014-04-05 21:12 ` W. Trevor King
2014-04-05 22:53 ` David Bremner
2014-04-06 8:18 ` Tomi Ollila
2014-04-14 18:00 ` [PATCH 0/7] doc: Python 3 compat, rst2man.py support, etc Tomi Ollila
2014-04-20 22:56 ` David Bremner
2014-04-21 13:03 ` David Bremner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m21txac0qy.fsf@guru.guru-group.fi \
--to=tomi.ollila@iki.fi \
--cc=notmuch@notmuchmail.org \
--cc=wking@tremily.us \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).