On Fri, Sep 13, 2019 at 05:45:51PM -0400, Clem Cole wrote: > It does leave us an interesting question, when did the original roff(1) > show up and when did nroff(1). The original, roff(1), was early, and > of course not until after the original PDP-11/20 port. But was it as > early as first edition? roff was the first formatting program. nroff > replaced it later on, although roff lived through the 6th edition (I do > not believe it is on the v7 tape). There was a roff on PDP-7 Unix: By the spring of 1971, it was generally agreed that no one had the slightest interest in scrapping Unix. Therefore, we transliterated the roff text formatter into PDP-11 assembler language, starting from the PDP-7 version that had been transliterated from McIlroy’s BCPL version on Multics, which had in turn been inspired by J. Saltzer’s runoff program on CTSS. From "The Evolution of the Unix Time-sharing System" http://www.read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf Cheers, Warren
[-- Attachment #1: Type: text/plain, Size: 1351 bytes --] Thanks. So we have a date that explains the pdp-11 assembler version - it was there at v1. On Fri, Sep 13, 2019 at 6:14 PM Warren Toomey <wkt@tuhs.org> wrote: > On Fri, Sep 13, 2019 at 05:45:51PM -0400, Clem Cole wrote: > > It does leave us an interesting question, when did the original > roff(1) > > show up and when did nroff(1). The original, roff(1), was early, and > > of course not until after the original PDP-11/20 port. But was it as > > early as first edition? roff was the first formatting program. > nroff > > replaced it later on, although roff lived through the 6th edition (I > do > > not believe it is on the v7 tape). > > There was a roff on PDP-7 Unix: > > By the spring of 1971, it was generally agreed that no one had the > slightest interest in scrapping Unix. Therefore, we transliterated > the roff text formatter into PDP-11 assembler language, starting from > the PDP-7 version that had been transliterated from McIlroy’s BCPL > version on Multics, which had in turn been inspired by J. Saltzer’s > runoff program on CTSS. > > From "The Evolution of the Unix Time-sharing System" > > > http://www.read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf > > Cheers, Warren > -- Sent from a handheld expect more typos than usual [-- Attachment #2: Type: text/html, Size: 1917 bytes --]
> > slightest interest in scrapping Unix. Therefore, we transliterated
> > the roff text formatter into PDP-11 assembler language, starting from
> > the PDP-7 version that had been transliterated from McIlroy???s BCPL
> > version on Multics, which had in turn been inspired by J. Saltzer???s
> > runoff program on CTSS.
As a *roff guy to the core, to this day, I'd love to see any docs on the
Multics version and/or the CTSS version.
Roff has some pretty sophisticated stuff (environments come to mind) that
I think 99.9% of the CS world doesn't understand (sort of like my rant
on SCCS, most people didn't look hard enough to get it. I'm not sure
that I get roff environments to this day but I kinda do).
I'd love to see the docs on that early stuff and see if Joe Ossanna
added in his own magic or was he carrying forward earlier magic.
--lm
P.S. I love this list for this stuff, I'm an old retired guy that
wishes he could have helped birth Unix. Hanging out with the people
who were there is super fun.
On Fri, Sep 13, 2019 at 07:02:40PM -0700, Larry McVoy wrote: > Roff has some pretty sophisticated stuff (environments come to mind) that > I think 99.9% of the CS world doesn't understand (sort of like my rant > on SCCS, most people didn't look hard enough to get it. I'm not sure > that I get roff environments to this day but I kinda do). > > I'd love to see the docs on that early stuff and see if Joe Ossanna > added in his own magic or was he carrying forward earlier magic. Here's a good page on the history: https://manpages.bsd.lv/history.html > P.S. I love this list for this stuff, I'm an old retired guy that > wishes he could have helped birth Unix. Hanging out with the people > who were there is super fun. Hell yeah to both! Cheers, Warren
> I'd love to see the docs on that early stuff and see if Joe Ossanna > added in his own magic or was he carrying forward earlier magic. Here are scans of non-unix roff in 1971: https://www.cs.dartmouth.edu/~doug/roff71/roff71 I also have 1969, but it's bedtime and that will have to wait. Relative numbers (+n), roman numerals, .ti, top and bottom margin settings, .po, running titles, tab settings, hyphenation and footnotes were not in Saltzer's runoff. Most other features were. Doug
On 14/09/2019 03:44, Warren Toomey wrote:
> On Fri, Sep 13, 2019 at 07:02:40PM -0700, Larry McVoy wrote:
>> Roff has some pretty sophisticated stuff (environments come to mind) that
>> I think 99.9% of the CS world doesn't understand
This thread about *roff echoes something that I have been thinking about
recently.
I've been wondering whether it is possible and worthwhile to use *roff
for complex technical documentation. I've always loved the aesthetic
that books produced using *roff have but there are other reasons too.
As far as _markup_ is concerned we have DocBook for example. I am also
looking into this. (Also, I understand it's not a typesetting system.)
Getting back to *roff, does anybody know if there is a (hopefully rich)
repository of macros, or any other resources, for my use case? (La)TeX
has this but I'd like to try something else. What do people think?
Kind regards,
Andrew
--
OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
"U'll Be King of the Stars" <ullbeking@andrewnesbit.org> wrote: > On 14/09/2019 03:44, Warren Toomey wrote: > > On Fri, Sep 13, 2019 at 07:02:40PM -0700, Larry McVoy wrote: > >> Roff has some pretty sophisticated stuff (environments come to mind) that > >> I think 99.9% of the CS world doesn't understand > > This thread about *roff echoes something that I have been thinking about > recently. > > I've been wondering whether it is possible and worthwhile to use *roff > for complex technical documentation. I've always loved the aesthetic > that books produced using *roff have but there are other reasons too. > > As far as _markup_ is concerned we have DocBook for example. I am also > looking into this. (Also, I understand it's not a typesetting system.) Unless you use a WYSIWYG tool that generates DocBook, you should avoid it. Your fingers will kill you. I have written books in troff, DocBook and Texinfo. Texinfo is *by far* the superior markup language. Using Texinfo can generate DocBook which your publisher can turn into PDF. (I have done this, three times at least.) But working directly in DocBook just plain hurts. > Getting back to *roff, does anybody know if there is a (hopefully rich) > repository of macros, or any other resources, for my use case? (La)TeX > has this but I'd like to try something else. What do people think? The MM macros are the most capable of the standard sets that are out there, although possibly the MOM macros distributed with groff are even more so; I have not investigated fully. My own wish for the next genie in a lamp that I come across would be for a texinfo --> troff translator. Arnold
On Sun, 15 Sep 2019, arnold@skeeve.com wrote:
> The MM macros are the most capable of the standard sets that are out
> there, although possibly the MOM macros distributed with groff are even
> more so; I have not investigated fully.
For some reason I prefer the MS macros, probably because I learnt them
first and I find it difficult to use MM.
-- Dave
On 15/09/2019 07:54, arnold@skeeve.com wrote: > "U'll Be King of the Stars" <ullbeking@andrewnesbit.org> wrote: >> I've been wondering whether it is possible and worthwhile to use *roff >> for complex technical documentation. I've always loved the aesthetic >> that books produced using *roff have but there are other reasons too. >> >> As far as _markup_ is concerned we have DocBook for example. I am also >> looking into this. (Also, I understand it's not a typesetting system.) > > Unless you use a WYSIWYG tool that generates DocBook, you should avoid it. > Your fingers will kill you. Oh, I'm not looking for WYSIWIG or even really WYSIMIM. I'm well used to writing in structural markup and presentation markup languages, e.g., LaTeX (which I think is extremely complicated, and since I left the university environment I do not miss it). AS for authoring DocBook I was depending on GNU Emacs to do a lot of the heavy XML stuff for me. Wishful thinking perhaps. > I have written books in troff, DocBook > and Texinfo. Texinfo is *by far* the superior markup language. I've had a feeling that Texinfo has been getting brushed to the side. Are you suggesting that Info is a good as a rendered documentation format? Or just that Texinfo is good for proto-documents that are to be authored in a parseable and meaningful format? I've been a long-time GNU Emacs user so reading Info files is OK for me. But we've never had a _nice_ Info reader, which is why it didn't take off I think. A lot of people REALLY hate the Info UI. Moreover it was (is?) very difficult to generate good contents and index pages with the official tools that I used at the time. I started working on improving this about 20 years ago but back then it felt as though the GNU Info and GNU Emacs projects had other things on their minds. > Using Texinfo can generate DocBook which your publisher can turn into PDF. > (I have done this, three times at least.) But working directly in > DocBook just plain hurts. OK, so you are suggesting Texinfo as a prototypical markup language, not necessarily something that will end up as Info files? I have read the Texinfo documentation and I agree that it seemed like a rich markup language. >> Getting back to *roff, does anybody know if there is a (hopefully rich) >> repository of macros, or any other resources, for my use case? (La)TeX >> has this but I'd like to try something else. What do people think? > > The MM macros are the most capable of the standard sets that are > out there, although possibly the MOM macros distributed with groff > are even more so; I have not investigated fully. Thank you for the heads up. I never heard of MOM but MM is more familiar. *I haven't really looked at eqn beyond browsing docs and I'm not sure how much I should expect from it.* TeX is (still?) the king of mathematical expression typesetting. > My own wish for the next genie in a lamp that I come across would be > for a texinfo --> troff translator. Have you looked at Pandoc? I don't know if it will do this but it's worth checking out. Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
Hi. "U'll Be King of the Stars" <ullbeking@andrewnesbit.org> wrote: > AS for authoring DocBook I was depending on GNU Emacs to do a lot of the > heavy XML stuff for me. Wishful thinking perhaps. Possibly. I use gvim. :-) And, no, I won't start _that_ discussion. To each his own, live and let live. > > I have written books in troff, DocBook > > and Texinfo. Texinfo is *by far* the superior markup language. > > I've had a feeling that Texinfo has been getting brushed to the side. It is actively maintained and developed. > Are you suggesting that Info is a good as a rendered documentation > format? Or just that Texinfo is good for proto-documents that are to be > authored in a parseable and meaningful format? The latter. > Moreover it was (is?) very difficult to generate good contents and index > pages with the official tools that I used at the time. For _printed_ matter, the current texinfo does fine at table of contents. The upcoming version of texinfo (in prerelease now) has new indexing capabilities that bring it on par with what you see in commercial publishing: multilevel indexing, as well as "see" and "see also" entries. I agree that Info isn't lovely; I prefer to read the generated HTML from makeinfo, or the PDF from texi2pdf. > I have read the Texinfo documentation and I agree that it seemed like a > rich markup language. Much of the growth in the markup language has been at my urging over the years. :-) > *I haven't really looked at eqn beyond browsing docs and I'm not sure > how much I should expect from it.* eqn is the inspiration for math mode in TeX. That's very clear, and Knuth was also aware of tbl. > > My own wish for the next genie in a lamp that I come across would be > > for a texinfo --> troff translator. > > Have you looked at Pandoc? I don't know if it will do this but it's > worth checking out. Thanks for that pointer. I'll have to take a look at it. Arnold
Dave Horsfall writes:
> On Sun, 15 Sep 2019, arnold@skeeve.com wrote:
>
> > The MM macros are the most capable of the standard sets that are out
> > there, although possibly the MOM macros distributed with groff are even
> > more so; I have not investigated fully.
>
> For some reason I prefer the MS macros, probably because I learnt them
> first and I find it difficult to use MM.
>
> -- Dave
I am also a MS fan. Tektronix did their own version of MS that added a ton
of really nice features. Would be nice if someone could share that since
Tek is long gone and probably doesn't care.
Jon
ROFF is the simplest of the runoff programs but is utterly frozen. I started with the -ms macro package so I had fondness for it, but switched to -mm over time. I had done some work (after not being able to pry a version Dennis Mumaugh had written out of the agency) on putting classification marking and formatting in it. I had restyled it to make the output look like the standard IBM formatting when we were doing UNIX work under contract for IBM. At Hopkins, we had a small furor when Mike (Michael John) Muuss wrote his own macro package and installed it as tmac.jm (invoked by the -mjm option). This led to lots of jokes about renaming programs and options after various users.
[-- Attachment #1: Type: text/plain, Size: 646 bytes --] Warren, On Fri, Sep 13, 2019 at 10:44 PM Warren Toomey <wkt@tuhs.org> wrote: > > Here's a good page on the history: > https://manpages.bsd.lv/history.html Excellent - thanks for the pointer. This shows nroff before troff. FWIW: I guess I was miss informed, but I had been under the impression that was the other way around. i.e. nroff was done to be compliant with the new troff, replacing roff, although the suggestion here is that he wrote it add macros to roff. I'll note that either way, the dates are all possible of course because the U/L case ASR 37 was introduced 1968 so by the early 1970's they would have been around the labs. [-- Attachment #2: Type: text/html, Size: 1225 bytes --]
Clem Cole writes:
> Excellent - thanks for the pointer. This shows nroff before troff.
> FWIW: I guess I was miss informed, but I had been under the impression
> that was the other way around. i.e. nroff was done to be compliant with
> the new troff, replacing roff, although the suggestion here is that he
> wrote it add macros to roff. I'll note that either way, the dates are all
> possible of course because the U/L case ASR 37 was introduced 1968 so by
> the early 1970's they would have been around the labs.
Yes, we had ASR 37s, used one myself. Not only did the do upper and lower
case, but they also did Greek and math characters, had bracket building
characters, and so on. Biggest problem was line noise since these were
mostly on dial-up. One could be having a nice day and all of a sudden a
burst of line noise would trigger a shift-out and everything would be
gibberish.
[-- Attachment #1: Type: text/plain, Size: 1151 bytes --] On Sat, Sep 14, 2019 at 11:03 PM U'll Be King of the Stars < ullbeking@andrewnesbit.org> wrote: > > I've been wondering whether it is possible and worthwhile to use *roff > for complex technical documentation. I've always loved the aesthetic > that books produced using *roff have but there are other reasons too. > Ditto. The books that used roff can look clean and within a series are usually consistent, but what I've like is that they are different. The Prentiss-Hall series and the ORA books both were produced using troff and different versions of ms, but the results are different. One of my complained with LaTex books is they all seem to look the same. > Getting back to *roff, does anybody know if there is a (hopefully rich) > repository of macros, or any other resources, for my use case? > I've never seen one. As far as I knew it, publishers sometimes seeded authors. ORA used the Masscomp/Tektronix derived version of ms (-mS) that Steve Talbot created (and Rick LeFaivre originally created from the original Lesk V7 set). Rich Steven's has his own additions to the version of ms that came with groff which I have also seen. [-- Attachment #2: Type: text/html, Size: 2314 bytes --]
[-- Attachment #1: Type: text/plain, Size: 308 bytes --] On Sun, Sep 15, 2019 at 2:55 AM <arnold@skeeve.com> wrote: > Texinfo is *by far* the superior markup language. > I'll take your work for it, but my complaint is it requires emacs to use as the pager on my screen. If you live in emacs, that makes sense; but most people, even in the GNU/Linux world, don't. [-- Attachment #2: Type: text/html, Size: 794 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1058 bytes --] I learn runoff from the IBM and the TOPS, then PUB then Scribe before I saw the nroff/troff family. I have fond memories of using Scribe (which was sort of the model for the LaTex macros when it got tied up in the legal entanglements of CMU). So UNIX was what I had and became adept at it. Like Larry, it's still my goto today and even prefer to Word for anything over a single page. On Sun, Sep 15, 2019 at 3:01 AM Dave Horsfall <dave@horsfall.org> wrote: > For some reason I prefer the MS macros, probably because I learnt them > first and I find it difficult to use MM. > The order I learned them was -mm {PWB}, -ms {V7}, -man {V7}, -ms {Tek}, -me {UCB}, -mS {MSCP}, -man {UCB version}. I feel into -ms with a couple of macros from -mS (.Li/Le for lists which were similar to MM's) for big documents, and the UCB -man for really simple things. It becomes a 'less is more' sort of thing - -mm and too complicated and I was not writing BTL tech memos, and after I did not my thesis, I did not need Eric's work (which was perfect for a UCB thesis). [-- Attachment #2: Type: text/html, Size: 1815 bytes --]
On 15/09/2019 20:35, Clem Cole wrote: > > > On Sat, Sep 14, 2019 at 11:03 PM U'll Be King of the Stars > <ullbeking@andrewnesbit.org <mailto:ullbeking@andrewnesbit.org>> wrote: > > > I've been wondering whether it is possible and worthwhile to use *roff > for complex technical documentation. I've always loved the aesthetic > that books produced using *roff have but there are other reasons too. > > Ditto. The books that used roff can look clean and within a series are > usually consistent, but what I've like is that they are different. Yes, they look clean but different to each other. I'm guessing that the reason might be that it is easier to exercise *roff's capabilities than it is to push LaTeX to get good results without spending a huge amount of time. > The Prentiss-Hall series and the ORA books both were produced using > troff and different versions of ms, but the results are different. I wonder if Prentice-Hall and O'Reilly & Associates might be willing to share their *roff macro sets in an open source way. > One of my complained with LaTex books is they all seem to look the same. Don't they ever?! It has gotten to the point that Computer Modern actually makes me feel *fatigued* when I encounter it when reading, say, a mathematics monograph. On the other hand it's the perfect typeface for résumés and CV's for computer scientists. Like a secret handshake. Perhaps the reason that the CM typeface is so common is that changing typefaces in LaTeX is complicated and difficult so authors leave it alone. At least this has been my experience. > Getting back to *roff, does anybody know if there is a (hopefully rich) > repository of macros, or any other resources, for my use case? > > I've never seen one. As far as I knew it, publishers sometimes seeded > authors. ORA used the Masscomp/Tektronix derived version of ms (-mS) > that Steve Talbot created (and Rick LeFaivre originally created from the > original Lesk V7 set). Rich Steven's has his own additions to the > version of ms that came with groff which I have also seen. This is fascinating insider information, and it leads me full circle to several reasons why I want to try to use *roff in the first place: 1. Do you think there is any chance of obtaining these macro packages? Either from authors who haven't passed away, or from the publishing houses themselves? 2. I get the impression that writing a macro package or editing an existing is relatively straightforward. Would you agree? Or, at least, that it makes some kind of sense. I could never make head or tail of LaTeX's macro extensions. I certainly didn't want to spend my life trying to figure it out. I still remember the sinking feeling in my stomach when I realized that the five (or so) books that make up the de facto canon of LaTeX user documentation (published by Addison-Wesley) are thousands of pages in total. I did not want to engage with that. I have no particular intention to speak ill of LaTeX. Rather, it is my only point of reference for publishing-grade typesetting and unfortunately I don't have fond memories of it. Kind regards, Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
[-- Attachment #1: Type: text/plain, Size: 828 bytes --] On Sun, 15 Sep 2019, Clem Cole wrote: > The order I learned them was -mm {PWB}, -ms {V7}, -man {V7}, -ms {Tek}, > -me {UCB}, -mS {MSCP}, -man {UCB version}. I feel into -ms with a > couple of macros from -mS (.Li/Le for lists which were similar to MM's) > for big documents, and the UCB -man for really simple things. It > becomes a 'less is more' sort of thing - -mm and too complicated and I > was not writing BTL tech memos, and after I did not my thesis, I did not > need Eric's work (which was perfect for a UCB thesis). For me it was ROFF (V5), -man (V6), -ms (V6). These days I don't need markup any more; the most complicated things I write are letters using TextEdit on the Mac, and C/Perl/etc with VI :-) Actually on the odd occasion I need markup it's "groff -ms -Tps" on the FreeBSD box. -- Dave
> Excellent - thanks for the pointer. This shows nroff before troff.
> FWIW: I guess I was miss informed, but I had been under the impression
> that was the other way around. i.e. nroff was done to be compliant with
> the new troff, replacing roff, although the suggestion here is that he
> wrote it add macros to roff. I'll note that either way, the dates are all
> possible of course because the U/L case ASR 37 was introduced 1968 so by
> the early 1970's they would have been around the labs.
nroff was in v2; troff appeared in v4, which incidentally was
typeset in troff.
Because of Joe Ossanna's role in designing the model 37, we
had 37's in the Labs and even in our homes right from the
start of production. But when they went obsolete, they were
a chore to get rid of. As Labs property, they had to be
returned; and picking them up was nobody's priority.
Andy Hall had one on his back porch for a year.
Doug
Clem Cole <clemc@ccc.com> wrote:
> On Sun, Sep 15, 2019 at 2:55 AM <arnold@skeeve.com> wrote:
>
> > Texinfo is *by far* the superior markup language.
> >
> I'll take your work for it, but my complaint is it requires emacs to use as
> the pager on my screen. If you live in emacs, that makes sense; but most
> people, even in the GNU/Linux world, don't.
Not true at all. I don't use Emacs, never have, and likely never will.
I use the standalone Info reader (named info) if I want to look at the
Info output. But as I mentioned already, I usually look at the Texinfo
documentation I'm working on via PDF or HTML.
And gvim has very nice syntax highlighting for Texinfo input files.
Arnold
"U'll Be King of the Stars" <ullbeking@andrewnesbit.org> wrote: > This is fascinating insider information, and it leads me full circle to > several reasons why I want to try to use *roff in the first place: > > 1. Do you think there is any chance of obtaining these macro packages? > Either from authors who haven't passed away, or from the publishing > houses themselves? O'Reilly probably would. I can ask someone there, if there's serious interest here. They haven't used troff for book production for well over a decade. I'm not sure that Prentice-Hall had its own macros. Rather, the books from Bell Labs were all set on the same research Unix systems. > 2. I get the impression that writing a macro package or editing an > existing is relatively straightforward. Would you agree? Possibly straightforward, but very much like working in assembly language. The commands and escape sequences (in standard troff) are all very short, and thus cryptic, and the extra levels of backslashes needed inside macro bodies don't help. GNU troff has additional features that probably help a lot; my experience has been in grunging around in traditional packages. My two cents, Arnodl
[-- Attachment #1: Type: text/plain, Size: 594 bytes --] On Mon, Sep 16, 2019 at 1:52 AM <arnold@skeeve.com> wrote: > I use the standalone Info reader (named info) if I want to look at the > Info output. > Fair enough, but be careful, while I admit I have not looked in a while, info(gnu) relies on emacs keybindings and a number of very emacs'ish things. Every time I have tried to deal with it, I have unprogram my fingers and reset them to emacs. If it would have used more(1) [or even less(1)] then I would not be as annoyed. Unix had fine tools [man(1), more(1), et al] and rms and friends felt the need to replace them with ITS-like programs. [-- Attachment #2: Type: text/html, Size: 1538 bytes --]
[-- Attachment #1: Type: text/plain, Size: 508 bytes --] On Mon, Sep 16, 2019 at 2:21 AM <arnold@skeeve.com> wrote: > I'm not sure that Prentice-Hall had its own macros. Rather, the > books from Bell Labs were all set on the same research Unix systems. > That's might be true for bwk's and Pike's stuff, but not Rich Steven's or Comer's books. I know for fact that Rich had a set of macro's (based originally on -ms) and a set of integrated makefiles to build his texts. I was under the impression he passed them to a number of people, not just people like me. [-- Attachment #2: Type: text/html, Size: 1030 bytes --]
Clem Cole wrote:
> Unix had fine tools [man(1), more(1), et al] and rms and friends felt
> the need to replace them with ITS-like programs.
Emacs and Info are rather blatantly are not anywhere near the Unix
philosophy. (Maybe they can be useful anyway.)
However, please note that more(1) also was inspired by, almost copied
from, ITS. Certainly the prompt --More-- is.
Clem Cole <clemc@ccc.com> wrote: > On Mon, Sep 16, 2019 at 2:21 AM <arnold@skeeve.com> wrote: > > > I'm not sure that Prentice-Hall had its own macros. Rather, the > > books from Bell Labs were all set on the same research Unix systems. > > > That's might be true for bwk's and Pike's stuff, but not Rich Steven's or > Comer's books. I know for fact that Rich had a set of macro's (based > originally on -ms) and a set of integrated makefiles to build his texts. I > was under the impression he passed them to a number of people, not just > people like me. Don't know, but you could try http://www.unixnetworkprogramming.com/contact.html for the Unix Network Programming book which was updated after Richard Stevens passed away. Arnold
On 9/16/19 8:10 AM, Clem Cole wrote: > I use the standalone Info reader (named info) if I want to look at the > Info output. > > Fair enough, but be careful, while I admit I have not looked in a while, > info(gnu) relies on emacs keybindings and a number of very emacs'ish things. > Every time I have tried to deal with it, I have unprogram my fingers and > reset them to emacs. > > If it would have used more(1) [or even less(1)] then I would not be as annoyed. It seems to me that the strength of info (the file format and program) is the navigation of a menu-driven hierarchical document containing what are essentially selectable links between sections. Something like more or less is poorly suited to take advantage of those features. You need a way to position the cursor with more flexibility than more gives you. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/
[-- Attachment #1: Type: text/plain, Size: 2183 bytes --] On Mon, Sep 16, 2019 at 8:26 AM Lars Brinkhoff <lars@nocrew.org> wrote: > However, please note that more(1) also was inspired by, almost copied > from, ITS. Certainly the prompt --More-- is. > Absolutely. A friend of mine/fellow UCB grad student, Eric Shienbrood, wrote it. He was a MIT undergrad. And Eric happily said it was modeled from ITS. And before, Eric wrote it, UNIX lacked anything like it. Which to me is fine, t*aking an idea from another system to add a new feature that is lacking.* What irks me is the blatant force-feeding of any system to the users, be it ITS, UNIX or Windows into another. It's ok to offer an alternative interface, but when the system has a mechanism, your tools need to be *socially compliant* with it, not try to make 'those users become like me.' Frankly, that is a pretty arrogant behavior. Yes, I know the argument is two fold. GNU is not UNIX and we wrote it (he who has the gold, gets to rule). BTW: If it makes you feel better, I've been fighting this attitude at a number of places, particularly Intel, for years. For instance, our dev tools folks wrote their own Installer 'because it was easier for them and they could use it everywhere'). That's a no-no. If you have Windows product, you must use Microsoft's installer, if you have a Mac, you use what Apple gives you, if you have VMS, you used the (wretched) setld, or in this case, for Linux its rpm/yum et al.; etc. But they had their own 'installer group' and it was easier for >>them<< than for the users. I think the rule of 'least astonishment' is what needs to be the high order bit when building tools for people. Again, offering emacs (or any other ITS tool) is fine, but when the new tool is installed on Windows/UNIX/Mac et.. it needs to behave itself with the rest of the system, particularly if there is already a mechanism in place to do a support function. Simply, I would not mind info(gnu) and texinfo(gnu) if there was a way to created man pages (or Windows / Mac help). But having a man page that basically says, see figure one <https://www.dourish.com/goodies/see-figure-1.html> is not cool. my 2 cents from a grumpy old guy.... Clem [-- Attachment #2: Type: text/html, Size: 4208 bytes --]
On Mon, Sep 16, 2019 at 08:10:48AM -0400, Clem Cole wrote:
> On Mon, Sep 16, 2019 at 1:52 AM <arnold@skeeve.com> wrote:
>
> > I use the standalone Info reader (named info) if I want to look at the
> > Info output.
> >
> Fair enough, but be careful, while I admit I have not looked in a while,
> info(gnu) relies on emacs keybindings and a number of very emacs'ish things.
> Every time I have tried to deal with it, I have unprogram my fingers and
> reset them to emacs.
>
> If it would have used more(1) [or even less(1)] then I would not be as
> annoyed.
> Unix had fine tools [man(1), more(1), et al] and rms and friends felt the
> need to replace them with ITS-like programs.
I hate texinfo and friends. I get why it is better than man, but man was
good enough, more than good enough, and the GNU project took everything
it could find and destroyed the man pages.
If you have something like perl that needs a zillion sub pages, info
makes sense. For just a man page, info is horrible.
On Mon, Sep 16, 2019 at 08:13:55AM -0400, Clem Cole wrote:
> On Mon, Sep 16, 2019 at 2:21 AM <arnold@skeeve.com> wrote:
>
> > I'm not sure that Prentice-Hall had its own macros. Rather, the
> > books from Bell Labs were all set on the same research Unix systems.
> >
> That's might be true for bwk's and Pike's stuff, but not Rich Steven's or
> Comer's books. I know for fact that Rich had a set of macro's (based
> originally on -ms) and a set of integrated makefiles to build his texts. I
> was under the impression he passed them to a number of people, not just
> people like me.
I don't have them but he and I had many discussions about troff, tbl,
pic, etc. We had a shared love for pic.
Holy smokes, Clem, you are me and I am you. I couldn't agree more with this post, especially 'least astonishment'. On Mon, Sep 16, 2019 at 09:42:56AM -0400, Clem Cole wrote: > What irks me is the blatant force-feeding of any system to the users, be it > ITS, UNIX or Windows into another. It's ok to offer an alternative > interface, but when the system has a mechanism, your tools need to be *socially > compliant* with it, not try to make 'those users become like me.' > Frankly, that is a pretty arrogant behavior. Yes, I know the argument is > two fold. GNU is not UNIX and we wrote it (he who has the gold, gets to > rule). > > BTW: If it makes you feel better, I've been fighting this attitude at a > number of places, particularly Intel, for years. For instance, our dev > tools folks wrote their own Installer 'because it was easier for them and > they could use it everywhere'). That's a no-no. If you have Windows > product, you must use Microsoft's installer, if you have a Mac, you use > what Apple gives you, if you have VMS, you used the (wretched) setld, or in > this case, for Linux its rpm/yum et al.; etc. But they had their own > 'installer group' and it was easier for >>them<< than for the users. > > I think the rule of 'least astonishment' is what needs to be the high order > bit when building tools for people. Again, offering emacs (or any other > ITS tool) is fine, but when the new tool is installed on Windows/UNIX/Mac > et.. it needs to behave itself with the rest of the system, particularly if > there is already a mechanism in place to do a support function. > > Simply, I would not mind info(gnu) and texinfo(gnu) if there was a way to > created man pages (or Windows / Mac help). But having a man page that > basically says, see figure one > <https://www.dourish.com/goodies/see-figure-1.html> is not cool. > > my 2 cents from a grumpy old guy.... > Clem -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
[-- Attachment #1: Type: text/plain, Size: 696 bytes --] On Mon, Sep 16, 2019 at 10:51 AM Larry McVoy <lm@mcvoy.com> wrote: > I hate texinfo and friends. I get why it is better than man, but man was > good enough, more than good enough, and the GNU project took everything > it could find and destroyed the man pages. > Amen, bro. As I said, it was not 'social compliant' which was really a not very nice thing to do. It's arrogant to say in effect "your way is wrong, I'm going to try to kill it off." > > If you have something like perl that needs a zillion sub pages, info > makes sense. For just a man page, info is horrible. I'm not even sure, I like that, to be honest. I'm 'old school' enough to rather use a book from ORA or the like. [-- Attachment #2: Type: text/html, Size: 1693 bytes --]
[-- Attachment #1: Type: text/plain, Size: 312 bytes --] Is it any surprise that the early GNU effort was really trying to recreate ITS? Can you really blame them? I'm grateful that they made `info` be a standalone program. Putting the concept of "cursor position" into the existing pagers (more/less/etc) and doing jump/xref/back would be more than a stretch, IMO. [-- Attachment #2: Type: text/html, Size: 370 bytes --]
> On Sep 16, 2019, at 11:14 AM, Richard Salz <rich.salz@gmail.com> wrote:
>
> Is it any surprise that the early GNU effort was really trying to recreate ITS? Can you really blame them? I'm grateful that they made `info` be a standalone program. Putting the concept of "cursor position" into the existing pagers (more/less/etc) and doing jump/xref/back would be more than a stretch, IMO.
>
Having been an early UNIX Emacs adoptee (I never really learned VI, if there was no emacs, I just used ed. A tendency that my employees always found amusing), I could never tolerate INFO in any of its forms (either ITS or on UNIX).
It was far too cumbersome for the features it claimed to add to the mix.
As for formatters, my biggest gripe with many of them is that I should not be able to tell what the formatter is by looking at the output. This is where Tex fails. It’s ugly style always seems to telegraph through. The only thing that is worse is those odd little bumps on the top of pic-framed tbl output.
On 9/16/19, Clem Cole <clemc@ccc.com> wrote: > On Mon, Sep 16, 2019 at 8:26 AM Lars Brinkhoff <lars@nocrew.org> wrote: > > What irks me is the blatant force-feeding of any system to the users, be it > ITS, UNIX or Windows into another. It's ok to offer an alternative > interface, but when the system has a mechanism, your tools need to be > *socially > compliant* with it, not try to make 'those users become like me.' > Frankly, that is a pretty arrogant behavior. Yes, I know the argument is > two fold. GNU is not UNIX and we wrote it (he who has the gold, gets to > rule). Amen to that! As the old saying goes, "when in Rome, do as the Romans do". On UNIX, tools are expected to send output to stdout. On Windows, users expect text selection and ^C/^V copy-and-paste to work. On VMS, you use the CLI interface to parse the command line. And so on. The principle of least astonishment should always be foremost in user interaction design. > BTW: If it makes you feel better, I've been fighting this attitude at a > number of places, particularly Intel, for years. For instance, our dev > tools folks wrote their own Installer 'because it was easier for them and > they could use it everywhere'). That's a no-no. If you have Windows > product, you must use Microsoft's installer, if you have a Mac, you use > what Apple gives you, if you have VMS, you used the (wretched) setld, or in > this case, for Linux its rpm/yum et al.; etc. But they had their own > 'installer group' and it was easier for >>them<< than for the users. I used to work in that organization. The installer situation is one of the worst cases of not-invented-here syndrome that I've ever seen. Or maybe it was just empire building by some ambitious manager. The "it's easier for us and we can use it everywhere" argument is pure BS. Any savings that they got from having the a common code base for the installer was wiped out by all the extra development effort needed to track the release-to-release changes that the various platforms made to their software deployment setup. Their installer was always a step or two behind the curve, late in supporting new platform features, and full of subtle bugs and mis-implemented edge conditions. It wasn't really "easier for them" in the long run after all. It was a maintenance nightmare. -Paul W.
On Mon, Sep 16, 2019 at 11:14:25AM -0400, Richard Salz wrote:
> Is it any surprise that the early GNU effort was really trying to recreate
> ITS? Can you really blame them? I'm grateful that they made `info` be a
> standalone program. Putting the concept of "cursor position" into the
> existing pagers (more/less/etc) and doing jump/xref/back would be more than
> a stretch, IMO.
It's what Clem said. You should acclimate yourself to your environment.
Pushing info into man environment is a lot like being an immigrant and
wanting to bring your laws into your new homeland. That isn't a thing
and shouldn't be a thing. Doesn't matter that people think ITS is better,
they are in Unix. If you think ITS is better, go live there.
When in Rome....
Larry McVoy writes:
> On Mon, Sep 16, 2019 at 11:14:25AM -0400, Richard Salz wrote:
> > Is it any surprise that the early GNU effort was really trying to recreate
> > ITS? Can you really blame them? I'm grateful that they made `info` be a
> > standalone program. Putting the concept of "cursor position" into the
> > existing pagers (more/less/etc) and doing jump/xref/back would be more than
> > a stretch, IMO.
>
> It's what Clem said. You should acclimate yourself to your environment.
> Pushing info into man environment is a lot like being an immigrant and
> wanting to bring your laws into your new homeland. That isn't a thing
> and shouldn't be a thing. Doesn't matter that people think ITS is better,
> they are in Unix. If you think ITS is better, go live there.
>
> When in Rome....
Well, in the shameless department, I can quote from my book:
Mucking up the ecosystem into which you release code does not
add value. Many developers behave as if they’re stereotypical
Americans vacationing in another country, or for that matter my
father-in-law visiting — the “I just came to your place, so do
things my way” attitude.
For example, UNIX systems have a command that displays manual pages
for programs. You can type man foo and it’ll show you the page
for the foo command. There’s also a convention that really complex
commands, such as yacc , have both a manual page and a longer, more
in-depth document that describes the program in more detail. When
the GNU project (which I’ll discuss shortly) added commands to
UNIX, it used its own texinfo system for manuals, which wasn’t
compatible with the man system. The result was that users would have
to try both the man and info commands to find documentation. Even
if, as some believe, the GNU approach was superior, any possible
benefits were outweighed by the UNIX community’s huge loss of
productivity that resulted from the fragmented ecosystem.
+1 On Mon, Sep 16, 2019 at 09:16:03AM -0700, Jon Steinhart wrote: > Larry McVoy writes: > > On Mon, Sep 16, 2019 at 11:14:25AM -0400, Richard Salz wrote: > > > Is it any surprise that the early GNU effort was really trying to recreate > > > ITS? Can you really blame them? I'm grateful that they made `info` be a > > > standalone program. Putting the concept of "cursor position" into the > > > existing pagers (more/less/etc) and doing jump/xref/back would be more than > > > a stretch, IMO. > > > > It's what Clem said. You should acclimate yourself to your environment. > > Pushing info into man environment is a lot like being an immigrant and > > wanting to bring your laws into your new homeland. That isn't a thing > > and shouldn't be a thing. Doesn't matter that people think ITS is better, > > they are in Unix. If you think ITS is better, go live there. > > > > When in Rome.... > > Well, in the shameless department, I can quote from my book: > > Mucking up the ecosystem into which you release code does not > add value. Many developers behave as if they???re stereotypical > Americans vacationing in another country, or for that matter my > father-in-law visiting ??? the ???I just came to your place, so do > things my way??? attitude. > > For example, UNIX systems have a command that displays manual pages > for programs. You can type man foo and it???ll show you the page > for the foo command. There???s also a convention that really complex > commands, such as yacc , have both a manual page and a longer, more > in-depth document that describes the program in more detail. When > the GNU project (which I???ll discuss shortly) added commands to > UNIX, it used its own texinfo system for manuals, which wasn???t > compatible with the man system. The result was that users would have > to try both the man and info commands to find documentation. Even > if, as some believe, the GNU approach was superior, any possible > benefits were outweighed by the UNIX community???s huge loss of > productivity that resulted from the fragmented ecosystem. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
[-- Attachment #1: Type: text/plain, Size: 158 bytes --] I don't think it's totally GNU's fault that it became Linux. They weren't trying to be tourists in Rome, they were trying to create a new city of their own. [-- Attachment #2: Type: text/html, Size: 229 bytes --]
On Mon, Sep 16, 2019 at 12:31:13PM -0400, Richard Salz wrote:
> I don't think it's totally GNU's fault that it became Linux. They weren't
> trying to be tourists in Rome, they were trying to create a new city of
> their own.
Yeah, except they didn't create their own city, they pooped all over a
different one. There is no defense for what they did. If they did the
right thing they would have created a markup language that could have
produced info files and man files.
It's not that hard, I wrote something called webroff that took -ms
format input and produced a website complete with the navigation tree,
it defaulted to showing you a page (each .NH) at time but it also had
a site map where you could see the entire document as a single page,
or each major section (.NH 1) as a page.
For more than a decade this was BitMover's home page. I can't tell
you how many sales calls I've been on and I've seen the entire web
site printed out on the manager's desk.
The reality is there was absolutely no need for a new format for
info files, they could have parsed man input and produced info
files and that's what they should have done.
Those who defend the choice of info over man just aren't real Unix
people. And that's fine, Unix isn't the only choice, they can go
run some other OS and be happy. But it's just rude to thrust info
into a Unix system. And lame because they could have parsed man
pages into info docs and then they are adopting the Unix way of
doing things and actually adding value.
[-- Attachment #1: Type: text/plain, Size: 1565 bytes --] I note that it wasn't "GNI" it was GNU or he would have started with LISP. The fact is rms started by wanting to hack/rewrite Gosling EMACS as it had been released and some of the other C versions were at the same time a little less open to him as a starting point. Since it was not in LISP, he needed to write a C Compiler (which I still think is the #1 positive thing from the Gnu project and in the end, I believe that it was others that really made the compiler the success, not rms other than he tirelessly championed it). The reality is that the Gnu team quick set out to rewrite the UNIX tools and used Trix (a UNIX clone) as the original OS. Hurd did not come until later and in the Linux became the kernel it lived upon (as Jon says, it's Internet/Linux not Gnu/Linux). Sorry, IMO, rms tried to 'pee on Unix to make it smell like ITS' - not surprising as you say. But pretty darned arrogant none-the less. The results makes using many of the tools "astonishing" to everyone else. +1 to Jon's comments. "Even if, as some believe, the GNU approach was superior, any possible benefits were outweighed by the UNIX community’s huge loss of productivity that resulted from the fragmented ecosystem." Amen brother Jon, and this week's free will offering will be sponsoring .... On Mon, Sep 16, 2019 at 12:31 PM Richard Salz <rich.salz@gmail.com> wrote: > I don't think it's totally GNU's fault that it became Linux. They weren't > trying to be tourists in Rome, they were trying to create a new city of > their own. > [-- Attachment #2: Type: text/html, Size: 3299 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2010 bytes --] On Mon, Sep 16, 2019 at 09:45:02AM -0700, Larry McVoy wrote: [cut] > > Those who defend the choice of info over man just aren't real Unix > people. And that's fine, Unix isn't the only choice, they can go > run some other OS and be happy. But it's just rude to thrust info > into a Unix system. And lame because they could have parsed man > pages into info docs and then they are adopting the Unix way of > doing things and actually adding value. Sorry, but I totally don't see the point here. The problem is not the technology, but the adopters. I personally don't like info at all, and still swear whenever a software comes without a proper manpage, but info has not been shovelled down your throat (or anybody else's, for that matter). The adopters have decided that info was fine for their use case. They could have written manpages and send patches over, and in many cases they didn't. There is plenty of software coming from the GNU project that has comprehensive and clear manpages (just to cite a single example, bash(1) comes with manpages, and no info doc). At the same time, there is tons of "Unix" software around that comes without any documentation *at all*, or with scant text files covering the bare basics. Unfortunately this trend is only getting worse, and we have far too many notaable examples here, not all of them coming from the GNU project, or from the "ITS tradition", whatever it means for you. I agree that whoever does not produce a readily usable documentaion for their software has not really understood much of the Unix philosophy. But that's not at all a matter of formats, rather of culture. Then, if you just want to vomit on info, or you prefer to use info as another excuse to vomit on the GNU project, well go ahead. But the actual issue is elsewhere (the lack of respect for the users, and the tendency to hide stuff under the carpet), and has not been introduced by the GNU project, at all. My2Cents Enzo Nicosia [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --]
On Mon, Sep 16, 2019 at 07:19:05PM +0200, KatolaZ wrote:
> On Mon, Sep 16, 2019 at 09:45:02AM -0700, Larry McVoy wrote:
>
> [cut]
>
> >
> > Those who defend the choice of info over man just aren't real Unix
> > people. And that's fine, Unix isn't the only choice, they can go
> > run some other OS and be happy. But it's just rude to thrust info
> > into a Unix system. And lame because they could have parsed man
> > pages into info docs and then they are adopting the Unix way of
> > doing things and actually adding value.
>
> Sorry, but I totally don't see the point here.
Jon put it well, the point is people expect to be able to say
man foo
and have that work. Until GNU came along, that's the way it was.
GNU pushed a different system into the mix.
The secondary point is they could have *added* to Unix by making a
man2info command, I know they could have because I've done something
similar, parsing man or -ms pages is trivial.
GNU choose not to do that and I can't begin to express how wrong
that was. GNU is not Unix for sure.
[-- Attachment #1: Type: text/plain, Size: 2417 bytes --] On Mon, Sep 16, 2019 at 12:45 PM Larry McVoy <lm@mcvoy.com> wrote: > Yeah, except they didn't create their own city, they pooped all over a > different one. peed *vs.* pooped - one is marking territory while the other is destroying it. It is interesting that both analogs work here, however. There is no defense for what they did. If they did the > right thing they would have created a markup language that could have > produced info files and man files. > +1 and that's why it is even more difficult to understand. Being polite and 'fitting in' would really not been any harder than being like Jon's father-in-law. > .... > Those who defend the choice of info over man just aren't real Unix people. I'd maybe say it as they don't want to be real Unix people and fit it with the rest. > And that's fine, Unix isn't the only choice, they can go > run some other OS and be happy. Frankly, trying to turn a Lisp Machine into a "Unix box" would have been as much of sin, in my eyes. Hey, I'm thrilled to see rms and his friends can build and purchase as many LMI box as he would like (But I do observe, the 'technically superior system,' in the end, wasn't very economical). I really don't mind bringing things over (like more, or job control, or command/filename completion that all came from other systems). That is really adding value to the new system (UNIX in this case). But it's just rude to thrust info > into a Unix system. And lame because they could have parsed man > pages into info docs and then they are adopting the Unix way of > doing things and actually adding value. touché As Larry and Jon have said better than I, it was the seemly effect of trying to replace man with info that I just don't understand. As Larry has said if they had made a way go from texinfo to man, even if it had been a little rough on the edges, I might have grumbled, but I would have tried to use it. The truth is today, like many other Unix hacker I know, if I am offered a new tool but using it means that I am being led down a path to use info/texinfo, I rethink if I want to use that new tool or not. It's a big turn off for me to want to learn to use such a tool since I know the authors have made no attempt to integrate it into a traditional UNIX workflow if they have not built proper man pages, much less written traditional docs. [-- Attachment #2: Type: text/html, Size: 5465 bytes --]
Larry McVoy writes:
> On Mon, Sep 16, 2019 at 07:19:05PM +0200, KatolaZ wrote:
> > On Mon, Sep 16, 2019 at 09:45:02AM -0700, Larry McVoy wrote:
> >
> > [cut]
> >
> > >
> > > Those who defend the choice of info over man just aren't real Unix
> > > people. And that's fine, Unix isn't the only choice, they can go
> > > run some other OS and be happy. But it's just rude to thrust info
> > > into a Unix system. And lame because they could have parsed man
> > > pages into info docs and then they are adopting the Unix way of
> > > doing things and actually adding value.
> >
> > Sorry, but I totally don't see the point here.
>
> Jon put it well, the point is people expect to be able to say
>
> man foo
>
> and have that work. Until GNU came along, that's the way it was.
> GNU pushed a different system into the mix.
>
> The secondary point is they could have *added* to Unix by making a
> man2info command, I know they could have because I've done something
> similar, parsing man or -ms pages is trivial.
>
> GNU choose not to do that and I can't begin to express how wrong
> that was. GNU is not Unix for sure.
So I'm not really trying to be all that shameless, it's just that I've already
written down my opinions on this sort of stuff and don't need to retype it all.
From a section entitled "The Value Proposition":
There's an overarching question that you should keep in mind when
working on a project: "Am I adding value?" I'm not talking about
the intrinsic value of accomplishing some task here; I'm talking
about increasing productivity.
If you're programming for a living, you need to meet whatever goals
your employer has set. But, of course, there's more than one way
to meet those goals. You could just do what you need to do to get
by. Or, you could put a little thought into things that might not
have occurred to management. For example, you might realize that
your code would be useful in another project and structure it so
it's easily reusable. Or, you might sense that you were tasked to
implement a special case of a more general problem and solve that
general problem instead, paving the way for future enhancements.
Of course, you should talk about this with management so that
they're not surprised.
You can add value to yourself by making sure that you're proficient
in a variety of technologies. Side projects are a common way to
get experience; it's equivalent to doing homework but more fun.
One classic way in which people attempt to add value is by
creating tools. This is trickier than it seems because sometimes
adding value for yourself reduces value for others. People often
create new tools because some feature that they think they need
is missing from existing ones. A good example is the make utility
(invented by Stuart Feldman at Bell Labs in 1976), which is used to
build large software packages. As time went on, new features were
needed. Some of these were added to make, but in many other cases,
people created well-intentioned but incompatible new utilities
that performed similar functions. (For example, I consulted for
a company once that wrote their own solely because they didn't
bother to completely read the make documentation and were unaware
that it would do exactly what they needed.) Now there's make,
cmake, dmake, imake, pick-a-letter-make, and other programs that
all do similar things in incompatible ways. The result is that
practitioners like you need to learn multiple tools in each category.
It makes everyone's life harder, not easier. It doesn't add
value—it detracts. Figure 15-1 sums up the situation nicely.
[ Figure 15-1 is the xkcd how standards proliferate cartoon ]
[-- Attachment #1: Type: text/plain, Size: 639 bytes --] On Mon, Sep 16, 2019 at 1:24 PM Larry McVoy <lm@mcvoy.com> wrote: > The secondary point is they could have *added* to Unix by making a > man2info command > Exactly!!!! That's what Eric did when he wrote more(ucb) - he *added to Unix*. The funny part was that USG thought more(ucb) was a good idea and then wrote their own, pg(att); which was just as arrogant as the info behavior from the Gnu folks!!! Later, Less(internet) replaced more, but only as a superset, building on the foundation and eventually USB chose to ship more also as so many people wanted it. As I said yesterday, standing on the shoulders, not on their toes. [-- Attachment #2: Type: text/html, Size: 1437 bytes --]
KatolaZ writes:
> Sorry, but I totally don't see the point here. The problem is not the
> technology, but the adopters. I personally don't like info at all, and
> still swear whenever a software comes without a proper manpage, but
> info has not been shovelled down your throat (or anybody else's, for
> that matter). The adopters have decided that info was fine for their
> use case. They could have written manpages and send patches over, and
> in many cases they didn't.
>
> There is plenty of software coming from the GNU project that has
> comprehensive and clear manpages (just to cite a single example,
> bash(1) comes with manpages, and no info doc). At the same time, there
> is tons of "Unix" software around that comes without any documentation
> *at all*, or with scant text files covering the bare basics.
>
> Unfortunately this trend is only getting worse, and we have far too
> many notaable examples here, not all of them coming from the GNU
> project, or from the "ITS tradition", whatever it means for you.
>
> I agree that whoever does not produce a readily usable documentaion
> for their software has not really understood much of the Unix
> philosophy. But that's not at all a matter of formats, rather of
> culture.
>
> Then, if you just want to vomit on info, or you prefer to use info as
> another excuse to vomit on the GNU project, well go ahead. But the
> actual issue is elsewhere (the lack of respect for the users, and the
> tendency to hide stuff under the carpet), and has not been introduced
> by the GNU project, at all.
>
> My2Cents
>
> Enzo Nicosia
It seems to me that you're missing the point here. It's not a question of
whether or not GNU programs have good documentation. It's the fact that
GNU made it hard to find documentation because they took one pile and split
it into two with no guide to what was in each pile. It's not that their
documentation was good or bad, it's that they made it hard to find any
documentation.
Maybe it's because I'm a child of the 60s, but I'm with Arlo Guthrie on this
one (from Alice's Restaurant): "And we decided that one big pile is better
than two little piles, and rather than bring that one up we decided to throw
ours down."
Jon
[-- Attachment #1.1: Type: text/plain, Size: 483 bytes --] On 9/16/19 1:19 PM, KatolaZ wrote: > There is plenty of software coming from the GNU project that has > comprehensive and clear manpages (just to cite a single example, > bash(1) comes with manpages, and no info doc). Bash comes with both a large man page and an extensive info doc. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/ [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #1: Type: text/plain, Size: 493 bytes --] On Mon, Sep 16, 2019 at 02:04:00PM -0400, Chet Ramey wrote: > On 9/16/19 1:19 PM, KatolaZ wrote: > > > There is plenty of software coming from the GNU project that has > > comprehensive and clear manpages (just to cite a single example, > > bash(1) comes with manpages, and no info doc). > > Bash comes with both a large man page and an extensive info doc. > Yep, sorry! I meant "and not only an info doc". And they are both of very good quality, IMHO. HND Enzo Nicosia [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --]
Richard Salz wrote in <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc5\ 8A@mail.gmail.com>: |Is it any surprise that the early GNU effort was really trying to recreate \ |ITS? Can you really blame them? I'm grateful that they made `info` \ |be a standalone program. Putting the concept of "cursor |position" into the existing pagers (more/less/etc) and doing jump/xref/b\ |ack would be more than a stretch, IMO. So that is actually not true, really. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
The way Rob solved the problem in acme(1) is much nicer.
Right click on |open(2)| and its man page opens up in a
new window. You can do the same on any manpage mentioned
in the SEE ALSO section or anywhere else and you can see
their man page without any side-effect on the original
window. He didn't throw out any old documentation but
added a a new tool to make navigation easier (and it is
more general in that you can define right click actions).
There was already cursor positioning available in vi. It
would not have been a real stretch to hack in acme like
support in less or vi (clumsier without a mouse but still).
In fact tag support in vi already did something like it
with ^] and ^^ for jump/back.
> On Sep 16, 2019, at 8:14 AM, Richard Salz <rich.salz@gmail.com> wrote:
>
> Is it any surprise that the early GNU effort was really trying to recreate ITS? Can you really blame them? I'm grateful that they made `info` be a standalone program. Putting the concept of "cursor position" into the existing pagers (more/less/etc) and doing jump/xref/back would be more than a stretch, IMO.
>
[-- Attachment #1: Type: text/plain, Size: 518 bytes --] On Mon, 16 Sep 2019, Clem Cole wrote: > Fair enough, but be careful, while I admit I have not looked in a while, > info(gnu) relies on emacs keybindings and a number of very > emacs'ish things. Every time I have tried to deal with it, I have > unprogram my fingers and reset them to emacs. Yep, which is why I like "info" as much as I like EMACS i.e. not at all. What exactly is wrong with the manpage format? It tells you everything you need to know, and tells you where to find further information. -- Dave
On Tue, Sep 17, 2019 at 07:42:28AM +1000, Dave Horsfall wrote:
> On Mon, 16 Sep 2019, Clem Cole wrote:
>
> >Fair enough, but be careful, while I admit I have not looked in a while,
> >info(gnu) relies on emacs keybindings and a number of very
> >emacs'ish??things. Every time I have tried to deal with it, I have
> >unprogram my fingers and reset them to emacs.
>
> Yep, which is why I like "info" as much as I like EMACS i.e. not at all.
>
> What exactly is wrong with the manpage format? It tells you everything you
> need to know, and tells you where to find further information.
I think, someone correct me if I'm wrong, the info stuff was designed
to handle larger, more complex stuff, with a table of contents, etc.
Something like perl could fit in one info doc but the perl man page is
not a thing, it's just a series of pointers to more man pages.
Larry McVoy writes:
>
> I think, someone correct me if I'm wrong, the info stuff was designed
> to handle larger, more complex stuff, with a table of contents, etc.
> Something like perl could fit in one info doc but the perl man page is
> not a thing, it's just a series of pointers to more man pages.
Can't answer you directly on this one, but I prefer the old system of
having man pages and separate documents for longer things. I still
have old notebooks full of papers on lex, yacc, and so on.
One of the problems with using info for something like perl is that it
doesn't have a useful organization. There's a difference to me between
a reference manual and a user's guide. Most of the stuff referenced by
the main perl page is user's guide stuff to me, it's not a reference.
Probably someone knows more than me about all this. I have always been
under the impression that one read the user's guide to learn about
complicated stuff. The manual pages were there so that you could find
the right options when you forgot. Putting every detail about a complex
program into a manual page doesn't feel right to me.
Jon
On Mon, Sep 16, 2019 at 02:54:49PM -0700, Jon Steinhart wrote:
> Larry McVoy writes:
> >
> > I think, someone correct me if I'm wrong, the info stuff was designed
> > to handle larger, more complex stuff, with a table of contents, etc.
> > Something like perl could fit in one info doc but the perl man page is
> > not a thing, it's just a series of pointers to more man pages.
>
> Can't answer you directly on this one, but I prefer the old system of
> having man pages and separate documents for longer things. I still
> have old notebooks full of papers on lex, yacc, and so on.
>
> One of the problems with using info for something like perl is that it
> doesn't have a useful organization.
We are 100% on the same page. My complaint about wikis is it is impossible
to find anything without a search engine. I like tables of contents and
indices.
My comment on the info stuff was just my understand of why it came to be.
[-- Attachment #1: Type: text/plain, Size: 600 bytes --] On Mon, 16 Sep 2019, Clem Cole wrote: > > However, please note that more(1) also was inspired by, almost > > copied from, ITS. Certainly the prompt --More-- is. > > Absolutely. A friend of mine/fellow UCB grad student, Eric Shienbrood, > wrote it. He was a MIT undergrad. And Eric happily said it was modeled > from ITS. And before, Eric wrote it, UNIX lacked anything like it. > Which to me is fine, taking an idea from another system to add a new > feature that is lacking. Am I the only one who remembers the old "pg" program? It seems to have disappeared. -- Dave
On Mon, 16 Sep 2019 14:54:49 -0700 Jon Steinhart <jon@fourwinds.com> wrote:
> Larry McVoy writes:
> >
> > I think, someone correct me if I'm wrong, the info stuff was designed
> > to handle larger, more complex stuff, with a table of contents, etc.
> > Something like perl could fit in one info doc but the perl man page is
> > not a thing, it's just a series of pointers to more man pages.
>
> Can't answer you directly on this one, but I prefer the old system of
> having man pages and separate documents for longer things. I still
> have old notebooks full of papers on lex, yacc, and so on.
>
> One of the problems with using info for something like perl is that it
> doesn't have a useful organization. There's a difference to me between
> a reference manual and a user's guide. Most of the stuff referenced by
> the main perl page is user's guide stuff to me, it's not a reference.
>
> Probably someone knows more than me about all this. I have always been
> under the impression that one read the user's guide to learn about
> complicated stuff. The manual pages were there so that you could find
> the right options when you forgot. Putting every detail about a complex
> program into a manual page doesn't feel right to me.
A typical manpage had just the right length. Reading man pages
and experimenting is how I initially learned all about unix
commands.
Keeping a manpage short also limited what you as the
implementer would be tempted to add to the command. Manpages
work best for programs that follow the unix mantra of do one
thing and do it well. But not for kitchensink programs. When
you need a multipage reference manual (for *experts*) with a
TOC and program to "navigate", you're much more likely to give
into the temptation of adding more features than partition
functionality into separate programs that work well together.
Not to mention it is harder to get something right that has
many more features.
> Am I the only one who remembers the old "pg" program? It seems to have
> disappeared.
I see two different pg. One in the 32V sources and the other first
Usenix delaware collection. (Both in TUHS archives)
Another pager "cr3" is in 1BSD collection (which was replaced by
Halbert's more in 3BSD).
[-- Attachment #1: Type: text/plain, Size: 439 bytes --] On Mon, 16 Sep 2019, Clem Cole wrote: > > If you have something like perl that needs a zillion sub pages, > > info makes sense. For just a man page, info is horrible. > > I'm not even sure, I like that, to be honest. I'm 'old school' enough to > rather use a book from ORA or the like. Or use www.perltutorial.org which is a good resource; I often get stuck on the finer points of Perl, such as the OO stuff. -- Dave
On Mon, 16 Sep 2019, Chet Ramey wrote:
> Bash comes with both a large man page and an extensive info doc.
On my (obsolete) FreeBSD box:
aneurin% man bash | wc -l
5947
Now there's a manpage that should have been split up...
On the same box:
aneurin% man zsh | wc -l
346
That's because it's got sub-pages, each describing a particular feature
(I've been using ZSH for years).
-- Dave
On 09/16/19 18:05, Dave Horsfall wrote:
> Am I the only one who remembers the old "pg" program? It seems to have
> disappeared.
Still ships with Solaris (in /usr/bin).
N.
On Mon, 16 Sep 2019, reed@reedmedia.net wrote:
>> Am I the only one who remembers the old "pg" program? It seems to have
>> disappeared.
>
> I see two different pg. One in the 32V sources and the other first
> Usenix delaware collection. (Both in TUHS archives)
We never ran 32V; our Vaxen - called "vaxa" and "vaxb" - ran VMS... I was
only in charge of the Unix PDP-11/40s sprinkled around the place (and the
odd /34 and /23).
-- Dave
[-- Attachment #1: Type: text/plain, Size: 1495 bytes --] On Tuesday, 17 September 2019 at 7:42:28 +1000, Dave Horsfall wrote: > On Mon, 16 Sep 2019, Clem Cole wrote: > >> Fair enough, but be careful, while I admit I have not looked in a while, >> info(gnu) relies on emacs keybindings and a number of very >> emacs'ish things. Every time I have tried to deal with it, I have >> unprogram my fingers and reset them to emacs. > > Yep, which is why I like "info" as much as I like EMACS i.e. not at > all. Maybe I've missed something, but I'm in the intermediate camp. Emacs is in my fingertips, and I wouldn't want to live without it, but I'd far rather see info go away. In some ways it anticipated HTML, but I find navigation particularly painful. > What exactly is wrong with the manpage format? It's linear. > It tells you everything you need to know, and tells you where to > find further information. Yes, but you need to follow the link manually. Theoretically a good HTML document would be better, but it's nice to have a linear form that you can search. For an extreme case of man pages, look at something like mplayer(1) or mpv(1): $ man mplayer|wc -l 9435 $ man mpv|wc -l 13939 That doesn't make them easy to read. Greg -- Sent from my desktop computer. Finger grog@lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 163 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2570 bytes --] Dennis had a model 37 on his sunporch for years. The innards were nearly all mechanical -- cams and levers, etc. And as the years went by, wear and tear made the thing shake when it was being used. From time to time, it would shake so much that a space would be added into whatever you were typing. I think Dennis finally retired it after he typed the command "rm *.o" (a common command in those days of small discs), and got the respnse ".o not found" The model37 used fan-fold paper, that we got by the box. It was an art to arrange the paper flow so that the output didn't pile up inside the box of blank paper, but rather ended up in a pile on the floor. In this era, Unix would, from time to time, crash unexpectedly, causing you to lose all the edits you hadn't written out yet. The drill in that case was to gather up the paper with all your typing on it, and, with a highlighter, highlight the stuff you needed to retype when the system came up. One day I had been furiously editing a long program file for about an hour and a half when I was called away to lunch, and, being hungry, didn't save my file. When I got back to the terminal an hour later, I discovered two things -- the system had crashed, and our cat had decided that the pile of paper on the floor made a great litter box. After a few choice words, I sighed and picked up my highliter... Steve ----- Original Message ----- From: "Doug McIlroy" <doug@cs.dartmouth.edu> To:<tuhs@tuhs.org> Cc: Sent:Sun, 15 Sep 2019 18:07:11 -0400 Subject:Re: [TUHS] earliest Unix roff > Excellent - thanks for the pointer. This shows nroff before troff. > FWIW: I guess I was miss informed, but I had been under the impression > that was the other way around. i.e. nroff was done to be compliant with > the new troff, replacing roff, although the suggestion here is that he > wrote it add macros to roff. I'll note that either way, the dates are all > possible of course because the U/L case ASR 37 was introduced 1968 so by > the early 1970's they would have been around the labs. nroff was in v2; troff appeared in v4, which incidentally was typeset in troff. Because of Joe Ossanna's role in designing the model 37, we had 37's in the Labs and even in our homes right from the start of production. But when they went obsolete, they were a chore to get rid of. As Labs property, they had to be returned; and picking them up was nobody's priority. Andy Hall had one on his back porch for a year. Doug [-- Attachment #2: Type: text/html, Size: 3423 bytes --]
On 9/16/2019 8:02 PM, Nemo Nusquam wrote:
> On 09/16/19 18:05, Dave Horsfall wrote:
>> Am I the only one who remembers the old "pg" program? It seems to have
>> disappeared.
>
> Still ships with Solaris (in /usr/bin).
Now you've gone and said a bad word... ;)
art k.
Greg 'groggy' Lehey writes:
>
> Yes, but you need to follow the link manually. Theoretically a good
> HTML document would be better, but it's nice to have a linear form
> that you can search.
Isn't "good HTML document" an oxymoron?
[-- Attachment #1: Type: text/plain, Size: 987 bytes --] The USG pg program was created after UCB released more. Btw this was before vi or csh was distributed. But too many BTL folks had seen BSD during there OYOC year and either demanded it or had brought what was in effect 2BSD back with them. On Mon, Sep 16, 2019 at 6:06 PM Dave Horsfall <dave@horsfall.org> wrote: > On Mon, 16 Sep 2019, Clem Cole wrote: > > > > However, please note that more(1) also was inspired by, almost > > > copied from, ITS. Certainly the prompt --More-- is. > > > > Absolutely. A friend of mine/fellow UCB grad student, Eric Shienbrood, > > wrote it. He was a MIT undergrad. And Eric happily said it was modeled > > from ITS. And before, Eric wrote it, UNIX lacked anything like it. > > Which to me is fine, taking an idea from another system to add a new > > feature that is lacking. > > Am I the only one who remembers the old "pg" program? It seems to have > disappeared. > > -- Dave -- Sent from a handheld expect more typos than usual [-- Attachment #2: Type: text/html, Size: 1453 bytes --]
On 9/16/2019 8:20 PM, Steve Johnson wrote:
> One day I had been furiously editing a long program file for about an
> hour and a half when I was called away to lunch, and, being hungry,
> didn't save
> my file. When I got back to the terminal an hour later, I discovered
> two things -- the system had crashed, and our cat had decided that the
> pile of paper
> on the floor made a great litter box. After a few choice words, I
> sighed and picked up my highliter...
This should be engraved on a plaque somewhere. Only because I had almost
the same thing happen to me, without the cat though. I had a printout of a
"mail" program I had written on TOPS-10 at high school. I had to retype
the entire thing after the file got corrupted.
Yay MACRO-10
On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote:
> On 9/16/2019 8:20 PM, Steve Johnson wrote:
> >One day I had been furiously editing a long program file for about an hour
> >and a half when I was called away to lunch, and, being hungry, didn't save
> >my file.?? When I got back to the terminal an hour later, I discovered two
> >things -- the system had crashed, and our cat had decided that the pile of
> >paper
> >on the floor made a great litter box.?? After a few choice words, I sighed
> >and picked up my highliter...
>
> This should be engraved on a plaque somewhere. Only because I had almost the
> same thing happen to me, without the cat though. I had a printout of a
> "mail" program I had written on TOPS-10 at high school. I had to retype the
> entire thing after the file got corrupted.
I think we have all been there. Something always goes wrong. I wrote
a paper about how to restore a Masscomp because I did rm -rf . in /.
I believe we had roots home as / because /usr was a different partition.
Clem, did Masscomp make roots home / or was that us? Anyway, I did a
cd something
and somehow deleted the something and then did rm -rf .
Much fun was had, I was up all night putting things back together.
This was probably around 1984 or 1985, I was pretty green.
[-- Attachment #1: Type: text/plain, Size: 550 bytes --] The one time you didn't want any cat output.... > On Sep 16, 2019, at 5:20 PM, Steve Johnson <scj@yaccman.com> wrote: > > One day I had been furiously editing a long program file for about an hour and a half when I was called away to lunch, and, being hungry, didn't save > my file. When I got back to the terminal an hour later, I discovered two things -- the system had crashed, and our cat had decided that the pile of paper > on the floor made a great litter box. After a few choice words, I sighed and picked up my highliter... > [-- Attachment #2: Type: text/html, Size: 2083 bytes --]
I’ve forgotten but it could have been early on. Having /root as the super users home directory was on later systems. I thought Masscomp did that but I might be thinking Stellar by then.
Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
> On Sep 16, 2019, at 9:17 PM, Larry McVoy <lm@mcvoy.com> wrote:
>
>> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote:
>>> On 9/16/2019 8:20 PM, Steve Johnson wrote:
>>> One day I had been furiously editing a long program file for about an hour
>>> and a half when I was called away to lunch, and, being hungry, didn't save
>>> my file.?? When I got back to the terminal an hour later, I discovered two
>>> things -- the system had crashed, and our cat had decided that the pile of
>>> paper
>>> on the floor made a great litter box.?? After a few choice words, I sighed
>>> and picked up my highliter...
>>
>> This should be engraved on a plaque somewhere. Only because I had almost the
>> same thing happen to me, without the cat though. I had a printout of a
>> "mail" program I had written on TOPS-10 at high school. I had to retype the
>> entire thing after the file got corrupted.
>
> I think we have all been there. Something always goes wrong. I wrote
> a paper about how to restore a Masscomp because I did rm -rf . in /.
> I believe we had roots home as / because /usr was a different partition.
> Clem, did Masscomp make roots home / or was that us? Anyway, I did a
> cd something
> and somehow deleted the something and then did rm -rf .
> Much fun was had, I was up all night putting things back together.
> This was probably around 1984 or 1985, I was pretty green.
In retrospect having / be roots home is a super bad idea but I think it was fairly common practice, /root became a thing as idiots like me messed things up :) On Mon, Sep 16, 2019 at 09:26:34PM -0400, Clem cole wrote: > I???ve forgotten but it could have been early on. Having /root as the super users home directory was on later systems. I thought Masscomp did that but I might be thinking Stellar by then. > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > > > On Sep 16, 2019, at 9:17 PM, Larry McVoy <lm@mcvoy.com> wrote: > > > >> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote: > >>> On 9/16/2019 8:20 PM, Steve Johnson wrote: > >>> One day I had been furiously editing a long program file for about an hour > >>> and a half when I was called away to lunch, and, being hungry, didn't save > >>> my file.?? When I got back to the terminal an hour later, I discovered two > >>> things -- the system had crashed, and our cat had decided that the pile of > >>> paper > >>> on the floor made a great litter box.?? After a few choice words, I sighed > >>> and picked up my highliter... > >> > >> This should be engraved on a plaque somewhere. Only because I had almost the > >> same thing happen to me, without the cat though. I had a printout of a > >> "mail" program I had written on TOPS-10 at high school. I had to retype the > >> entire thing after the file got corrupted. > > > > I think we have all been there. Something always goes wrong. I wrote > > a paper about how to restore a Masscomp because I did rm -rf . in /. > > I believe we had roots home as / because /usr was a different partition. > > Clem, did Masscomp make roots home / or was that us? Anyway, I did a > > cd something > > and somehow deleted the something and then did rm -rf . > > Much fun was had, I was up all night putting things back together. > > This was probably around 1984 or 1985, I was pretty green. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
[-- Attachment #1: Type: text/plain, Size: 296 bytes --] We've all been there. I won a Unix "most egregious use of Unix tools" award from Usenix for this small script trap 'ls | wc' 1 2 3 15 echo Reflex test. Type control-c ls | wc rm * Because I also did "rm * .o" I still have the ugly little warthog, anatomically correct, on my desk. [-- Attachment #2: Type: text/html, Size: 473 bytes --]
On Mon, 16 Sep 2019 18:17:52 -0700 Larry McVoy <lm@mcvoy.com> wrote:
> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote:
> > On 9/16/2019 8:20 PM, Steve Johnson wrote:
> > >One day I had been furiously editing a long program file for about an hour
> > >and a half when I was called away to lunch, and, being hungry, didn't save
> > >my file.?? When I got back to the terminal an hour later, I discovered two
> > >things -- the system had crashed, and our cat had decided that the pile of
> > >paper
> > >on the floor made a great litter box.?? After a few choice words, I sighed
> > >and picked up my highliter...
> >
> > This should be engraved on a plaque somewhere. Only because I had almost th
> e
> > same thing happen to me, without the cat though. I had a printout of a
> > "mail" program I had written on TOPS-10 at high school. I had to retype the
> > entire thing after the file got corrupted.
>
> I think we have all been there. Something always goes wrong. I wrote
> a paper about how to restore a Masscomp because I did rm -rf . in /.
> I believe we had roots home as / because /usr was a different partition.
> Clem, did Masscomp make roots home / or was that us? Anyway, I did a
> cd something
> and somehow deleted the something and then did rm -rf .
> Much fun was had, I was up all night putting things back together.
> This was probably around 1984 or 1985, I was pretty green.
I may have mentioned restoring root directory using peek/poke
commands of a primitive boot loader. Right before Comdex
(fall 1981) someone accidentally wiped out the root dir. IIRC
we had just two systems that actually worked. The other person
was copying the floppy to the second system when something
went wrong. The backup didn't work. And this was a Comdex
special filesystem (with demos for the show painstakingly put
together and no time to recreate it all from scratch). I
happened to remember inode & block numbers of the first few
things so I fixed up the root dir enough for the system to
come up & run fsck. Luckily very little was lost and we were
able to repair the demos and run them at Comdex!
Larry McVoy wrote:
> My comment on the info stuff was just my understand of why it came to be.
Probably no one knows any more.
Quick history recap:
- First there was the old plain text INFO which was more like Unix' man.
- Then there was the new hypertext INFO built on EMACS.
- GNU info copied ITS' INFO.
When I ask ITS people about this old plain text INFO, they don't even
remember it.
I think it's reasonable to assume they thought the new hypertext format
with links was more intriguing technology than plain text files.
It is like clockwork.
Whenever I say something about Texinfo *as a markup language* for use
in *writing books*, the discussion inevitably degenerates into a hate
rant against Info and RMS's (failed) attempt to replace man pages.
Totally missing the point too.
This is a trend on TUHS. The same discussions, the same rants, often
the same misinformation, over and over and over again.
I start to wonder if I should continue to subscribe.
Arnold
Larry McVoy <lm@mcvoy.com> wrote:
> On Mon, Sep 16, 2019 at 08:10:48AM -0400, Clem Cole wrote:
> > On Mon, Sep 16, 2019 at 1:52 AM <arnold@skeeve.com> wrote:
> >
> > > I use the standalone Info reader (named info) if I want to look at the
> > > Info output.
> > >
> > Fair enough, but be careful, while I admit I have not looked in a while,
> > info(gnu) relies on emacs keybindings and a number of very emacs'ish things.
> > Every time I have tried to deal with it, I have unprogram my fingers and
> > reset them to emacs.
> >
> > If it would have used more(1) [or even less(1)] then I would not be as
> > annoyed.
> > Unix had fine tools [man(1), more(1), et al] and rms and friends felt the
> > need to replace them with ITS-like programs.
>
> I hate texinfo and friends. I get why it is better than man, but man was
> good enough, more than good enough, and the GNU project took everything
> it could find and destroyed the man pages.
>
> If you have something like perl that needs a zillion sub pages, info
> makes sense. For just a man page, info is horrible.
Nemo Nusquam wrote:
> On 09/16/19 18:05, Dave Horsfall wrote:
> > Am I the only one who remembers the old "pg" program? It seems
> to have disappeared.
>
> Still ships with Solaris (in /usr/bin).
the sources can be found at Jorg Schillings sourceforge site.
Larry McVoy <lm@mcvoy.com> wrote:
>
> It's what Clem said. You should acclimate yourself to your environment.
> Pushing info into man environment is a lot like being an immigrant and
> wanting to bring your laws into your new homeland. That isn't a thing
> and shouldn't be a thing. Doesn't matter that people think ITS is better,
> they are in Unix. If you think ITS is better, go live there.
> When in Rome....
>
info failed (as well as texinfo). Hardly anybody using it, beside notorious emacs maniacs like me. Rome doesn't like it.
> On Sep 16, 2019, at 5:16 PM, Greg 'groggy' Lehey <grog@lemis.com> wrote:
>
> For an extreme case of man pages, look at something like mplayer(1) or
> mpv(1):
>
> $ man mplayer|wc -l
> 9435
> $ man mpv|wc -l
> 13939
>
Those aren’t man pages, they are novellas.
David
[-- Attachment #1: Type: text/plain, Size: 2330 bytes --] Fair enough. Mei culpa from one of those that was vocal. That said, maybe a trick is to stay away from texinfo/info and the man page discussion on this list since its a hot button that causes much trama for some with a more traditional UNIX view. Please don't leave, your voice is important and I generally agree with you and always like to hear you out. But even if I do not agree, I still want to listen. You have come to your conclusions in a different manner than some of us, and where each of us puts the MSB tends to color our views. Diversity of opinion is a good thing. Respectfully, Clem ᐧ On Tue, Sep 17, 2019 at 3:53 AM <arnold@skeeve.com> wrote: > It is like clockwork. > > Whenever I say something about Texinfo *as a markup language* for use > in *writing books*, the discussion inevitably degenerates into a hate > rant against Info and RMS's (failed) attempt to replace man pages. > Totally missing the point too. > > This is a trend on TUHS. The same discussions, the same rants, often > the same misinformation, over and over and over again. > > I start to wonder if I should continue to subscribe. > > Arnold > > Larry McVoy <lm@mcvoy.com> wrote: > > > On Mon, Sep 16, 2019 at 08:10:48AM -0400, Clem Cole wrote: > > > On Mon, Sep 16, 2019 at 1:52 AM <arnold@skeeve.com> wrote: > > > > > > > I use the standalone Info reader (named info) if I want to look at > the > > > > Info output. > > > > > > > Fair enough, but be careful, while I admit I have not looked in a > while, > > > info(gnu) relies on emacs keybindings and a number of very emacs'ish > things. > > > Every time I have tried to deal with it, I have unprogram my fingers > and > > > reset them to emacs. > > > > > > If it would have used more(1) [or even less(1)] then I would not be as > > > annoyed. > > > Unix had fine tools [man(1), more(1), et al] and rms and friends felt > the > > > need to replace them with ITS-like programs. > > > > I hate texinfo and friends. I get why it is better than man, but man was > > good enough, more than good enough, and the GNU project took everything > > it could find and destroyed the man pages. > > > > If you have something like perl that needs a zillion sub pages, info > > makes sense. For just a man page, info is horrible. > [-- Attachment #2: Type: text/html, Size: 3490 bytes --]
Yes, I think the next time anyone says anything about markup languages,
I'll just use private mail.
Thanks,
Arnold
Clem Cole <clemc@ccc.com> wrote:
> Fair enough. Mei culpa from one of those that was vocal. That said, maybe
> a trick is to stay away from texinfo/info and the man page discussion on
> this list since its a hot button that causes much trama for some with a
> more traditional UNIX view.
>
> Please don't leave, your voice is important and I generally agree with you
> and always like to hear you out. But even if I do not agree, I still want
> to listen. You have come to your conclusions in a different manner than
> some of us, and where each of us puts the MSB tends to color our views.
> Diversity of opinion is a good thing.
>
> Respectfully,
> Clem
> ᐧ
>
> On Tue, Sep 17, 2019 at 3:53 AM <arnold@skeeve.com> wrote:
>
> > It is like clockwork.
> >
> > Whenever I say something about Texinfo *as a markup language* for use
> > in *writing books*, the discussion inevitably degenerates into a hate
> > rant against Info and RMS's (failed) attempt to replace man pages.
> > Totally missing the point too.
> >
> > This is a trend on TUHS. The same discussions, the same rants, often
> > the same misinformation, over and over and over again.
> >
> > I start to wonder if I should continue to subscribe.
> >
> > Arnold
> >
> > Larry McVoy <lm@mcvoy.com> wrote:
> >
> > > On Mon, Sep 16, 2019 at 08:10:48AM -0400, Clem Cole wrote:
> > > > On Mon, Sep 16, 2019 at 1:52 AM <arnold@skeeve.com> wrote:
> > > >
> > > > > I use the standalone Info reader (named info) if I want to look at
> > the
> > > > > Info output.
> > > > >
> > > > Fair enough, but be careful, while I admit I have not looked in a
> > while,
> > > > info(gnu) relies on emacs keybindings and a number of very emacs'ish
> > things.
> > > > Every time I have tried to deal with it, I have unprogram my fingers
> > and
> > > > reset them to emacs.
> > > >
> > > > If it would have used more(1) [or even less(1)] then I would not be as
> > > > annoyed.
> > > > Unix had fine tools [man(1), more(1), et al] and rms and friends felt
> > the
> > > > need to replace them with ITS-like programs.
> > >
> > > I hate texinfo and friends. I get why it is better than man, but man was
> > > good enough, more than good enough, and the GNU project took everything
> > > it could find and destroyed the man pages.
> > >
> > > If you have something like perl that needs a zillion sub pages, info
> > > makes sense. For just a man page, info is horrible.
> >
[-- Attachment #1: Type: text/plain, Size: 1962 bytes --] On Tue, Sep 17, 2019, 3:54 AM <arnold@skeeve.com> wrote: > It is like clockwork. > > Whenever I say something about Texinfo *as a markup language* for use > in *writing books*, the discussion inevitably degenerates into a hate > rant against Info and RMS's (failed) attempt to replace man pages. > Totally missing the point too. > Yeah, that is a pain in the neck. I had the other reaction to this... I have been managing my web presence via DocBook SGML for a goodly long time. It is, as mentioned upthread, pretty wordy what with all the verbose tagging. It would be worth something to be able to edit it in TeXinfo form, with the lesser amount of tagging required. (And I'd kinda like to get off of DocBook/SGML one of these days as the toolset is clearly mouldering away pretty badly.) So my reaction to your comments was to look into the usability of TeXinfo... I did a wee experiment yesterday, attempting to use docbook2x to get to something else. Alas, it seems to want to use xsltproc on the XML form, and the transformation to XML is apparently a separate pain in the neck. I thought I accomplished it, but the XSLT for generating TeXinfo throws up on it, so there must be more to the matter. I'll take a further poke at it later; thank you for offering a bit of inspiration on possible approaches to change. I know I can turn DocBook into s-expressions, and then write some transformation in CL after that; it would be nice if there were something already written. For sophisticated material, TeXinfo is of use, notwithstanding notions to make everything into brief man pages. Bashing RMS for wanting things from ITS (and probably Multics too) (as I see elsewhere in the thread) is unnecessarily unkind. A dogmatic attitude of "must be short man pages" shifts us to a different Procrustean bed that fails in a different set of cases. I for one was kinda hoping for Project Xanadu someday, to throw a different perspective on that. > [-- Attachment #2: Type: text/html, Size: 2867 bytes --]
Hi. Christopher Browne <cbbrowne@gmail.com> wrote: > I had the other reaction to this... > > I have been managing my web presence via DocBook SGML for a goodly long > time. It is, as mentioned upthread, pretty wordy what with all the verbose > tagging. > > It would be worth something to be able to edit it in TeXinfo form, with the > lesser amount of tagging required. (And I'd kinda like to get off of > DocBook/SGML one of these days as the toolset is clearly mouldering away > pretty badly.) Looks like pandoc will go from DocBook to Texinfo. Me, I'd probably write a giant awk script to do the grunt work. :-) > For sophisticated material, TeXinfo is of use, notwithstanding notions to > make everything into brief man pages. As I've been saying, I use it for books. Good luck, Arnold
[-- Attachment #1: Type: text/plain, Size: 832 bytes --] On Tue, Sep 17, 2019 at 12:16 PM <arnold@skeeve.com> wrote: > Hi. > > Christopher Browne <cbbrowne@gmail.com> wrote: > > I had the other reaction to this... > > > > I have been managing my web presence via DocBook SGML for a goodly long > > time. It is, as mentioned upthread, pretty wordy what with all the > verbose > > tagging. > > > > It would be worth something to be able to edit it in TeXinfo form, with > the > > lesser amount of tagging required. (And I'd kinda like to get off of > > DocBook/SGML one of these days as the toolset is clearly mouldering away > > pretty badly.) > > Looks like pandoc will go from DocBook to Texinfo. > > Me, I'd probably write a giant awk script to do the grunt work. :-) > FreeBSD likely is moving out DocBook stuff to markdown. Docbook is too hard to find people to work on :( Warner [-- Attachment #2: Type: text/html, Size: 1334 bytes --]
On Mon, 16 Sep 2019, Larry McVoy wrote:
> In retrospect having / be roots home is a super bad idea but I think it
> was fairly common practice, /root became a thing as idiots like me
> messed things up :)
After my similar fsckup, I made /etc root's home directory (it was much
easier to recover, and was available at boot time).
-- Dave
[-- Attachment #1: Type: text/plain, Size: 1041 bytes --] I always rather liked the IBM Bookmaster flavor of GML. I wrote some good-looking (and perhaps even useful) things in it. Adam On Tue, Sep 17, 2019 at 11:16 AM <arnold@skeeve.com> wrote: > Hi. > > Christopher Browne <cbbrowne@gmail.com> wrote: > > I had the other reaction to this... > > > > I have been managing my web presence via DocBook SGML for a goodly long > > time. It is, as mentioned upthread, pretty wordy what with all the > verbose > > tagging. > > > > It would be worth something to be able to edit it in TeXinfo form, with > the > > lesser amount of tagging required. (And I'd kinda like to get off of > > DocBook/SGML one of these days as the toolset is clearly mouldering away > > pretty badly.) > > Looks like pandoc will go from DocBook to Texinfo. > > Me, I'd probably write a giant awk script to do the grunt work. :-) > > > For sophisticated material, TeXinfo is of use, notwithstanding notions to > > make everything into brief man pages. > > As I've been saying, I use it for books. > > Good luck, > > Arnold > [-- Attachment #2: Type: text/html, Size: 1549 bytes --]
Larry McVoy: If you have something like perl that needs a zillion sub pages, info makes sense. For just a man page, info is horrible. ===== This pokes me in one of my longest-standing complaints: Manual entries, as printed by man and once upon a time in the Programmers' Manual Volume 1, should be concise references. They are not a place for tutorials or long-winded descriptions or even long lists of hundreds of options (let alone descriptions of why the developer thinks this is the neatest thing since sliced bread and what bread he had in his sandwiches that day). For many programs, one or two pages of concise reference is all the documentation that's needed; no one needs a ten-page tutorial on how to use cat or rm or ls, for example. But some programs really do deserve a longer treatment, either a tutorial or an extended reference with more detail or both. Those belong in separate documents, and are why the Programmers' Manual had a second volume. Nowadays people think nothing of writing 68-page-long manual entries (real example from something I'm working with right now) that are long, chatty lists of options or configuration-file directives with tutorial information interspersed. The result makes the developer feel good--look at all the documentation I've written!!--but it's useless for someone trying to figure out how to write a configuration file for the first time, and not so great even for someone trying to edit an existing one. Even the Research system didn't always get this right; some manual entries ran on and on and on when what was really needed was a concise list of something and a longer accompanying document. (The Tenth Edition manual was much better about that, mostly because of all the work Doug put in. I doubt there has ever been a better editor for technical text than Doug.) But it's far worse now in most systems, because there's rarely any editor at all; the manuals are just an accreted clump. And that's a shame, though I have no suggestions on how to fix it. Norman Wilson Toronto ON
[-- Attachment #1: Type: text/plain, Size: 1975 bytes --] On Thu, Sep 19, 2019 at 2:11 PM Norman Wilson <norman@oclsc.org> wrote: > Manual entries, as printed by man and once upon a time in > the Programmers' Manual Volume 1, should be concise references. > They are not a place for tutorials or long-winded descriptions > or even long lists of hundreds of options (let alone descriptions > of why the developer thinks this is the neatest thing since > sliced bread and what bread he had in his sandwiches that day). > > For many programs, one or two pages of concise reference is > all the documentation that's needed; no one needs a ten-page > tutorial on how to use cat or rm or ls, for example. But some > programs really do deserve a longer treatment, either a tutorial > or an extended reference with more detail or both. Those belong > in separate documents, and are why the Programmers' Manual had > a second volume. > > Nowadays people think nothing of writing 68-page-long manual > entries (real example from something I'm working with right now) > that are long, chatty lists of options or configuration-file > directives with tutorial information interspersed. The result > makes the developer feel good--look at all the documentation > I've written!!--but it's useless for someone trying to figure > out how to write a configuration file for the first time, and > not so great even for someone trying to edit an existing one. > > Even the Research system didn't always get this right; some > manual entries ran on and on and on when what was really > needed was a concise list of something and a longer accompanying > document. (The Tenth Edition manual was much better about > that, mostly because of all the work Doug put in. I doubt > there has ever been a better editor for technical text than > Doug.) But it's far worse now in most systems, because > there's rarely any editor at all; the manuals are just an > accreted clump. > > And that's a shame, though I have no suggestions on how > to fix it. > > +1 [-- Attachment #2: Type: text/html, Size: 2608 bytes --]
Clem Cole: Exactly!!!! That's what Eric did when he wrote more(ucb) - he *added to Unix*. The funny part was that USG thought more(ucb) was a good idea and then wrote their own, pg(att); which was just as arrogant as the info behavior from the Gnu folks!!! ====== And others wrote their own too, of course. The one I know best is p(1), written by Rob Pike in the late 1970s at the University of Toronto. I encountered at Caltech on the system Rob had set up before leaving for Bell Labs (and which I cared for and hacked on for the next four years before following him). By the time I reached BTL it was a normal part of the Research system; I believe it's in all of the Eighth, Ninth, and Tenth Edition manuals. p is interesting because it's so much lighter-weight, and because it has rather a different interior design: Rather than doing termcappy things, p just prints 22 lines (or the number specified in an option), then doesn't print the newline after the 22nd line. Hit return and it will print the next 22 lines, and so on. The resulting text just flows up the glass-tty screen without any fuss, cbreak, or anything. (I believe the first version predated V7 and therefore cbreak.) Why 22 lines instead of 24, the common height of glass ttys back then? Partly because that means you keep a line or two of context when advancing pages, making reading simpler. But also because in those days, a standard page destined for a printer (e.g. from pr or nroff, and therefore from man) was 66 lines long. 22 evenly divides 66, so man something | p never gives you a screen spanning pages. p was able to back up: type - (and return) instead of just return, and it reprints the previous 22-line page; -- (return) the 22 lines before that; and so on. This was implemented in an interesting and clever way: a wrapper around the standard I/O library which kept a circular buffer of some fixed number of characters (8KiB in early versions, I think), and a new call that, in effect, backed up the file pointer by one character and returned the character just backed over. That made it easy to back over the previous N lines: just make that call until you've seen N newlines, then discard the newline you've just backed over, and you're at the beginning the first line you want to reprint. As I vaguely recall, more was able to back up, but only when reading from a real file, not a pipeline. p could do (limited but sufficient) backup from a pipeline too. As a creature of its pre-window-system era, you could also type !command when p paused as well. I remember being quite interested in that wrapper as a possible library for use in other things, though I never found a use for it. I also remember a wonderful Elements-of-Programming-Style adventure with Rob's code. I discovered it had a bug under some specific case when read returned less than a full bufferful. I read the code carefully and couldn't see what was wrong. So I wrote my own replacement for the problematic subroutine from scratch, tested it carefully in corner cases, then with listings of Rob's code and mine side-by-side walked through each with the problem case and found the bug. I still carry my own version of p (rewritten from scratch mainly to make it more portable--Rob's code was old enough to be too clever in some details) wherever I go; ironically, even back to U of T where I have been on and off for the past 30 years. more and less and pg and the like are certainly useful programs; for various reasons they're not to my taste, but I don't scorn them. But I can't help being particular fond of p because it taught me a few things about programming too. Norman Wilson Toronto ON
Clem Cole writes:
>
> On Thu, Sep 19, 2019 at 2:11 PM Norman Wilson <norman@oclsc.org> wrote:
>
> > Manual entries, as printed by man and once upon a time in
> > the Programmers' Manual Volume 1, should be concise references.
> > They are not a place for tutorials or long-winded descriptions
> > or even long lists of hundreds of options (let alone descriptions
> > of why the developer thinks this is the neatest thing since
> > sliced bread and what bread he had in his sandwiches that day).
> >
> > For many programs, one or two pages of concise reference is
> > all the documentation that's needed; no one needs a ten-page
> > tutorial on how to use cat or rm or ls, for example. But some
> > programs really do deserve a longer treatment, either a tutorial
> > or an extended reference with more detail or both. Those belong
> > in separate documents, and are why the Programmers' Manual had
> > a second volume.
> >
> > Nowadays people think nothing of writing 68-page-long manual
> > entries (real example from something I'm working with right now)
> > that are long, chatty lists of options or configuration-file
> > directives with tutorial information interspersed. The result
> > makes the developer feel good--look at all the documentation
> > I've written!!--but it's useless for someone trying to figure
> > out how to write a configuration file for the first time, and
> > not so great even for someone trying to edit an existing one.
> >
> > Even the Research system didn't always get this right; some
> > manual entries ran on and on and on when what was really
> > needed was a concise list of something and a longer accompanying
> > document. (The Tenth Edition manual was much better about
> > that, mostly because of all the work Doug put in. I doubt
> > there has ever been a better editor for technical text than
> > Doug.) But it's far worse now in most systems, because
> > there's rarely any editor at all; the manuals are just an
> > accreted clump.
> >
> > And that's a shame, though I have no suggestions on how
> > to fix it.
> >
> > +1
This is sort of my late in life mission. Here's a description of a session
that I've proposed for an upcoming conference.
Once upon a time there was Budweiser. Then, along came craft beer
which started a movement. Now, one can find a whole range of
offerings from craft cheese to artisanal baking soda. Hard to find
is craft programming. What’s called "programming technology" today
seems to be the art of minimizing the damage that can be done by
monkeys at keyboards. Since we can no longer purchase even a
toothpick that doesn’t contain a processor and a blue LED, we depend
on code. How can we revive the art of programming? How do we foster
the creation of good code instead of spending energy minimizing the
damage that can be done by bad code? Our lives depend on it.
My two cents is that craft programmers know how to write good documentation.
Probably one of the things that made BTL so wonderful was the breadth of
knowledge that people had. Ken was recently telling me about Lee McMahon who
was a classically trained monk in addition to writing qsort for V3.
Norman Wilson wrote in <1568916649.17313.for-standards-violators@oclsc.org>: |Larry McVoy: | | If you have something like perl that needs a zillion sub pages, info | makes sense. For just a man page, info is horrible. | |===== | |This pokes me in one of my longest-standing complaints: | |Manual entries, as printed by man and once upon a time in |the Programmers' Manual Volume 1, should be concise references. |They are not a place for tutorials or long-winded descriptions |or even long lists of hundreds of options (let alone descriptions |of why the developer thinks this is the neatest thing since |sliced bread and what bread he had in his sandwiches that day). | |For many programs, one or two pages of concise reference is |all the documentation that's needed; no one needs a ten-page |tutorial on how to use cat or rm or ls, for example. But some |programs really do deserve a longer treatment, either a tutorial |or an extended reference with more detail or both. Those belong |in separate documents, and are why the Programmers' Manual had |a second volume. | |Nowadays people think nothing of writing 68-page-long manual |entries (real example from something I'm working with right now) |that are long, chatty lists of options or configuration-file |directives with tutorial information interspersed. The result |makes the developer feel good--look at all the documentation |I've written!!--but it's useless for someone trying to figure |out how to write a configuration file for the first time, and |not so great even for someone trying to edit an existing one. | |Even the Research system didn't always get this right; some I totally disagree with you. Whereas i even admire McIlroy's "concise", and really love reading Plan9 manual pages, and that not only because one can imagine _who_ put their fingers on those, i think manual pages should enable people to work with a program. And not only intellectual elite, the absolute top of the pops gathered together in this cave and grooving with a pict, but "everybody" to the extend possible. If i would have a lot of money in spare i could hire teams of three people each which rotate through the develop / test / documentation cycle, and around each others work. But that is not how it goes here, you add a feature and write down the docs, you extend one and patch in doc where you think it belongs, yet get infos from someone and patch in doc to clarify something. You do all that short on time, and finally you have a rag rug. So what you would need then is time to step back, let time pass, come back with fresh eyes, reread the entire documentation once, reflect, and work it all over. Add the complications of not being a native speaker. For some projects, add many translations done by volunteers, which you leave behind if you adhere to this work cycle. (But do not if you just patch up.) You could of course split the manual into several subsections, but which one to split, which not. Duplicate several, for example command line options, which can initiate complicate tasks, which need a lengthy text to become understandable? Who is going to do all that work? Who is the one who will spend the time and strength necessary to keep all the individual parts in sync? For example, this week (at least the latter commit) on FreeBSD the ZFS filesystem, thus a crucial part of the infrastructure of FreeBSD (no Hammer or BTRFS support), the i guess second largest free software environment, with quite some people getting paid for working on the code base, was extended (i do not use ZFS), but even the help string of the managing tool was not updated until a follow up commit several days later fixed that! So for me this is not feasible. I have the manual, and i have the help string output for -h / --help, and a longer (long option) one with --long-help. If you want a quick shot, use -h. If you need documentation, use the manual. #?0|kent:mk$ man -l ../nail.1|wc -l troff: <standard input>:14382: name expected (got '\c'): treated as missing 8172 Without TOC and anchors. bug in groff mdoc macros in 1.22.3, by the way (.Lk i guessed). #?0|kent:mk$ mdoc ../nail.1|wc -l 8307 With TOC and hundreds of internal and external anchors. #?0|kent:mk$ /tmp/y/s-nail -h|wc -l 24 #?0|kent:mk$ /tmp/y/s-nail --long-help|wc -l 57 |manual entries ran on and on and on when what was really |needed was a concise list of something and a longer accompanying |document. (The Tenth Edition manual was much better about |that, mostly because of all the work Doug put in. I doubt |there has ever been a better editor for technical text than |Doug.) But it's far worse now in most systems, because |there's rarely any editor at all; the manuals are just an |accreted clump. | |And that's a shame, though I have no suggestions on how |to fix it. I do not know either. The car industry has the many pictures but no content (for people who spend money), a repair manual for underpaid mechanics, and detailed spare part foils for those people working in the dusty spare parts depot. That at least thirty years ago when i snuffled into that industry. |Norman Wilson |Toronto ON --End of <1568916649.17313.for-standards-violators@oclsc.org> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
[-- Attachment #1: Type: text/plain, Size: 6093 bytes --] In the early 70's, Marc Rochkind recommended re-reading the entire UNIX manual yearly. Back then, it was doable. Now it is probably growing faster than I can read. There is a place for a *concise* description of each command, and a separate place for tutorials and conference papers. On Thu, Sep 19, 2019 at 3:44 PM Steffen Nurpmeso <steffen@sdaoden.eu> wrote: > Norman Wilson wrote in <1568916649.17313.for-standards-violators@oclsc.org > >: > |Larry McVoy: > | > | If you have something like perl that needs a zillion sub pages, info > | makes sense. For just a man page, info is horrible. > | > |===== > | > |This pokes me in one of my longest-standing complaints: > | > |Manual entries, as printed by man and once upon a time in > |the Programmers' Manual Volume 1, should be concise references. > |They are not a place for tutorials or long-winded descriptions > |or even long lists of hundreds of options (let alone descriptions > |of why the developer thinks this is the neatest thing since > |sliced bread and what bread he had in his sandwiches that day). > | > |For many programs, one or two pages of concise reference is > |all the documentation that's needed; no one needs a ten-page > |tutorial on how to use cat or rm or ls, for example. But some > |programs really do deserve a longer treatment, either a tutorial > |or an extended reference with more detail or both. Those belong > |in separate documents, and are why the Programmers' Manual had > |a second volume. > | > |Nowadays people think nothing of writing 68-page-long manual > |entries (real example from something I'm working with right now) > |that are long, chatty lists of options or configuration-file > |directives with tutorial information interspersed. The result > |makes the developer feel good--look at all the documentation > |I've written!!--but it's useless for someone trying to figure > |out how to write a configuration file for the first time, and > |not so great even for someone trying to edit an existing one. > | > |Even the Research system didn't always get this right; some > > I totally disagree with you. Whereas i even admire McIlroy's > "concise", and really love reading Plan9 manual pages, and that > not only because one can imagine _who_ put their fingers on those, > i think manual pages should enable people to work with a program. > And not only intellectual elite, the absolute top of the pops > gathered together in this cave and grooving with a pict, but > "everybody" to the extend possible. > > If i would have a lot of money in spare i could hire teams of > three people each which rotate through the develop / test > / documentation cycle, and around each others work. But that is > not how it goes here, you add a feature and write down the docs, > you extend one and patch in doc where you think it belongs, yet > get infos from someone and patch in doc to clarify something. You > do all that short on time, and finally you have a rag rug. > > So what you would need then is time to step back, let time pass, > come back with fresh eyes, reread the entire documentation once, > reflect, and work it all over. > > Add the complications of not being a native speaker. > For some projects, add many translations done by volunteers, which > you leave behind if you adhere to this work cycle. (But do not if > you just patch up.) > > You could of course split the manual into several subsections, but > which one to split, which not. Duplicate several, for example > command line options, which can initiate complicate tasks, which > need a lengthy text to become understandable? > > Who is going to do all that work? Who is the one who will spend > the time and strength necessary to keep all the individual parts > in sync? For example, this week (at least the latter commit) on > FreeBSD the ZFS filesystem, thus a crucial part of the > infrastructure of FreeBSD (no Hammer or BTRFS support), the > i guess second largest free software environment, with quite some > people getting paid for working on the code base, was extended (i > do not use ZFS), but even the help string of the managing tool was > not updated until a follow up commit several days later fixed > that! > > So for me this is not feasible. I have the manual, and i have the > help string output for -h / --help, and a longer (long option) one > with --long-help. If you want a quick shot, use -h. If you need > documentation, use the manual. > > #?0|kent:mk$ man -l ../nail.1|wc -l > troff: <standard input>:14382: name expected (got '\c'): treated as > missing > 8172 > > Without TOC and anchors. > bug in groff mdoc macros in 1.22.3, by the way (.Lk i guessed). > > #?0|kent:mk$ mdoc ../nail.1|wc -l > 8307 > > With TOC and hundreds of internal and external anchors. > > #?0|kent:mk$ /tmp/y/s-nail -h|wc -l > 24 > #?0|kent:mk$ /tmp/y/s-nail --long-help|wc -l > 57 > > |manual entries ran on and on and on when what was really > |needed was a concise list of something and a longer accompanying > |document. (The Tenth Edition manual was much better about > |that, mostly because of all the work Doug put in. I doubt > |there has ever been a better editor for technical text than > |Doug.) But it's far worse now in most systems, because > |there's rarely any editor at all; the manuals are just an > |accreted clump. > | > |And that's a shame, though I have no suggestions on how > |to fix it. > > I do not know either. The car industry has the many pictures but > no content (for people who spend money), a repair manual for > underpaid mechanics, and detailed spare part foils for those > people working in the dusty spare parts depot. That at least > thirty years ago when i snuffled into that industry. > > |Norman Wilson > |Toronto ON > --End of <1568916649.17313.for-standards-violators@oclsc.org> > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > [-- Attachment #2: Type: text/html, Size: 7304 bytes --]
[-- Attachment #1: Type: text/plain, Size: 569 bytes --] On Thursday, September 19, 2019, Larry McVoy <lm@mcvoy.com> wrote: > On Thu, Sep 19, 2019 at 03:00:16PM -0400, Nemo Nusquam wrote: > > On 09/19/19 14:50, Norman Wilson wrote (in part): > > >So it's true that BSD added needless (in my humble but correct > > >opinion) options, but not that it had none before they touched it. > > >Unless all those other programs were stuffed into cat in an earlier > > >Berkeley system, but I don't think they were. > > > > Who said "Cat came back from Berkeley waving flags."? > > Rob Pike > http://harmful.cat-v.org/cat-v/ --Andy [-- Attachment #2: Type: text/html, Size: 912 bytes --]
On Sep 19, 2019, at 11:10 AM, Norman Wilson <norman@oclsc.org> wrote:
>
> This pokes me in one of my longest-standing complaints:
>
> Manual entries, as printed by man and once upon a time in
> the Programmers' Manual Volume 1, should be concise references.
> They are not a place for tutorials or long-winded descriptions
> or even long lists of hundreds of options (let alone descriptions
> of why the developer thinks this is the neatest thing since
> sliced bread and what bread he had in his sandwiches that day).
>
> For many programs, one or two pages of concise reference is
> all the documentation that's needed; no one needs a ten-page
> tutorial on how to use cat or rm or ls, for example. But some
> programs really do deserve a longer treatment, either a tutorial
> or an extended reference with more detail or both. Those belong
> in separate documents, and are why the Programmers' Manual had
> a second volume.
>
> Nowadays people think nothing of writing 68-page-long manual
> entries (real example from something I'm working with right now)
> that are long, chatty lists of options or configuration-file
> directives with tutorial information interspersed. The result
> makes the developer feel good--look at all the documentation
> I've written!!--but it's useless for someone trying to figure
> out how to write a configuration file for the first time, and
> not so great even for someone trying to edit an existing one.
>
> Even the Research system didn't always get this right; some
> manual entries ran on and on and on when what was really
> needed was a concise list of something and a longer accompanying
> document. (The Tenth Edition manual was much better about
> that, mostly because of all the work Doug put in. I doubt
> there has ever been a better editor for technical text than
> Doug.) But it's far worse now in most systems, because
> there's rarely any editor at all; the manuals are just an
> accreted clump.
>
> And that's a shame, though I have no suggestions on how
> to fix it.
Agree 100%. But I think what we are really complaining about
is more recent program design & interface. Why do programs
have so many options. Why is their functionality partitioned
better.
[-- Attachment #1: Type: text/plain, Size: 4721 bytes --] Here is the complete Plan 9 man page for p: % 9 man p P(1) P(1) NAME p - paginate SYNOPSIS p [ -number ] [ file ... ] DESCRIPTION P copies its standard input, or the named files if given, to its standard output, stopping at the end of every 22nd line, and between files, to wait for a newline from the user. The option sets the number of lines on a page. While waiting for a newline, p interprets the commands: ! Pass the rest of the line to the shell as a command. q Quit. SOURCE /usr/local/plan9/src/cmd/p.c Page 1 Plan 9 (printed 9/20/19) On Fri, Sep 20, 2019 at 4:43 AM Norman Wilson <norman@oclsc.org> wrote: > Clem Cole: > > Exactly!!!! That's what Eric did when he wrote more(ucb) - he *added > to > Unix*. The funny part was that USG thought more(ucb) was a good idea > and > then wrote their own, pg(att); which was just as arrogant as the info > behavior from the Gnu folks!!! > > ====== > > And others wrote their own too, of course. The one I know > best is p(1), written by Rob Pike in the late 1970s at the > University of Toronto. I encountered at Caltech on the > system Rob had set up before leaving for Bell Labs (and > which I cared for and hacked on for the next four years > before following him). By the time I reached BTL it was > a normal part of the Research system; I believe it's in > all of the Eighth, Ninth, and Tenth Edition manuals. > > p is interesting because it's so much lighter-weight, and > because it has rather a different interior design: > > Rather than doing termcappy things, p just prints 22 lines > (or the number specified in an option), then doesn't print > the newline after the 22nd line. Hit return and it will > print the next 22 lines, and so on. The resulting text just > flows up the glass-tty screen without any fuss, cbreak, or > anything. (I believe the first version predated V7 and > therefore cbreak.) > > Why 22 lines instead of 24, the common height of glass ttys > back then? Partly because that means you keep a line or two > of context when advancing pages, making reading simpler. > But also because in those days, a standard page destined for > a printer (e.g. from pr or nroff, and therefore from man) was > 66 lines long. 22 evenly divides 66, so man something | p > never gives you a screen spanning pages. > > p was able to back up: type - (and return) instead of just > return, and it reprints the previous 22-line page; -- (return) > the 22 lines before that; and so on. This was implemented > in an interesting and clever way: a wrapper around the standard > I/O library which kept a circular buffer of some fixed number > of characters (8KiB in early versions, I think), and a new > call that, in effect, backed up the file pointer by one character > and returned the character just backed over. That made it easy > to back over the previous N lines: just make that call until > you've seen N newlines, then discard the newline you've just > backed over, and you're at the beginning the first line you want > to reprint. > > As I vaguely recall, more was able to back up, but only when > reading from a real file, not a pipeline. p could do (limited > but sufficient) backup from a pipeline too. > > As a creature of its pre-window-system era, you could also type > !command when p paused as well. > > I remember being quite interested in that wrapper as a > possible library for use in other things, though I never > found a use for it. > > I also remember a wonderful Elements-of-Programming-Style > adventure with Rob's code. I discovered it had a bug under some > specific case when read returned less than a full bufferful. > I read the code carefully and couldn't see what was wrong. > So I wrote my own replacement for the problematic subroutine > from scratch, tested it carefully in corner cases, then with > listings of Rob's code and mine side-by-side walked through > each with the problem case and found the bug. > > I still carry my own version of p (rewritten from scratch mainly > to make it more portable--Rob's code was old enough to be too > clever in some details) wherever I go; ironically, even back to > U of T where I have been on and off for the past 30 years. > more and less and pg and the like are certainly useful programs; > for various reasons they're not to my taste, but I don't scorn > them. But I can't help being particular fond of p because it > taught me a few things about programming too. > > Norman Wilson > Toronto ON > [-- Attachment #2: Type: text/html, Size: 14866 bytes --]
Re: more/less/p At Fortune Systems Dave Yost added page mode to the tty driver when his serial io optimizations made scrolling at 9600 blazing fast. He also added an ioctl for page size. By setting it to something smaller than the tty number of rows you can see some context as well. This worked pretty well.
[-- Attachment #1: Type: text/plain, Size: 5605 bytes --] John P. Linderman wrote in <CAC0cEp-CVPb-OhcDHKfbj5nMoiYjkAOEZnEOf4Sv5Zr\ zTnDKTg@mail.gmail.com>: |In the early 70's, Marc Rochkind recommended re-reading the entire \ |UNIX manual yearly. Back then, it was doable. Now it is probably growing \ |faster than I can read. It is however astonishing by how much even the POSIX standard changes, as a lowest common denominator. The IETF produces an overwhelming amount of drafts and RFCs, which need to or should be adhered to, affecting functionality and documentation. So much more time would be needed, for so many things. |There is a place for a concise description of each command, and a separate \ |place for tutorials and conference papers. Unfortunately not except in FreeBSD and NetBSD, which carry some in /usr/share/doc, like the BSD mail manual. You need to find it here, and i wonder how many of those who have grown up in the Linux world would find them at all. (Or even do a search.) They are not really updated in addition. Though FreeBSD added a clang entry, the time when developers invented ideas and implementations, and documented those under /usr/share/doc are over even there. This is really sad. Infrequently and getting rarer i reread those, for example "Rethinking /dev and devices in the UNIX kernel" about the introduction of devfs, which i still find great. It is great to hear you who is responsible that the "load of options reached 17 in v9", whereas i maintain a fork of the program which causes "old UNIX hands [to] groan at the monstrous headers that come from latter-day mailers and at the fatness of their manuals" (citing A Research UNIX Reader). To offer a solution i could add another layer in between -h output and full reference manual, and create a heavily minimized version of the manual, renaming that one to -reference.1 maybe, and prominently mention the reference. Also, easy it is to concisely document that -n chooses a numeric sort, and -r reverses the result order, but -b addr, --bcc=.. Send a blind carbon copy to recipient addr. can result in dead-end or otherwise misunderstood situations unless you really know that particular manual is stripped down, and the reference manual makes this -b addr, --bcc=.. Send a blind carbon copy to recipient addr, if the set[268]ting of expandaddr[408], one of the INTERNAL VARIABLES[29], allows; the ‘shquote’ expandaddr[408] flag is supported. The option may be used multiple times. Also see the section On sending mail, and non-interactive mode[7]. (Here, expandaddr has not been invented by me.) But if you have the reference a bit present in your head, then #?0|kent:nail$ .obj/s-nail -h|grep -- -b [:-a attachment:] [:-b bcc-addr:] [:-c cc-addr:] . -b, -c, -r, -T, to-addr: ex@am.ple or '(Lovely) Ex <am@p.le>' should also be sufficient. Blasting the concise complexity of a mathematical formula, -a file[=input-charset[#output-charset]], --attach=.. Attach file to the message (for compose mode opportunities refer to ~@[317] and ~^[319]). needs to backed as -a file[=input-charset[#output-charset]], --attach=.. Attach file to the message (for compose mode opportunities refer to ~@[317] and ~^[319]). Filename transformations[26] (also see file[193]) will be performed, except that shell variables are not expanded. Shall file not be accessible but contain a ‘=’ charac‐ ter, then anything before the last ‘=’ will be used as the file‐ name, anything thereafter as a character set specification. If an input character set is specified, but no output character set, then the given input character set is fixed as-is, and no conversion will be applied; giving the empty string or the special string hyphen-minus ‘-’ will be treated as if ttycharset[590] has been specified (the default). If an output character set has also been given then the conversion will be performed exactly as specified and on-the-fly, not consid‐ ering the file type and content. As an exception the empty string or hyphen-minus ‘-’, select the default conversion algorithm (see Character sets[14]): no conversion is performed on-the-fly, file and its contents will be MIME-classified (HTML mail and MIME attachments[9], The mime.types files[35]); Only this mode is sup‐ ported without support for character set conversions (features[411] does not mention ‘+iconv’). for people to get at least enough of the picture to use the option. (Note the actual algorithm is documented somewhere else.) #?0|kent:nail$ .obj/s-nail -h|grep -- '-a ' [:-a attachment:] [:-b bcc-addr:] [:-c cc-addr:] . -a attachment[=input-charset[#output-charset]] But normally, all you say is "-a file" and the thing is fine by default without just doing anything at all. That is how it should be. Dear John P. Linderman, be warned that the above output of -b is new, it was "-[bcrT]:" before, for which to understand regular expressions or file patterns are implied. I have given you credit for the change. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) [-- Attachment #2: Original message content --] [-- Type: message/rfc822, Size: 16687 bytes --] [-- Attachment #2.1.1: Type: text/plain, Size: 6093 bytes --] In the early 70's, Marc Rochkind recommended re-reading the entire UNIX manual yearly. Back then, it was doable. Now it is probably growing faster than I can read. There is a place for a *concise* description of each command, and a separate place for tutorials and conference papers. On Thu, Sep 19, 2019 at 3:44 PM Steffen Nurpmeso <steffen@sdaoden.eu> wrote: > Norman Wilson wrote in <1568916649.17313.for-standards-violators@oclsc.org > >: > |Larry McVoy: > | > | If you have something like perl that needs a zillion sub pages, info > | makes sense. For just a man page, info is horrible. > | > |===== > | > |This pokes me in one of my longest-standing complaints: > | > |Manual entries, as printed by man and once upon a time in > |the Programmers' Manual Volume 1, should be concise references. > |They are not a place for tutorials or long-winded descriptions > |or even long lists of hundreds of options (let alone descriptions > |of why the developer thinks this is the neatest thing since > |sliced bread and what bread he had in his sandwiches that day). > | > |For many programs, one or two pages of concise reference is > |all the documentation that's needed; no one needs a ten-page > |tutorial on how to use cat or rm or ls, for example. But some > |programs really do deserve a longer treatment, either a tutorial > |or an extended reference with more detail or both. Those belong > |in separate documents, and are why the Programmers' Manual had > |a second volume. > | > |Nowadays people think nothing of writing 68-page-long manual > |entries (real example from something I'm working with right now) > |that are long, chatty lists of options or configuration-file > |directives with tutorial information interspersed. The result > |makes the developer feel good--look at all the documentation > |I've written!!--but it's useless for someone trying to figure > |out how to write a configuration file for the first time, and > |not so great even for someone trying to edit an existing one. > | > |Even the Research system didn't always get this right; some > > I totally disagree with you. Whereas i even admire McIlroy's > "concise", and really love reading Plan9 manual pages, and that > not only because one can imagine _who_ put their fingers on those, > i think manual pages should enable people to work with a program. > And not only intellectual elite, the absolute top of the pops > gathered together in this cave and grooving with a pict, but > "everybody" to the extend possible. > > If i would have a lot of money in spare i could hire teams of > three people each which rotate through the develop / test > / documentation cycle, and around each others work. But that is > not how it goes here, you add a feature and write down the docs, > you extend one and patch in doc where you think it belongs, yet > get infos from someone and patch in doc to clarify something. You > do all that short on time, and finally you have a rag rug. > > So what you would need then is time to step back, let time pass, > come back with fresh eyes, reread the entire documentation once, > reflect, and work it all over. > > Add the complications of not being a native speaker. > For some projects, add many translations done by volunteers, which > you leave behind if you adhere to this work cycle. (But do not if > you just patch up.) > > You could of course split the manual into several subsections, but > which one to split, which not. Duplicate several, for example > command line options, which can initiate complicate tasks, which > need a lengthy text to become understandable? > > Who is going to do all that work? Who is the one who will spend > the time and strength necessary to keep all the individual parts > in sync? For example, this week (at least the latter commit) on > FreeBSD the ZFS filesystem, thus a crucial part of the > infrastructure of FreeBSD (no Hammer or BTRFS support), the > i guess second largest free software environment, with quite some > people getting paid for working on the code base, was extended (i > do not use ZFS), but even the help string of the managing tool was > not updated until a follow up commit several days later fixed > that! > > So for me this is not feasible. I have the manual, and i have the > help string output for -h / --help, and a longer (long option) one > with --long-help. If you want a quick shot, use -h. If you need > documentation, use the manual. > > #?0|kent:mk$ man -l ../nail.1|wc -l > troff: <standard input>:14382: name expected (got '\c'): treated as > missing > 8172 > > Without TOC and anchors. > bug in groff mdoc macros in 1.22.3, by the way (.Lk i guessed). > > #?0|kent:mk$ mdoc ../nail.1|wc -l > 8307 > > With TOC and hundreds of internal and external anchors. > > #?0|kent:mk$ /tmp/y/s-nail -h|wc -l > 24 > #?0|kent:mk$ /tmp/y/s-nail --long-help|wc -l > 57 > > |manual entries ran on and on and on when what was really > |needed was a concise list of something and a longer accompanying > |document. (The Tenth Edition manual was much better about > |that, mostly because of all the work Doug put in. I doubt > |there has ever been a better editor for technical text than > |Doug.) But it's far worse now in most systems, because > |there's rarely any editor at all; the manuals are just an > |accreted clump. > | > |And that's a shame, though I have no suggestions on how > |to fix it. > > I do not know either. The car industry has the many pictures but > no content (for people who spend money), a repair manual for > underpaid mechanics, and detailed spare part foils for those > people working in the dusty spare parts depot. That at least > thirty years ago when i snuffled into that industry. > > |Norman Wilson > |Toronto ON > --End of <1568916649.17313.for-standards-violators@oclsc.org> > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > [-- Attachment #2.1.2: Type: text/html, Size: 7304 bytes --]
Steffen Nurpmeso wrote in <20190920134137.DXBTo%steffen@sdaoden.eu>: |John P. Linderman wrote in <CAC0cEp-CVPb-OhcDHKfbj5nMoiYjkAOEZnEOf4Sv5Zr\ |zTnDKTg@mail.gmail.com>: ... ||There is a place for a concise description of each command, and a \ ||separate \ ||place for tutorials and conference papers. ... |Also, easy it is to concisely document that -n chooses a numeric |sort, and -r reverses the result order, but | | -b addr, --bcc=.. | Send a blind carbon copy to recipient addr. | |can result in dead-end or otherwise misunderstood situations |unless you really know that particular manual is stripped down, |and the reference manual makes this ... And i want to clarify that we talk about a program which does not behave the way a user would normally expect, where normally is that the mail is sent to all recipients. In an academic or a lab environment you can ask someone, or go over and say "Hi Ken" or "Hi Kurt", "your program misbehaves". But in the wild people will simply start to mistrust a program, or stop using it right away. In 99 percent you will not even get a bug report or hear just about anything. (Except maybe for the most popular and widely used programs.) And then all the work, the blood sweat and tears have been for nothing. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
(pardon the reply on an oldish thread, I've not read this group in a while) On Mon, 16 Sep 2019, Clem Cole wrote: > On Mon, Sep 16, 2019 at 1:52 AM <arnold@skeeve.com> wrote: > >> I use the standalone Info reader (named info) if I want to look at the >> Info output. >> > Fair enough, but be careful, while I admit I have not looked in a while, > info(gnu) relies on emacs keybindings and a number of very emacs'ish things. > Every time I have tried to deal with it, I have unprogram my fingers and > reset them to emacs. > > If it would have used more(1) [or even less(1)] then I would not be as > annoyed. > Unix had fine tools [man(1), more(1), et al] and rms and friends felt the > need to replace them with ITS-like programs. A few years ago, I was introduced to pinfo[0] for reading info pages, it's more like using the lynx browser to read info docs rather than the emacs keybindings. -- Michael Parson Pflugerville, TX KF5LGQ [0] http://pinfo.sourceforge.net