On 2014-04-02, Damien Miller wrote:
> On Tue, 1 Apr 2014, Christian Weisgerber wrote:
>
>> On 2014-04-01, Theo de Raadt wrote:
>>
>> > Another approach is to extend the usage() in every program so that it
>> > provides more information.
>>
>> Just embed the whole man page, as in curl -M.
>
> Pu
Can we have a lib to create quad-barcodes so I can grab the URL with my
cellphone?
We just need to import this from the ports tree into base.
*qrencode-libs*
A small http webserver would not be wasteful either..
2014-04-02 7:28 GMT+02:00 Damien Miller :
> On Tue, 1 Apr 2014, Christian Weisge
On Tue, 1 Apr 2014, Christian Weisgerber wrote:
> On 2014-04-01, Theo de Raadt wrote:
>
> > Another approach is to extend the usage() in every program so that it
> > provides more information.
>
> Just embed the whole man page, as in curl -M.
Putting stuff in usage() is pretty retro. Modern pr
On 2/04/2014 6:21 AM, patrick keshishian wrote:
On 4/1/14, Hendrickson, Kenneth wrote:
On 4/1/2014, Patrick Keshishian wrote:
sorry to crash your party, but i think you've got something there
with the usage() example. this could reduce man executable to
a one line shell script (or a builtin):
On 2014-04-01, Theo de Raadt wrote:
> Another approach is to extend the usage() in every program so that it
> provides more information.
Just embed the whole man page, as in curl -M.
--
Christian "naddy" Weisgerber na...@mips.inka.de
On 4/1/14, Hendrickson, Kenneth wrote:
>
> On 4/1/2014, Patrick Keshishian wrote:
>> sorry to crash your party, but i think you've got something there
>> with the usage() example. this could reduce man executable to
>> a one line shell script (or a builtin):
>>
>> $ cat /usr/bin/man
>> #!/bin/sh
>
On 2014-04-01 13:43, Theo de Raadt wrote:
Then the semantic markup would all be in one place -- in the source
files. There would be no need for seperate manual pages, and the
pipeline could be simply:
ssh-keygen -? -> usage2pod -> pod2mdoc -> doclifter -> docbook2mdoc
-> man
More food f
On 4/1/2014, Patrick Keshishian wrote:
> sorry to crash your party, but i think you've got something there
> with the usage() example. this could reduce man executable to
> a one line shell script (or a builtin):
>
> $ cat /usr/bin/man
> #!/bin/sh
> while [ $# -gt 0 ] ; do $1 -h | ${PAGER:-more}
On 4/1/14, Theo de Raadt wrote:
>> In the short-run, can't you achieve your goal the same way with this:
>>
>> pod2mdoc -> doclifter -> docbook2mdoc -> man
>>
>> Eventually, we can re-write man to accept more sophisticated formats
>> directly instead of being tied to mdoc(7), but this would be t
On 2014/04/01 20:31, Kristaps Dzonsons wrote:
> I think a better idea is to go with POD. We can dispense with the
> complexities of mdoc(7) and go right to what we really want--content, not
> markup.
Can't we just use ANSI colour sequences? We can use TheDraw in dosbox to
create pages, it's a fin
> In the short-run, can't you achieve your goal the same way with this:
>
> pod2mdoc -> doclifter -> docbook2mdoc -> man
>
> Eventually, we can re-write man to accept more sophisticated formats
> directly instead of being tied to mdoc(7), but this would be transparent
> to end-users.
>
> Tho
OK for the following commit to /usr/src/usr.bin/docbook2mdoc
as a first step? We can then continue development in tree.
Ingo,
I don't think you're addressing the root problem here: complexity. Both
mdoc(7) and DocBook are semantic languages. And while semantics were
good enough historicall
Hi,
given that Kristaps Dzonsons has recently written docbook2mdoc,
http://mdocml.bsd.lv/docbook2mdoc/
which is a DocBook-XML to mdoc(7) converter, and that Eric S. Raymond's
mdoc(7) to DocBook-XML converter
http://www.catb.org/~esr/doclifter/
is readily available, i am going to switch the
13 matches
Mail list logo
