Question of setting environment variables - Slackware

This is a discussion on Question of setting environment variables - Slackware ; Responding to Jerry Peters: [...] >> >> Sure there are task specific functions the man reader process can do >> better than a browser that was never designed or developed in that >> direction, but it /could/ be, and /wasn't/. ...

+ Reply to Thread
Page 7 of 9 FirstFirst ... 5 6 7 8 9 LastLast
Results 121 to 140 of 174

Thread: Question of setting environment variables

  1. Re: Question of getting system/application information

    Responding to Jerry Peters:

    [...]
    >>
    >> Sure there are task specific functions the man reader process can do
    >> better than a browser that was never designed or developed in that
    >> direction, but it /could/ be, and /wasn't/.

    >
    > Again, _why_ _bother_. man works perfectly well for the overwhelming
    > majority of us. If you want to, why not write some troff macros to
    > convert man pages to HTML?


    My point (or part of it anyway) made then. "Why bother" is pretty close
    to "We've always done things this way" and "We're used to it now" and so
    on.

    Thats not where I've been aiming. I KNOW its not much bother once you get
    used to it, and I KNOW it appears trivial, and probably is, but the
    question stuck with me. Why are certain things "semi-fixed" in that "It
    worked ok, so we're still using it" zone?


    >>
    >> So, its maybe not so much me turning things into a complex issue, but
    >> that the question itself involves complexity that is already there, is
    >> traditionally avoided as its easier to just learn to use the man reader
    >> process, and this needs to be waded through if one is to examine the
    >> question I'm looking at.

    >
    > Sorry, but you remind me of people I've worked with over the years who
    > had a definite talent for making the simple difficult. IBM, for example,
    > is very good at designing things that work for very large installations,
    > but are a PITA for you average moderate sized datacenter.


    So thats the lens you're looking through. Don't invest too much in how
    things look in this surreal medium though. Its tricky guessing intent/
    motivation/etc. just by text alone.

    Next up, I'll teach you to how to suck eggs.


    >>
    >> IOW, the existence of the traditional man reader process has acted as a
    >> diversion to development of a potentially better way of integrating
    >> system and other documentation into other multi-purpose/function
    >> applications.

    >
    > But that's _not_ the UNIX way. The browser is already getting to be a
    > bloated monstrosity with image viewers & all sorts of other junk.



    I'm not talking about today's "Bloatfox", or even Rubic's Lynx, I'm
    trying to reference some kind of generic reader that can handle most
    things to a legible degree, rather than a collective of different
    applications with different command sequences and different flags and
    different keysets etc. just to do the same thing, read documentation.

    Ah mean tah say! Just how different can documentation BE already?

    Its words, then plus markup, then plus images, then plus extras. How many
    ways can one split that up and make life more complex than it needs to be?

    --
    *===( http://principiadiscordia.com/
    *===( http://www.badphorm.co.uk/
    *===( http://www.zenwalk.org/

  2. Re: Question of getting system/application information

    Mike wrote:
    >The fact nobody seems to have even thought to examine this question at
    >least lends support to my earlier statements that nobody seems to have
    >even thought to examine this question.


    He didn't say the question hadn't been examined; he said no one found it
    sufficiently interesting to bother trying to solve it. (Where "it" is
    convincing the man maintainer and all man users to switch!)

    People tend to come to this conclusion: "Forget that--I'll just run
    man2html on my local system."

    Believe me, virtually anyone in the last 10 years who has had to learn
    nroff to write a man page has wondered if there wasn't a better way.

    -Beej


  3. Re: Question of getting system/application information

    Mike wrote:

    > .... Why are certain things "semi-fixed" in that "It worked ok, so
    > we're still using it" zone?


    Another component of Unix philosophy: don't fix it if it ain't broken.
    "it works ok" == "it ain't broken"

    > ... I'm trying to reference some kind of generic reader that can
    > handle most things to a legible degree, rather than a collective of
    > different applications with different command sequences and different
    > flags and different keysets etc. just to do the same thing, read
    > documentation.


    Keith already pointed out that Konqueror seems to fit the above
    description, at least in the context of document formats already discussed
    in this thread (actually, I'm quite sure that Konqueror uses "helper"
    applications to display different file formats, but that's invisible
    to the user, which I'm sure fits what you're after). I hadn't any
    idea Konqueror could display formatted manual pages because, well,
    "man" has always[0] been the right tool for that to me. Knowing that
    Konqueror does the right thing is interesting only in that I checked it
    out, out of curiosity ...

    [0]Years ago, I used Xman a lot to read manual pages (in fact I still
    have a link to it in my Fvwm root menu), but I found it frustrating to
    not be able to use an equivalent to "man -k ..." so I just gave up on
    it and used man at the command-line like everyone else I know ...

    > Its words, then plus markup, then plus images, then plus extras. How
    > many ways can one split that up and make life more complex than it
    > needs to be?


    If you're involved in the GNU project, the sky's the limit! ;-)

    --
    ----------------------------------------------------------------------
    Sylvain Robitaille syl@alcor.concordia.ca

    Network and Systems analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

  4. Re: Question of getting system/application information

    Responding to Keith Keller:

    > On 2008-09-30, Mike wrote:
    >> Responding to Keith Keller:
    >>
    >>> On 2008-09-29, Mike wrote:
    >>>>
    >>>> Or, if the man pages themselves were html/html compatible... ?
    >>>
    >>> man man2html

    >>
    >> Assuming the sarcasm wasn't intended here, you missed the point.

    >
    > Of course the sarcasm was intended. But you could imagine a
    > hypothetical browser configured to run *.man files through man2html in
    > order to render them. I look forward to your contributions in this
    > field. Well, no, I don't, but I don't see anyone else lining up to
    > patch Firefox to do this. (Apparently Konquerer already does something
    > similar, so maybe it's not such a dumb idea after all.)
    >
    > --keith



    We're still not quite on the same bench on this yet, but,

    Thinking about this for a moment...

    All this converting stuff is "after the fact". Surely by now there is the
    very real potential to combine the best features of all proven formats
    and establish one single extendable format that could be used for all
    purposes?

    Lets call this imaginary format "LinForm" "something.lfx"

    There could be LinForm level one, simple text content with basic markup
    designed to make minimum impact if/when read as basic plain text. A kind
    of HTML-lite. = somedoc.lf1

    Then we could get a bit more ambitious, and start adding embedded
    entities like images, and we could call this somedoc.lf2

    Then media, like sound, animated images, and we could call this
    somedoc.lf3

    We could even pull in encryption as somedoc.lfe.enc, and so on.

    All THE reader application would need is to "know" what level it was
    expected to read, so it could call up the sub-binary(s) it needed to
    render that content in a seamless manner within the document. (Basically
    a system-light reader application, plus a series of plugin type support
    binaries, each individually developable, for example.)

    But this relies on a single but extendable base standard, not a
    collection of formats that are designed for one specific reader
    application.

    Mind you, with this properly supported by the right sub-binaries, one
    might even be able to do away with X11 servers and get back to the
    console full time! 8)

    (Now where is that Elinks download I grabbed last week?


    XHTML plus modern browsers appear to have these ideas in mind to some
    degree, but its so far proving to be less than idea. I have to wonder how
    much M$'s involvement in XHTML design has to do with that.

    --
    *===( http://principiadiscordia.com/
    *===( http://www.badphorm.co.uk/
    *===( http://www.zenwalk.org/

  5. Re: Question of getting system/application information

    On September 30, 2008 16:30, in alt.os.linux.slackware, Jerry Peters
    (jerry@example.invalid) wrote:
    [snip]
    >> From where I'm sitting, you just outlined something I've been talking
    >> about. Sure, issuing "man something" gets you documentation, but not in
    >> any way that couldn't be done in several other ways.

    [snip]
    >
    > You still seem to be missing the point. Manpages are written in a
    > markup language for troff (groff) using a set of macros.


    Once upon a time, Bell Laboratories wrote this little operating system. To
    justify the costs (in both time and hardware), the developers sold it to
    their management as a system for transcribing documents and publishing
    manuals. Because of this, the developers were obliged to concoct a language
    and tools that would allow the Bell secretaries to type documents into the
    computer, and have the computer generate printed versions of these
    documents. The language that the developers built was called "RunOff"
    (abbreviated to roff).

    As more and more hardware became available to the OS that these guys wrote,
    they found themselves being asked to interface RunOff with a typesetting
    device (so that the documents could be printed). They wrote a variation of
    roff that they called troff (for Typesetting RunOff). Later the Free
    Software Foundation would write a troff interpreter that they would call
    groff (for Gnu RunOff).

    Of course, having a general purpose document management system (the OS
    (called "Unix") and the RunOff language) made it easy for the developers to
    write the documentation for the system. They simply wrote all the
    documentation in the (t)roff language, and let the computer system print
    the manuals. One of these printed manuals, the "Programmers Reference
    Manual" was especially interesting. In it, the developers documented all
    the operating system's commands (in section 1), it's public interfaces (in
    section 2), the callable service routines (in section 3), relevant file
    formats (in section 4), and miscellaneous information (in section 5). This
    manual, like the rest of the manuals for the OS was written in the (t)roff
    language, and printed using the troff program.

    Time passed, the OS spread to places outside of Bell Labs (notably, the
    University of California, Berkeley campus), and others took on the task of
    enhancing and expanding the system. Of course, paper documentation is
    difficult to duplicate and distribute, so each copy of the OS came with
    it's own documentation in electronic form, as a set of files written in the
    (t)roff language. The end users, after installing the OS, were expected to
    use the troff program to print off as many copies of the printed manual as
    they needed.

    Some enterprising programmers decided that they could interpret the troff
    manual source with another program that would permit the end-user to
    interact with the manual. This program (man) would read the troff-formatted
    manual sources, reformat it for display on a screen or teleprinter, and
    display it accordingly. Of course, this meant that certain troff macros
    that governed such things as bold or italic print had to change to use the
    new display medium, but the end result was that there were no changes
    needed to the original softcopy documentation. And thus the 'man' command
    was born. 'man' retains the organization of the original printed manual,
    (see "man 1 man").

    Time has passed again, and new presentation languages and devices have
    become available. I see no reason not to adapt with the times. We need not
    abandon the (t)roff formatting of the softcopy manual data; we simply can
    invent a process that interprets that and generates XML or HTML or whatever
    we like. Alternatively, we could reinvent [gt]roff to read a specific XML
    or HTML format, and spit out the proper typesetting data accordingly, then
    reformat all the manual pages in this new format.

    [snip]
    --
    Lew Pitcher

    Master Codewright & JOAT-in-training | Registered Linux User #112576
    http://pitcher.digitalfreehold.ca/ | GPG public key available by request
    ---------- Slackware - Because I know what I'm doing. ------



  6. Re: Question of getting system/application information

    On Tue, 30 Sep 2008 17:30:58 +0000, Sylvain Robitaille wrote:

    > The only reason why the nroff/troff way of markup isn't "more widely
    > cross-compatible" is simply because it hasn't been as widely learned or
    > deployed outside of Unix/unix-like systems.


    That said, I have used runoff and/or and troff or clones thereof on VAX/
    VMS and Univac 1100 systems.

  7. Re: Question of getting system/application information

    On September 30, 2008 18:43, in alt.os.linux.slackware, Mark Madsen
    (mark.s.madsen+news@gmail.com) wrote:

    > On Tue, 30 Sep 2008 17:30:58 +0000, Sylvain Robitaille wrote:
    >
    >> The only reason why the nroff/troff way of markup isn't "more widely
    >> cross-compatible" is simply because it hasn't been as widely learned or
    >> deployed outside of Unix/unix-like systems.

    >
    > That said, I have used runoff and/or and troff or clones thereof on VAX/
    > VMS and Univac 1100 systems.


    And IBM MVS systems "Document Composition Facility" (aka DCF) and Script/VS
    markup language processing systems seem to be [gt]?roff clones as well

    --
    Lew Pitcher

    Master Codewright & JOAT-in-training | Registered Linux User #112576
    http://pitcher.digitalfreehold.ca/ | GPG public key available by request
    ---------- Slackware - Because I know what I'm doing. ------



  8. Re: Question of getting system/application information

    On 2008-09-30, Mike wrote:
    > Responding to Keith Keller:
    >>
    >> Of course the sarcasm was intended. But you could imagine a
    >> hypothetical browser configured to run *.man files through man2html in
    >> order to render them. I look forward to your contributions in this
    >> field. Well, no, I don't, but I don't see anyone else lining up to
    >> patch Firefox to do this. (Apparently Konquerer already does something
    >> similar, so maybe it's not such a dumb idea after all.)

    >
    > We're still not quite on the same bench on this yet, but,


    We (I) don't care. If you want these features, you need to write them
    or get other people interested. I have not seen much interest here thus
    far. Perhaps if you had something more than vaporware you'd drum up
    more interest.

    --keith


    --
    kkeller-usenet@wombat.san-francisco.ca.us
    (try just my userid to email me)
    AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
    see X- headers for PGP signature information


  9. Re: Question of getting system/application information

    Mark Madsen wrote:

    > ... I have used runoff and/or and troff or clones thereof on VAX/
    > VMS and Univac 1100 systems.


    Point taken.

    --
    ----------------------------------------------------------------------
    Sylvain Robitaille syl@alcor.concordia.ca

    Network and Systems analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

  10. Re: Question of getting system/application information

    Lew Pitcher wrote:

    > And IBM MVS systems "Document Composition Facility" (aka DCF) and
    > Script/VS markup language processing systems seem to be [gt]?roff
    > clones as well


    Ok.

    --
    ----------------------------------------------------------------------
    Sylvain Robitaille syl@alcor.concordia.ca

    Network and Systems analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

  11. Re: Question of getting system/application information

    Responding to Jerry Peters:

    > Mike wrote:
    >> Responding to Jerry Peters:
    >>
    >> [...]
    >>>
    >>>> While the idea of a single killer-app might not appear to some/many,
    >>>> IMO the man reader thing is heading in the other direction, and in
    >>>> some ways echoes the M$ way of imposing more complications than are
    >>>> necessary on the end user, when there are simpler and more direct
    >>>> ways of delivering that content.
    >>>
    >>> Let's see "man bash" as opposed to what? Man searches MANPATH, are you
    >>> going to implement that in the browser? Mostly I know which man page I
    >>> want, I just need to look up an option, or be sure I've remembered it
    >>> correctly. I _don't_ want to, or need to wade through a TOC to find
    >>> the page I'm looking for.
    >>>
    >>> Again, man is not a single program, it's a pipeline. It could actually
    >>> be implemented as a shell script if someone wanted to code it. The
    >>> complicated part is finding the desired manpage, after that it's a
    >>> simple pipeline.
    >>>
    >>>

    >>
    >> From where I'm sitting, you just outlined something I've been talking
    >> about. Sure, issuing "man something" gets you documentation, but not in
    >> any way that couldn't be done in several other ways. Sure, the obscure
    >> and specialist formating can be piped into several other options. Sure,
    >> its all learnable, and sure, its a process thats been developed and
    >> smoothed over the years.

    >
    > You still seem to be missing the point. Manpages are written in a markup
    > language for troff (groff)


    And how is my point NOT what you just wrote here?

    It needs it's own reader process/binary because of it's format.

    If man pages were written in a format for more than/something else than
    just t/groff, then they could/would be exportable by default and not need
    reformatting, or a specialist reader to read them.

    Just for the fun of it, when was the last time you read anything other
    than t/groff formatted documentation using t/groff?

    --
    *===( http://principiadiscordia.com/
    *===( http://www.badphorm.co.uk/
    *===( http://www.zenwalk.org/

  12. Re: Question of getting system/application information

    Responding to Lew Pitcher:

    > On September 30, 2008 16:30, in alt.os.linux.slackware, Jerry Peters
    > (jerry@example.invalid) wrote:
    > [snip]
    >>> From where I'm sitting, you just outlined something I've been talking
    >>> about. Sure, issuing "man something" gets you documentation, but not
    >>> in any way that couldn't be done in several other ways.

    > [snip]
    >>
    >> You still seem to be missing the point. Manpages are written in a
    >> markup language for troff (groff) using a set of macros.

    >
    > Once upon a time, Bell Laboratories wrote this little operating system.
    > To justify the costs (in both time and hardware), the developers sold it
    > to their management as a system for transcribing documents and
    > publishing manuals. Because of this, the developers were obliged to
    > concoct a language and tools that would allow the Bell secretaries to
    > type documents into the computer, and have the computer generate printed
    > versions of these documents. The language that the developers built was
    > called "RunOff" (abbreviated to roff).
    >
    > As more and more hardware became available to the OS that these guys
    > wrote, they found themselves being asked to interface RunOff with a
    > typesetting device (so that the documents could be printed). They wrote
    > a variation of roff that they called troff (for Typesetting RunOff).
    > Later the Free Software Foundation would write a troff interpreter that
    > they would call groff (for Gnu RunOff).
    >
    > Of course, having a general purpose document management system (the OS
    > (called "Unix") and the RunOff language) made it easy for the developers
    > to write the documentation for the system. They simply wrote all the
    > documentation in the (t)roff language, and let the computer system print
    > the manuals. One of these printed manuals, the "Programmers Reference
    > Manual" was especially interesting. In it, the developers documented all
    > the operating system's commands (in section 1), it's public interfaces
    > (in section 2), the callable service routines (in section 3), relevant
    > file formats (in section 4), and miscellaneous information (in section
    > 5). This manual, like the rest of the manuals for the OS was written in
    > the (t)roff language, and printed using the troff program.
    >
    > Time passed, the OS spread to places outside of Bell Labs (notably, the
    > University of California, Berkeley campus), and others took on the task
    > of enhancing and expanding the system. Of course, paper documentation is
    > difficult to duplicate and distribute, so each copy of the OS came with
    > it's own documentation in electronic form, as a set of files written in
    > the (t)roff language. The end users, after installing the OS, were
    > expected to use the troff program to print off as many copies of the
    > printed manual as they needed.
    >
    > Some enterprising programmers decided that they could interpret the
    > troff manual source with another program that would permit the end-user
    > to interact with the manual. This program (man) would read the
    > troff-formatted manual sources, reformat it for display on a screen or
    > teleprinter, and display it accordingly. Of course, this meant that
    > certain troff macros that governed such things as bold or italic print
    > had to change to use the new display medium, but the end result was that
    > there were no changes needed to the original softcopy documentation.
    > And thus the 'man' command was born. 'man' retains the organization of
    > the original printed manual, (see "man 1 man").
    >
    > Time has passed again, and new presentation languages and devices have
    > become available. I see no reason not to adapt with the times. We need
    > not abandon the (t)roff formatting of the softcopy manual data; we
    > simply can invent a process that interprets that and generates XML or
    > HTML or whatever we like. Alternatively, we could reinvent [gt]roff to
    > read a specific XML or HTML format, and spit out the proper typesetting
    > data accordingly, then reformat all the manual pages in this new format.
    >
    > [snip]



    Thank you. I don't feel so alone now.

    --
    *===( http://principiadiscordia.com/
    *===( http://www.badphorm.co.uk/
    *===( http://www.zenwalk.org/

  13. Re: Question of getting system/application information

    Responding to Jerry Peters:

    [...]
    >>
    >> Its a /legacy/ piece of software. If it's not "heading", as in "being
    >> developed/maintained" then its also potentially obsolete. (Just a
    >> thought there, nothing more.

    >
    > Why? Adding bells & whistles to something that works seems to me to be
    > the Microsoft way: "we need to completely change the interface again so
    > the yokels will think we've improved it".


    Hardly the same thing, and not quite what I meant.


    >
    >> Mature, yes, in common use, yes, even prefered by those who are
    >> familiar with it, but to suggest that its "maturity" is an indication
    >> of it's god- like design (OTT? , or that maturity itself is the
    >> indicator of "how things should be done" is surely stretching things a
    >> tad.
    >>
    >> If it were that clever and efficient, many other things would work just
    >> like it, but don't. Its unique. It has it's own logics and
    >> idiosyncracies, and adds to a list of unique interfaces the Linux user
    >> needs to become familiar with, without offering anything particularly
    >> better than other multi-purpose ways of doing the same jobs.
    >>
    >> IOW, its clutter. Friendly, familiar, maybe even prefered by those who
    >> have spent the time getting to know it, but its a cul-de-sac. It does
    >> nothing else, and other things can do what it does. Maybe not as well,
    >> ATM, but thats surely because there has always been the fallback that
    >> it is easier to learn the (old) man reader way than write a new
    >> function into a file manager or browser.

    >
    > As people keep telling you, IT IS NOT SOMETHING UNIQUE. You can set the
    > manpager to any program that can read from stdin. Most people probably
    > use the default program, which is less on Slack. Most people also use
    > less as a general purpose text viewer.
    >


    Yes I KNOW you CAN do all kinds of things with it. But you HAVE to do
    those things and KNOW to do those things and HOW to do those things.
    Which in turn means that its a techie-tool, not an end user tool.

    Any half competant techie can run everything they need from the
    commandline using some of the advanced tools at their disposal, but
    ordinary end users don't always have the time/concentration to learn all
    the obscure (and they ARE obscure, some of them) commands and controls
    for the often ingenius console applications available.

    In userland, other things become more important, like things looking
    something like the same, and having a similar/familiar interface and so
    on. This also translates into not finding documentation most likely to be
    needed in a time where one's focus is on a problem, in a format that
    needs either extra knowledge and/or extra processes.

    Yeah, sure, in an idea world we'd all have the time to play with each
    binary and process on our Linus system, but in the world of "getting on
    with something" that doesn't always happen. Therefore, the man format and
    specialist reader required, with its own unique "operation manual"
    becomes a PITA rather than a useful tool. IOW, it is, in that and similar
    scenarios, self-obscuring.

    If it were in a format common tools could read by default, without having
    to reformat them before you can read then, meaning you have to read up on
    how to reformat them (assuming you know you can) before you can read them
    to finally get the information you need to... er... what was I doing now?


    Yeah, you're right. This is not unique in that sense, but it is
    particularly a "hidden feature" of the "how to get info on your system
    when something goes SNAFU", or, to put it in non-techie end-user terms, a
    PITA.

    --
    *===( http://principiadiscordia.com/
    *===( http://www.badphorm.co.uk/
    *===( http://www.zenwalk.org/

  14. Re: Question of getting system/application information

    Responding to Keith Keller:

    > On 2008-09-30, Mike wrote:
    >> Responding to Keith Keller:
    >>>
    >>> Of course the sarcasm was intended. But you could imagine a
    >>> hypothetical browser configured to run *.man files through man2html in
    >>> order to render them. I look forward to your contributions in this
    >>> field. Well, no, I don't, but I don't see anyone else lining up to
    >>> patch Firefox to do this. (Apparently Konquerer already does
    >>> something similar, so maybe it's not such a dumb idea after all.)

    >>
    >> We're still not quite on the same bench on this yet, but,

    >
    > We (I) don't care. If you want these features, you need to write them
    > or get other people interested. I have not seen much interest here thus
    > far. Perhaps if you had something more than vaporware you'd drum up
    > more interest.
    >
    > --keith


    I'm not trying to "drum up interest". I'm not a developer. I was asking a
    question. Thats all. If you've been treating this as some kind of
    invitation to join a development team then, oops!

    If you're bored, just drop it. I don't mind.


    When did I end up talking to a Borg collective BTW? ;\

    --
    *===( http://principiadiscordia.com/
    *===( http://www.badphorm.co.uk/
    *===( http://www.zenwalk.org/

  15. Re: Question of getting system/application information

    Responding to Jerry Peters:

    [...]
    >
    > Slack is a "minor" distro because you actually have to work at mastering
    > it. It is not a point & click type process with a lot of hand-holding.
    > The reward is a system that can be customized to work exactly as you
    > want it to.
    >
    > Jerry



    Actually, if you also count the derivatives, Slackware is a base for
    quite a few projects, and the base for at least a couple of serious
    challengers for the Ubuntu "Its not Windows but..." products.

    Zenwalk is my (current) derivative of choice, but Vector is pretty
    sophisticated, and there are others worth looking at too.

    Slackware might not be as visible as some distros, but its there, and in
    more places than one might expect.

    --
    *===( http://principiadiscordia.com/
    *===( http://www.badphorm.co.uk/
    *===( http://www.zenwalk.org/

  16. Re: Question of getting system/application information

    Responding to Beej Jorgensen:

    > Mike wrote:
    >>The fact nobody seems to have even thought to examine this question at
    >>least lends support to my earlier statements that nobody seems to have
    >>even thought to examine this question.

    >
    > He didn't say the question hadn't been examined; he said no one found it
    > sufficiently interesting to bother trying to solve it. (Where "it" is
    > convincing the man maintainer and all man users to switch!)
    >
    > People tend to come to this conclusion: "Forget that--I'll just run
    > man2html on my local system."
    >
    > Believe me, virtually anyone in the last 10 years who has had to learn
    > nroff to write a man page has wondered if there wasn't a better way.
    >
    > -Beej



    Like I said earlier, I guess I'll just run man2html for now.

    --
    *===( http://principiadiscordia.com/
    *===( http://www.badphorm.co.uk/
    *===( http://www.zenwalk.org/

  17. Re: Question of getting system/application information

    Responding to Jerry Peters:

    > Sylvain Robitaille wrote:
    >>
    >> Users like superficial bells and whistles in their content. For crying
    >> out loud, some people even liked "blink" tags (to nauseating degrees).
    >> I think the jury is still out on whether this represents any form of
    >> progress at all. (well, that "blink" tags no longer seem to be used
    >> definitely is progress ...)

    >
    > Blink tags and animated gifs on web pages. One of the reasons I despise
    > MSIE: no way to turn these abominations off. Perhaps there is by now,
    > but I haven't used MSIE for anything serious in at least 5 years.
    > Oh, I forgot Flash, another abomination. Thank God for Flashblock &
    > Noscript.
    >
    > Jerry



    What are these strange esoteric thinks of which you speak?

    Let me dig around for a moment.

    Ah yes. Things on my "This is a fault/SNAFU/AdWare so nuke it before you
    start" list for any browser I examine/deploy.

    Still can't find any reference to this "MSIE" thing though. Could that be
    part of the spyware one typically has to clean off one's HDD when one
    buys a new computer? (Surely nobody actually fires that up any more?

    --
    *===( http://principiadiscordia.com/
    *===( http://www.badphorm.co.uk/
    *===( http://www.zenwalk.org/

  18. Re: Question of getting system/application information

    On 2008-10-01, Mike wrote:
    >
    > And how is my point NOT what you just wrote here?
    >
    > It needs it's own reader process/binary because of it's format.
    >
    > If man pages were written in a format for more than/something else than
    > just t/groff, then they could/would be exportable by default and not need
    > reformatting, or a specialist reader to read them.



    Just for the fun of it...isn't exporting and reformating one in the same??


    >
    > Just for the fun of it, when was the last time you read anything other
    > than t/groff formatted documentation using t/groff?
    >


    When was the last time you used adobe reader for anything other than pdf
    files.

    ken

  19. Re: Question of getting system/application information

    Responding to Beej Jorgensen:

    > Sylvain Robitaille wrote:
    >>Mike wrote:
    >>> Dayam! I'm drifing toward the (new) question "Why can't/don't browsers
    >>> and file managers read man formated documentation by default yet?"

    >>
    >>It's a valid question, the answer to which is likely along the lines of
    >>"no one has considered that a sufficiently interesting problem to bother
    >>trying to solve it, especially when 'everybody else' is going to point
    >>out to them that it's a non-problem and 'man document' is likely to be
    >>easier to use in most cases." :-)

    >
    > Or, to put it another way, "lack of demand." :-) Most web users don't
    > read man pages, and most man page users like to use "man". (Note
    > "most".)
    >
    > On the other hand, if one thinks of an idea, chances are it's already
    > implemented or in the works.
    >
    > For instance, all that noise I posted about converting man pages to XML
    > has already been implemented by ESR in doclifter. Someone else has
    > probably written stylesheets and an XML version of man... man(7) implies
    > that man readers "should" support this functionality.
    >
    > If someone like Red Hat wanted to fully implement this, it is probably
    > within reach for a couple thousand bucks, i.e. nothing.
    >
    > There can be a lot of resistance to change, though. It can be tough to
    > propose a new idea and not have it sound like an attack on peoples'
    > Linux lifestyles. But I think this is an easy one because a transition
    > can be made to a new format without changing anyone's habits.
    >
    > Finally, let me add a note from the BUGS subsection of man(7), which,
    > ironically, I'm viewing in Firefox from kernel.org--haha!
    >
    > Most of the macros describe formatting (e.g., font type and spacing)
    > instead of marking semantic content (e.g., this text is a reference
    > to another page), compared to formats like mdoc and DocBook (even
    > HTML has more semantic markings). This situation makes it harder to
    > vary the man format for different media, to make the formatting
    > consistent for a given media, and to automatically insert
    > cross-references. By sticking to the safe subset described above, it
    > should be easier to automate transitioning to a different reference
    > page format in the future.
    >
    > So it's already being considered, and probably the only bit left to do
    > is fight about it in committee for the next five years.
    >
    > OK! Issue Two: switching the United States to the metric system!
    >
    > -Beej



    Yaaar!

    --
    *===( http://principiadiscordia.com/
    *===( http://www.badphorm.co.uk/
    *===( http://www.zenwalk.org/

  20. Re: Question of getting system/application information

    Responding to Sylvain Robitaille:

    > Mike wrote:
    >
    >> .... Why are certain things "semi-fixed" in that "It worked ok, so
    >> we're still using it" zone?

    >
    > Another component of Unix philosophy: don't fix it if it ain't broken.
    > "it works ok" == "it ain't broken"


    And then there's the Linux way, "I wonder what would happen if we...?"


    >> ... I'm trying to reference some kind of generic reader that can handle
    >> most things to a legible degree, rather than a collective of different
    >> applications with different command sequences and different flags and
    >> different keysets etc. just to do the same thing, read documentation.

    >
    > Keith already pointed out that Konqueror seems to fit the above
    > description, at least in the context of document formats already
    > discussed in this thread (actually, I'm quite sure that Konqueror uses
    > "helper" applications to display different file formats, but that's
    > invisible to the user, which I'm sure fits what you're after). I hadn't
    > any idea Konqueror could display formatted manual pages because, well,
    > "man" has always[0] been the right tool for that to me. Knowing that
    > Konqueror does the right thing is interesting only in that I checked it
    > out, out of curiosity ...


    Konk is not a lightweight frame process that draws on and incorporates
    other function-specific sub-processes. Its a full on browser that has
    extensions. Not quite the same thing I was thinking about here.

    Again, I'm not looking to solve a problem, as there is no problem to
    speak of, only a specific question.


    > [0]Years ago, I used Xman a lot to read manual pages (in fact I still
    > have a link to it in my Fvwm root menu), but I found it frustrating to
    > not be able to use an equivalent to "man -k ..." so I just gave up on it
    > and used man at the command-line like everyone else I know ...
    >
    >> Its words, then plus markup, then plus images, then plus extras. How
    >> many ways can one split that up and make life more complex than it
    >> needs to be?

    >
    > If you're involved in the GNU project, the sky's the limit! ;-)


    Or, arthritis is the limit.

    --
    *===( http://principiadiscordia.com/
    *===( http://www.badphorm.co.uk/
    *===( http://www.zenwalk.org/

+ Reply to Thread
Page 7 of 9 FirstFirst ... 5 6 7 8 9 LastLast