From Newsgroup: comp.unix.shell

Found this <https://bash-hackers.gabe565.com/> useful-looking site in my search for info on a topic mentioned in another post. WasnrCOt useful for that, but could be helpful for other things.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <10893ra$1dihv$2@dont-email.me>,
Lawrence DOliveiro <ldo@nz.invalid> wrote:

Found this <https://bash-hackers.gabe565.com/> useful-looking site in my >search for info on a topic mentioned in another post. Wasn't useful for >that, but could be helpful for other things.

Looks interesting. Thanks.
--
Many (most?) Trump voters voted for him because they thought if they
supported Trump enough, they'd get to *be* Trump.

Similarly, Trump believes that if *he* praises Putin enough, he'll get to *be* Putin.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 22.08.2025 08:48, Lawrence DrCOOliveiro wrote:

Found this <https://bash-hackers.gabe565.com/> useful-looking site in my search for info on a topic mentioned in another post. WasnrCOt useful for that, but could be helpful for other things.

I like its intro:

"The main motivation was to provide human-readable documentation [...]"

:-)

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <108a8i6$1mc70$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 22.08.2025 08:48, Lawrence DOliveiro wrote:

Found this <https://bash-hackers.gabe565.com/> useful-looking site in my
search for info on a topic mentioned in another post. Wasnt useful for
that, but could be helpful for other things.

I like its intro:

"The main motivation was to provide human-readable documentation [...]"

Indeed. Your post reminded me of something else: There is a schism in the
GNU world as to whether the man page or the info documentation is the final word (i.e., the most authoritative).

Bash maintains that the man page is the final word - the info may or may
not be kept up to date. GAWK says the opposite, which I find annoying,
because I've found the man page less and less complete (*) as time goes by - and I don't like info (try to avoid it as much as possible).

(*) For example, the man page no longer documents the possible values of PROCINFO["sorted_in"]. In fact, it doesn't even really document PROCINFO
at all.
--
On the subject of racism being depicted in the media, the far right and the far left have
met up in agreement (sort of like how plus infinity meets up with minus infinity).
The far left doesn't want it, because they are afraid it will make people racist.
The far right doesn't want it, because they are afraid it will make people feel bad about being racist.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 22.08.2025 21:16, Kenny McCormack wrote:

Indeed. Your post reminded me of something else: There is a schism in the GNU world as to whether the man page or the info documentation is the final word (i.e., the most authoritative).

Bash maintains that the man page is the final word - the info may or may
not be kept up to date. GAWK says the opposite, which I find annoying, because I've found the man page less and less complete (*) as time goes by - and I don't like info (try to avoid it as much as possible).

I absolutely share that feeling. - I'm not sure what the right way
would be. I fear it's something else than 'man' or 'info'. Given
that the amount and type of information varies between the various
tools there's maybe a _separation of contents_ necessary; 'man' for
the "essentials" and another document type for details, tutorials,
whatever. (The latter may also be *roff based.[*])

Janis

[*] Or something else; just not 'info', or anything alike, please!

(BTW; hasn't anyone yet created an info2man converter? - There's
nothing more annoying here than to read in a "man page" that this
would be only a stub and that you should refer to an 'info' page.)

[...]

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-08-22, Kenny McCormack <gazelle@shell.xmission.com> wrote:

In article <108a8i6$1mc70$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 22.08.2025 08:48, Lawrence DOliveiro wrote:

Found this <https://bash-hackers.gabe565.com/> useful-looking site in my >>> search for info on a topic mentioned in another post. Wasnt useful for
that, but could be helpful for other things.

I like its intro:

"The main motivation was to provide human-readable documentation [...]"

Indeed. Your post reminded me of something else: There is a schism in the GNU world as to whether the man page or the info documentation is the final word (i.e., the most authoritative).

The final word for today is whatever the packaged and installed (by your distro) program is doing; everything else is just talk.

While the talk continues and the programs change, so there isn't
necessarily a final final word in anything.

If the man and info docs contradict each other, then if one of them
agrees with what the code is doing, then weight is likely given to
that. Not so absolutely as to always reaffirm a requirement that is
obviously bogus.

There is also consideration for what other implementations do, and of
course our POSIX.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]

I absolutely share that feeling. - I'm not sure what the right way
would be. I fear it's something else than 'man' or 'info'. Given
that the amount and type of information varies between the various
tools there's maybe a _separation of contents_ necessary; 'man' for
the "essentials" and another document type for details, tutorials,
whatever. (The latter may also be *roff based.[*])

Janis

[*] Or something else; just not 'info', or anything alike, please!

(BTW; hasn't anyone yet created an info2man converter? - There's
nothing more annoying here than to read in a "man page" that this
would be only a stub and that you should refer to an 'info' page.)

For most GNU tools, the info document is definitive and the man page is secondary (and sometimes is only a brief summary). bash is the only
exception that I know of.

The bash info document does say that the man page is the definitive
reference, but I don't think that's accurate. The statement goes
back at least to 1996, and appeared in a file called "features.info".
I've found the bash info manual to be comprehensive (I rarely use
the man page). I've submitted a bug report suggesting that that
statement should probably be changed or removed.

https://lists.gnu.org/archive/html/bug-bash/2025-08/msg00113.html

Incidentally, there's also an HTML version of the bash
documentation, apparently generated from the same bashref.texi
used to generate the info manual. On my Ubuntu system, it's /usr/share/doc/bash-doc/bashref.html . I don't think most GNU tools
provide HTML documentation; for example, coreutils doesn't. I imagine
it could be generated, though.

I personally like info documentation and usually prefer it to
man pages. I understand that a lot of people don't, and that the
current situation must be frustrating for them.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 22.08.2025 23:46, Keith Thompson wrote:

[...]

For most GNU tools, the info document is definitive and the man page is secondary (and sometimes is only a brief summary). bash is the only exception that I know of.

Really? - On my Linux system I get for most system commands thorough
man page information. (And I feel lucky about that situation.)

Janis

[...]

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 23.08.2025 00:06, Janis Papanagnou wrote:

On 22.08.2025 23:46, Keith Thompson wrote:

[...]

For most GNU tools, the info document is definitive and the man page is
secondary (and sometimes is only a brief summary). bash is the only
exception that I know of.

Really? - On my Linux system I get for most system commands thorough
man page information. (And I feel lucky about that situation.)

I have to correct that; on the bottom of some man pages I see a note
"The full documentation for <tool> is maintained as a Texinfo manual."

Janis

[...]

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 23.08.2025 00:13, Janis Papanagnou wrote:

On 23.08.2025 00:06, Janis Papanagnou wrote:

On 22.08.2025 23:46, Keith Thompson wrote:

[...]

For most GNU tools, the info document is definitive and the man page is
secondary (and sometimes is only a brief summary). bash is the only
exception that I know of.

Really? - On my Linux system I get for most system commands thorough
man page information. (And I feel lucky about that situation.)

I have to correct that; on the bottom of some man pages I see a note
"The full documentation for <tool> is maintained as a Texinfo manual."

Curiously I grep'ed for that phrase in the man pages and got these
results...

$ ksh man-stat /bin
164 13
$ ksh man-stat /usr/bin
3230 60

On left: all the bin-files, right: files with texinfo note in their
man page; i.e. 8% and 2% respectively of files containing texinfo
reference in the man pages of all the commands in /bin and /usr/bin.

(Of course I cannot tell whether there's also uncommented files.)

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 23.08.2025 00:06, Janis Papanagnou wrote:

On 22.08.2025 23:46, Keith Thompson wrote:

[...]

For most GNU tools, the info document is definitive and the man page is
secondary (and sometimes is only a brief summary). bash is the only
exception that I know of.

Really? - On my Linux system I get for most system commands thorough
man page information. (And I feel lucky about that situation.)

I have to correct that; on the bottom of some man pages I see a note
"The full documentation for <tool> is maintained as a Texinfo manual."

Yes. I think that for some GNU tools, the info and man documents
contain the same information. For others, the man page is just a brief summary, sometimes generated from "--help" output with "help2man".

The GNU coding standards cover this :

https://www.gnu.org/prep/standards/standards.html#GNU-Manuals
| The preferred document format for the GNU system is the Texinfo
| formatting language.

https://www.gnu.org/prep/standards/standards.html#Man-Pages
| In the GNU project, man pages are secondary. It is not necessary or
| expected for every GNU program to have a man page, but some of them
| do. ItrCOs your choice whether to include a man page in your program.

Maintaining comprehensive info and man documents is a substantial
burden, since they're not generated from the same sources. A tool
that generates decent man pages from Texinfo input would probably
make a lot of people happy.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 23.08.2025 00:13, Janis Papanagnou wrote:

[...]

I have to correct that; on the bottom of some man pages I see a note
"The full documentation for <tool> is maintained as a Texinfo manual."

Curiously I grep'ed for that phrase in the man pages and got these
results...

$ ksh man-stat /bin
164 13
$ ksh man-stat /usr/bin
3230 60

On left: all the bin-files, right: files with texinfo note in their
man page; i.e. 8% and 2% respectively of files containing texinfo
reference in the man pages of all the commands in /bin and /usr/bin.

(Of course I cannot tell whether there's also uncommented files.)

That line "The full documentation for <tool> is maintained as a Texinfo manual." is part of the boilerplate generated by the help2man command.
Look for

".\" DO NOT MODIFY THIS FILE! It was generated by help2man <version>.

as the first line of the raw man page (foo.1).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 23.08.2025 00:40, Keith Thompson wrote:

Yes. I think that for some GNU tools, the info and man documents
contain the same information. For others, the man page is just a brief summary, sometimes generated from "--help" output with "help2man".

I've meanwhile looked also into the size of the man pages...

Number of man pages with number of lines
512 with 1..40 lines
1641 with 41..200 lines
781 with 201..1000 lines
159 with 1001..5000 lines
28 with 5001..20000 lines

That doesn't appear to be just irrelevant information, at least.

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-08-22 at 20:05 ADT, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 23.08.2025 00:40, Keith Thompson wrote:

Yes. I think that for some GNU tools, the info and man documents
contain the same information. For others, the man page is just a brief
summary, sometimes generated from "--help" output with "help2man".

I've meanwhile looked also into the size of the man pages...

Number of man pages with number of lines
512 with 1..40 lines
1641 with 41..200 lines
781 with 201..1000 lines
159 with 1001..5000 lines
28 with 5001..20000 lines

That doesn't appear to be just irrelevant information, at least.

Is that 20000 tight? That is, are there man pages that big, or did your histogramization (?) arbitrarily pick 20000?

Jim
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 23.08.2025 19:08, Jim wrote:

On 2025-08-22 at 20:05 ADT, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 23.08.2025 00:40, Keith Thompson wrote:

Yes. I think that for some GNU tools, the info and man documents
contain the same information. For others, the man page is just a brief
summary, sometimes generated from "--help" output with "help2man".

I've meanwhile looked also into the size of the man pages...

Number of man pages with number of lines
512 with 1..40 lines
1641 with 41..200 lines
781 with 201..1000 lines
159 with 1001..5000 lines
28 with 5001..20000 lines

That doesn't appear to be just irrelevant information, at least.

Is that 20000 tight?

(What do you mean by "tight"?)

That is, are there man pages that big, or did your
histogramization (?) arbitrarily pick 20000?

I picked the ranges arbitra

From Newsgroup: comp.unix.shell

[Please do not mail me a copy of your followup]

gazelle@shell.xmission.com (Kenny McCormack) spake the secret code <108afmi$piu7$1@news.xmission.com> thusly:

Bash maintains that the man page is the final word - the info may or may
not be kept up to date. GAWK says the opposite, which I find annoying,

Of all the Free Software Foundation/GNU projects, Info is the biggest abomination.

Change my mind.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

[Please do not mail me a copy of your followup]

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> spake the secret code <108ahql$1oon3$1@dont-email.me> thusly:

I absolutely share that feeling. - I'm not sure what the right way
would be. I fear it's something else than 'man' or 'info'.

Perl showed the way by breaking up the documentation into multiple man
pages describing different aspects of the language, e.g. syntax,
modules, etc. and the main man page guiding into which man page you
should read for further information.

The original Unix distributions from Bell Labs took a different
approach. The man page was to serve as a concise reference for the command-line arguments, related files and so-on. If the software was
more complex, like yacc, then a user guide was expected to accompany
the program and would live in /usr/doc, not /usr/man. The user guide
was expected to be written with the ms macro package not the man macro
package. However, I don't think this actually took hold culturally
anywhere except Bell Labs and the original creators of Unix.

-- Richard
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

legalize+jeeves@mail.xmission.com (Richard) writes:
[...]

Of all the Free Software Foundation/GNU projects, Info is the biggest abomination.

Change my mind.

No.

I happen to like info documents. I prefer them to man pages,
particularly for large software packages like gcc and bash.
You apparently dislike them. Your opinion does not bother me,
and I have no reason to want to change your mind.

If you wanted to say something about *why* you dislike info
documents, or perhaps even how they could be improved, there might
be something interesting to discuss.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <108ij2o$18u16$2@news.xmission.com>, Richard <> wrote:

[Please do not mail me a copy of your followup]

gazelle@shell.xmission.com (Kenny McCormack) spake the secret code ><108afmi$piu7$1@news.xmission.com> thusly:

Bash maintains that the man page is the final word - the info may or may >>not be kept up to date. GAWK says the opposite, which I find annoying,

Of all the Free Software Foundation/GNU projects, Info is the biggest >abomination.

I don't disagree. I think info was a failure to launch (*).

But others think otherwise.

(*) As I said, it is really annoying that the GAWK man page is no longer authoritative or complete. But I get it; I think the GAWK maintenance is getting a little late in the day, and they want to downsize the effort.
--
To be evangelical is to spend every waking moment hovering around
two emotional states: fear and rage. Evangelicals are seriously the
angriest and most vicious bunch of self-pitying, constantly-moaning
whinybutts I've ever encountered.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-08-25, Richard <legalize+jeeves@mail.xmission.com> wrote:

[Please do not mail me a copy of your followup]

gazelle@shell.xmission.com (Kenny McCormack) spake the secret code
<108afmi$piu7$1@news.xmission.com> thusly:

Bash maintains that the man page is the final word - the info may or may >>not be kept up to date. GAWK says the opposite, which I find annoying,

Of all the Free Software Foundation/GNU projects, Info is the biggest abomination.

Change my mind.

AutoConf, AutoMake
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-08-25, Richard <legalize+jeeves@mail.xmission.com> wrote:

[Please do not mail me a copy of your followup]

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> spake the secret code
<108ahql$1oon3$1@dont-email.me> thusly:

I absolutely share that feeling. - I'm not sure what the right way
would be. I fear it's something else than 'man' or 'info'.

Perl showed the way by breaking up the documentation into multiple man
pages describing different aspects of the language, e.g. syntax,
modules, etc. and the main man page guiding into which man page you
should read for further information.

Perl showed a way that was optimized for machines that would
have struggled with huge man pages.

It's a bad way today; all in one man page, or GTFO.

All I want is to be able to type "man <thing>" and then search
for what I want in that one single wall of text.

If it's not found in the one text then I know that either what I'm
looking for doesn't exist, or my search pattern isn't the right one. I
don't have to also suspect that I might be searching using the right
pattern, but in the wrong documentation rabbit hole.

Look at the web-hosted GNU manuals. They usually have two flavors:
all-in-one giant HTML page, or sectioned. I almost always go for the all-in-one because one Ctrl-F will search the whole thing.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 25.08.2025 23:06, Richard wrote:

Perl showed the way by breaking up the documentation into multiple man
pages describing different aspects of the language, e.g. syntax,
modules, etc. and the main man page guiding into which man page you
should read for further information.

This is definitely not what I would be seeking. As other posters
said, in a simple way searching in one document with a standard
structure (like man) would be it. And that document should have
all the essentials.

Separating the topics you mention in separate "chapters" is fine.
But having "separate pages" (whether only referred to or linked
together by some link mechanism) appears not very appealing.

Incidentally, the _separation_ I mentioned elsethread is what you
are describing here and what sounds completely reasonable to me:

The original Unix distributions from Bell Labs took a different
approach. The man page was to serve as a concise reference for the command-line arguments, related files and so-on. If the software was
more complex, like yacc, then a user guide was expected to accompany
the program and would live in /usr/doc, not /usr/man. The user guide
was expected to be written with the ms macro package not the man macro package. However, I don't think this actually took hold culturally
anywhere except Bell Labs and the original creators of Unix.

Strangely, in the past decades, I completely missed the /usr/doc
part of the Unix documentation. (I wonder why...)

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Found an interesting Mandelbrot Set script on this page <https://bash-hackers.gabe565.com/scripting/terminalcodes/> from that
selfsame wiki.

It says the ksh version is 10|u faster. I tried running it in bash, and
it flashed up in the blink of an eye.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 26.08.2025 04:04, Lawrence DrCOOliveiro wrote:

Found an interesting Mandelbrot Set script on this page <https://bash-hackers.gabe565.com/scripting/terminalcodes/> from that selfsame wiki.

Funny things they do. :-)

It says the ksh version is 10|u faster. I tried running it in bash, and
it flashed up in the blink of an eye.

You have a fast (=contemporary) computer? - Mine is rather old...

ksh (93u+m/1.0.8 2024-01-01):
real 0m00.41s
user 0m00.32s
sys 0m00.04s

bash (4.2.25):
real 0m03.22s
user 0m03.00s
sys 0m00.16s

Or are the newer bash versions meanwhile faster?

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]

Strangely, in the past decades, I completely missed the /usr/doc
part of the Unix documentation. (I wonder why...)

On some systems (Ubuntu in my case), it's /usr/share/doc .
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 26.08.2025 05:48, Keith Thompson wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]

Strangely, in the past decades, I completely missed the /usr/doc
part of the Unix documentation. (I wonder why...)

On some systems (Ubuntu in my case), it's /usr/share/doc .

Yeah, thanks. - Now I know where they are. :-)

What's still unclear to me is how to read them.

I mean, man xterm will show me the xterm manual.
And below /usr/share/doc/xterm/, for example, I
see xterm.termcap.gz and xterm.terminfo.gz, but
there's (unlike man) no doc(1) command nor does
e.g. man xterm.terminfo work, and man terminfo
will access the man entries (not these docs it
seems).

As I said, I never knew about nor worked with
these /usr/share/doc information; I'm curious.

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 26.08.2025 05:48, Keith Thompson wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]

Strangely, in the past decades, I completely missed the /usr/doc
part of the Unix documentation. (I wonder why...)

On some systems (Ubuntu in my case), it's /usr/share/doc .

Yeah, thanks. - Now I know where they are. :-)

What's still unclear to me is how to read them.

I mean, man xterm will show me the xterm manual.
And below /usr/share/doc/xterm/, for example, I
see xterm.termcap.gz and xterm.terminfo.gz, but
there's (unlike man) no doc(1) command nor does
e.g. man xterm.terminfo work, and man terminfo
will access the man entries (not these docs it
seems).

As I said, I never knew about nor worked with
these /usr/share/doc information; I'm curious.

I rarely pay attention to the stuff under /usr/share/doc. As far
as I can tell, if a project happens to have additional documentation
that doesn't fit in man or info, it's dumped into /usr/share/doc.

In particular, /usr/share/doc/xterm/xterm.terminfo.gz is just a
gzipped plain text file, viewable with `zcat xterm.terminfo.gz |
less` or equivalent (zless if you have it). ctlseqs.ms.gz is a
*roff document using ms macros; you can use, for example, `zcat ... |
groff -ms -Tpdf` to generate a 54-page PDF.

/usr/share/doc/coreutils, on the other hand, doesn't have any
real documentation, just a list of authors, some READMEs, NEWS and
changelog, etc.

You probably won't miss much by ignoring /usr/share/doc .
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 26.08.2025 22:26, Keith Thompson wrote:

[...]

You probably won't miss much by ignoring /usr/share/doc .

Obviously! :-)

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

[Please do not mail me a copy of your followup]

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> spake the secret code <108itba$3o5c0$1@dont-email.me> thusly:

On 25.08.2025 23:06, Richard wrote:

Perl showed the way by breaking up the documentation into multiple man
pages describing different aspects of the language, e.g. syntax,
modules, etc. and the main man page guiding into which man page you
should read for further information.

This is definitely not what I would be seeking. As other posters
said, in a simple way searching in one document with a standard
structure (like man) would be it. And that document should have
all the essentials.

I disagree, but it's not the end of the world to me if it's all
crammed into one 300 screen man page.

I find it convenient to say 'man perlsyn' when I need to look up some
syntax idiosyncracy in perl.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

[Please do not mail me a copy of your followup]

gazelle@shell.xmission.com (Kenny McCormack) spake the secret code <108ima1$192n6$1@news.xmission.com> thusly:

In article <108ij2o$18u16$2@news.xmission.com>, Richard <> wrote:

Of all the Free Software Foundation/GNU projects, Info is the biggest >>abomination.

I don't disagree. I think info was a failure to launch (*).

FFS, just say you agree instead of being passive aggressive.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

[Please do not mail me a copy of your followup]

Kaz Kylheku <643-408-1753@kylheku.com> spake the secret code <20250825154059.51@kylheku.com> thusly:

On 2025-08-25, Richard <legalize+jeeves@mail.xmission.com> wrote:

Of all the Free Software Foundation/GNU projects, Info is the biggest
abomination.

Change my mind.

AutoConf, AutoMake

Oooohhhhhh... tough call.

In fairness, there was nothing better when autoconf/automake/libtool
were created and it indeed solved a problem.

Whereas info was a blatant attempt at replacing something that already
worked.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-08-23 at 19:31 ADT, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Kaz Kylheku <643-408-1753@kylheku.com> writes:

On 2025-08-23, Jim <zsd@jdvb.ca> wrote:

On 2025-08-22 at 20:05 ADT, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 23.08.2025 00:40, Keith Thompson wrote:

Yes. I think that for some GNU tools, the info and man documents
contain the same information. For others, the man page is just a brief >>>>> summary, sometimes generated from "--help" output with "help2man".

I've meanwhile looked also into the size of the man pages...

Number of man pages with number of lines
512 with 1..40 lines
1641 with 41..200 lines
781 with 201..1000 lines
159 with 1001..5000 lines
28 with 5001..20000 lines

That doesn't appear to be just irrelevant information, at least.

Is that 20000 tight? That is, are there man pages that big, or did your >>> histogramization (?) arbitrarily pick 20000?

$ man txr | wc
46266 382645 2775327

No, hold it, correction. I have a wide terminal. We have to measure
using the 80 column standard:

$ MANWIDTH=80 man txr | wc
67616 386241 3110809

That's more like it!

I don't have txr on my system, but :

$ MANWIDTH=80 man ffmpeg-all 2>/dev/null | wc
49196 210446 1764012

That omits the troff "cannot break line" and "cannot adjust line"
warnings.

Over the years I've heard people complain that man pages are too terse.
Imagine if the man page for ffmpeg(-all), gcc or txr was verbose. (Maybe
the txr man page is verbose, I also don't have it on my system.)

Jim
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 27.08.2025 18:36, Richard wrote:

[Please do not mail me a copy of your followup]

gazelle@shell.xmission.com (Kenny McCormack) spake the secret code <108ima1$192n6$1@news.xmission.com> thusly:

In article <108ij2o$18u16$2@news.xmission.com>, Richard <> wrote:

Of all the Free Software Foundation/GNU projects, Info is the biggest
abomination.

I don't disagree. I think info was a failure to launch (*).

FFS, just say you agree instead of being passive aggressive.

Your attitude to tell others how they shall express themselves
indeed provokes and asks for "*active* aggressivity".

Good luck.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <108ollu$13i08$2@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 27.08.2025 18:36, Richard wrote:

[Please do not mail me a copy of your followup]

gazelle@shell.xmission.com (Kenny McCormack) spake the secret code
<108ima1$192n6$1@news.xmission.com> thusly:

In article <108ij2o$18u16$2@news.xmission.com>, Richard <> wrote:

Of all the Free Software Foundation/GNU projects, Info is the biggest
abomination.

I don't disagree. I think info was a failure to launch (*).

FFS, just say you agree instead of being passive aggressive.

Your attitude to tell others how they shall express themselves
indeed provokes and asks for "*active* aggressivity".

We all had a good laugh around here on reading "Richard"'s post.

Funny stuff.

FWIW, I often use the phrase "I don't disagree" online - rather than the
more straightforward "I agree" - because I'm not really agreeing, so much
as dispelling the standard online-forum take (*).

(*) The standard assumption in all online forums is that if you agree with someone (or at least don't violently disagree), you say nothing (don't post
at all). So, the default assumption - if you are posting at all - is that
you are contesting the previous poster's (i.e., the person to whom you are responding's) statements. It all goes back to in the early days of Usenet, when bandwidth actually cost money (cost *someone* money, that is), where
the official ethic was that you needed to be absolutely sure that you
wanted to post - since every time you did so, it cost "the net" "hundreds,
if not thousands of dollars".

This ethic discouraged so-called "me too" posts.
--
The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/FiftyPercent
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

legalize+jeeves@mail.xmission.com (Richard) writes:
[...]

Of all the Free Software Foundation/GNU projects, Info is the biggest abomination.

I'm actually interested in *why* you dislike Info. You might think the
reasons are obvious, but they're not obvious to me.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <87v7m8m3qv.fsf@example.invalid>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >legalize+jeeves@mail.xmission.com (Richard) writes:

[...]

Of all the Free Software Foundation/GNU projects, Info is the biggest
abomination.

I'm actually interested in *why* you dislike Info. You might think the >reasons are obvious, but they're not obvious to me.

Speaking only for myself, of course, but the problem is that it is neither
fish nor fowl. I don't know what problem it was trying to solve.

That is, I know what the point of "man" is. And I know what the point of
HTML is. But I don't know what the point of "info" is. And, no, I'm not asking for a tutorial; these are rhetorical "I don't know"s.

Info seems to be trying to be both - badly. Also, the keyboard interface
of the standard "info" program (on all the systems I have tried it on) is dreadful. I can never get it to work effectively.

It seems to be creating yet another standard. See the famous XKCD about
"Now there are 15 incompatible standards". Now there's just one more place
you have to look to find stuff. See my comments about how putting stuff in "info" has caused the GAWK "man" page to be diluted.
--
This is the GOP's problem. When you're at the beginning of the year
and you've got nine Democrats running for the nomination, maybe one or
two of them are Dennis Kucinich. When you have nine Republicans, seven
or eight of them are Michelle Bachmann.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Janis Papanagnou wrote:

On 26.08.2025 04:04, Lawrence DrCOOliveiro wrote:

Found an interesting Mandelbrot Set script on this page
<https://bash-hackers.gabe565.com/scripting/terminalcodes/> from that
selfsame wiki.

Funny things they do. :-)

It says the ksh version is 10|u faster. I tried running it in bash, and
it flashed up in the blink of an eye.

You have a fast (=contemporary) computer? - Mine is rather old...

ksh (93u+m/1.0.8 2024-01-01):
real 0m00.41s
user 0m00.32s
sys 0m00.04s

bash (4.2.25):
real 0m03.22s
user 0m03.00s
sys 0m00.16s

Or are the newer bash versions meanwhile faster?

Janis

I suspect a zsh version would be even faster, since `echoti` could be
used, instead of forking for `tput`.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 28.08.2025 06:58, Kenny McCormack wrote:

[...]

FWIW, I often use the phrase "I don't disagree" online - rather than the
more straightforward "I agree" - because I'm not really agreeing, [...]

Obviously. :-)

Fine granular choice of words isn't popular these days it seems. We're
living in "Trump days" (just one popular character in a set of many),
where some folks understand just "eat or die", "black or white", "good
or bad", "friend or foe", 'true' or 'false' - and, tertium non datur,
of course, in that fantasy world.

[...] It all goes back to in the early days of Usenet,
when bandwidth actually cost money (cost *someone* money, that is), where
the official ethic was that you needed to be absolutely sure that you
wanted to post - since every time you did so, it cost "the net" "hundreds,
if not thousands of dollars".

Hereabouts we're still in another instance of that; running computers
generally (and AI specifically) costs our environment CO2 immissions.
(That will effectively be a lot of money, yet much growing over time.
But future expenses are considered externalities.)

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 28.08.2025 07:46, Brian Patrie wrote:

Janis Papanagnou wrote:

On 26.08.2025 04:04, Lawrence DrCOOliveiro wrote:

Found an interesting Mandelbrot Set script on this page
<https://bash-hackers.gabe565.com/scripting/terminalcodes/> from that
selfsame wiki.

Funny things they do. :-)

It says the ksh version is 10|u faster. I tried running it in bash, and
it flashed up in the blink of an eye.

You have a fast (=contemporary) computer? - Mine is rather old...

ksh (93u+m/1.0.8 2024-01-01):
real 0m00.41s
user 0m00.32s
sys 0m00.04s

bash (4.2.25):
real 0m03.22s
user 0m03.00s
sys 0m00.16s

Or are the newer bash versions meanwhile faster?

Janis

I suspect a zsh version would be even faster, since `echoti` could be
used, instead of forking for `tput`.

Frankly, I haven't analyzed where bash spends its time here.
(And that using other primitives for certain functions in
certain cases might increase performance is a truism, as is
using other shells with its functions for specific tasks.)

You may want to test that zsh approach and inform us about
the timing results?

That bash was (still is?) up to a magnitude slower than ksh
is known for long. I cannot tell what bash did (probably)
"wrong", I just know that ksh historically spent a lot of
effort into optimizations; that's why it's typically the
faster alternative where speed matters (or also where you
want to use some more advanced shell features).

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-08-27, Richard wrote:

[Please do not mail me a copy of your followup]

gazelle@shell.xmission.com (Kenny McCormack) spake the secret code <108ima1$192n6$1@news.xmission.com> thusly:

In article <108ij2o$18u16$2@news.xmission.com>, Richard <> wrote:

Of all the Free Software Foundation/GNU projects, Info is the biggest >>>abomination.

I don't disagree. I think info was a failure to launch (*).

FFS, just say you agree instead of being passive aggressive.

You don't understand logic, do you? If you can't grasp the concept of
the absence of disagreement not being agreement, then perhaps computer
science is going to be a challenging topic for you, as some basic
concepts will require understanding precisely this distinction...
--
Nuno Silva
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <108p852$17rs2$3@dont-email.me>,
Nuno Silva <nunojsilva@invalid.invalid> wrote:
...

FFS, just say you agree instead of being passive aggressive.

You don't understand logic, do you? If you can't grasp the concept of
the absence of disagreement not being agreement, then perhaps computer >science is going to be a challenging topic for you, as some basic
concepts will require understanding precisely this distinction...

Point of order: There *is* a difference between "I agree" and "I don't disagree" - you cannot simply apply computer science/boolean logic
principles to this and conclude that they mean exactly the same thing.

I explained this all in detail in my previous post on this thread.

But as Janis notes, fine granulatity of meaning is lost on the current generation.
--
That's the Trump playbook. Every action by Trump or his supporters can
be categorized as one (or more) of:

outrageous, incompetent, or mentally ill.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 28/08/2025 at 12:45, Kenny McCormack wrote:

In article <108p852$17rs2$3@dont-email.me>,
Nuno Silva <nunojsilva@invalid.invalid> wrote:
...

FFS, just say you agree instead of being passive aggressive.

You don't understand logic, do you? If you can't grasp the concept of
the absence of disagreement not being agreement, then perhaps computer
science is going to be a challenging topic for you, as some basic
concepts will require understanding precisely this distinction...

Point of order: There *is* a difference between "I agree" and "I don't disagree" - you cannot simply apply computer science/boolean logic
principles to this and conclude that they mean exactly the same thing.

C.f. Historical Scottish trial verdicts - Guilty, Not Guilty, Not Proven. Though I believe 'Not Proven' has now been junked.

I explained this all in detail in my previous post on this thread.

But as Janis notes, fine granulatity of meaning is lost on the current generation.

--
Chris Elvidge, England
MUD IS NOT ONE OF THE 4 FOOD GROUPS
Bart Simpson on chalkboard in episode 9F15

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

[Please do not mail me a copy of your followup]

Keith Thompson <Keith.S.Thompson+u@gmail.com> spake the secret code <87v7m8m3qv.fsf@example.invalid> thusly:

legalize+jeeves@mail.xmission.com (Richard) writes:
[...]

Of all the Free Software Foundation/GNU projects, Info is the biggest
abomination.

I'm actually interested in *why* you dislike Info. You might think the >reasons are obvious, but they're not obvious to me.

- it forces me into a GNU emacs like viewer in order to find information;
the assumption is that everyone likes the emacs style of interaction
and everyone is familiar with it.

man pages use your existing PAGER

- it subdivides everything into very tiny sections (in all fairness,
this could be an author style guide problem and not something
intrinsic to info per se)

This leads to information being balkanized into tiny sections and
forces you to navigate between them instead of just pressing
SPACEBAR to scroll down in the document or use your PAGER's search
commands for locating text.

- It assumes that those people wishing to view the document as a whole
have access to LaTeX, etc., and are willing to process the document as
such.

man pages are typically preformatted into something your PAGER can
scrub through without the user having to know anything about the man
macro package, *roff processors, etc.

There's probably some more things but those are the ones off the top
of my head.

Basically they made an inferior replacement to an existing mechanism
and as near as I can tell the only reason is a "not invented here"
syndrome because at the time there were no open source implementations
of *roff.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

[Please do not mail me a copy of your followup]

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> spake the secret code <108ollu$13i08$2@dont-email.me> thusly:

Your attitude to tell others how they shall express themselves
indeed provokes and asks for "*active* aggressivity".

Better honest aggression than passive aggression.

If you want to be argumentative, don't try to hide it behind phoney
politeness.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

[Please do not mail me a copy of your followup]

gazelle@shell.xmission.com (Kenny McCormack) spake the secret code <108onlc$1kgbr$1@news.xmission.com> thusly:

We all had a good laugh around here on reading "Richard"'s post.

I'm glad you had a good laugh, "Kenny McCormack".

FWIW, I often use the phrase "I don't disagree" online - rather than the
more straightforward "I agree" - because I'm not really agreeing

...which is exactly my point. You're making it seem like you agree,
but you don't agree, but you also don't provide any counter argument.

So, in essence, your post is information free while purporting to
convey information.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

[Please do not mail me a copy of your followup]

gazelle@shell.xmission.com (Kenny McCormack) spake the secret code <108pfh0$1lv85$1@news.xmission.com> thusly:

But as Janis notes, fine granulatity of meaning is lost on the current >generation.

It's just passive aggressive argumentation rather than "fine
granularity".

Passive aggressive disagreement does not constitute an argument.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <108q63f$1n7tf$2@news.xmission.com>, Richard <> wrote:

[Please do not mail me a copy of your followup]

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> spake the secret code ><108ollu$13i08$2@dont-email.me> thusly:

Your attitude to tell others how they shall express themselves
indeed provokes and asks for "*active* aggressivity".

Better honest aggression than passive aggression.

If you want to be argumentative, don't try to hide it behind phoney >politeness.

I've been accused of a lot of things in my time, but politeness (either
real or phony or any other kind) isn't one of them.

Face it. You mis-read this situation. Admit it. Move past it.
--
The only thing Trump's made great again is Saturday Night Live.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

legalize+jeeves@mail.xmission.com (Richard) writes:

Keith Thompson <Keith.S.Thompson+u@gmail.com> spake the secret code <87v7m8m3qv.fsf@example.invalid> thusly:

legalize+jeeves@mail.xmission.com (Richard) writes:
[...]

Of all the Free Software Foundation/GNU projects, Info is the biggest
abomination.

I'm actually interested in *why* you dislike Info. You might think the >>reasons are obvious, but they're not obvious to me.

- it forces me into a GNU emacs like viewer in order to find information;
the assumption is that everyone likes the emacs style of interaction
and everyone is familiar with it.

man pages use your existing PAGER

Fair enough. info documents are usually viewed from within emacs
(C-x i invokes the "info" function) or from the separate "info" command,
which uses emacs-like keybindings by default.

(Of course that's not an issue for those of us who don't mind
emacs-style keybindings. I use vim for editing, but I'm typing
this message in emacs.)

The info command has a "--vi-keys" option that might make it more
friendly for some users. I haven't used it; I just learned about
it 30 seconds ago.

And there are alternative info document viewers. tkinfo uses a GUI,
and pinfo uses keybindings that are more obvious to non-Emacs users.

- it subdivides everything into very tiny sections (in all fairness,
this could be an author style guide problem and not something
intrinsic to info per se)

This leads to information being balkanized into tiny sections and
forces you to navigate between them instead of just pressing
SPACEBAR to scroll down in the document or use your PAGER's search
commands for locating text.

I haven't seen that in the info documents I use most (bash, gcc).
The sections seem to be of a reasonable size, and you can still search
across the entire document -- and if you press spacebar repeatedly, info
will go through (all sections of) the document.

I personally like the way info documentation is organized into
hierarchical sections. Sections that have subsections start with
a table of contents, and you can type '3', for example, to jump to
the 3rd subsection.

YMMV, of course.

- It assumes that those people wishing to view the document as a whole
have access to LaTeX, etc., and are willing to process the document as
such.

On the systems I use, it's very easy to install the "info" command.
It might even be preinstalled on some systems. (I don't think
LaTeX is involved.)

man pages are typically preformatted into something your PAGER can
scrub through without the user having to know anything about the man
macro package, *roff processors, etc.

I don't think that's true anymore on most systems. I remember older
systems having cat1, cat2, ... directories containing preformatted man
pages, in parallel with the man1, man2, ... directories that contain the
*roff input, but running *roff is fast enough these days that most
systems don't bother. Most man pages on my system are gzipped *roff
files.

The man command (at least the one provided by the "man-db" package)
still has options to use preformatted "cat" files, but I think it's
rarely used.

But the "man" command invokes the appropriate *roff command
automatically. Just as you don't need to know *roff or the man
macros to read man pages, you don't need to know TeX to read info
documents.

There's probably some more things but those are the ones off the top
of my head.

Basically they made an inferior replacement to an existing mechanism
and as near as I can tell the only reason is a "not invented here"
syndrome because at the time there were no open source implementations
of *roff.

As it happens, I like "info" for most of the same reasons that you
dislike it. Which is not to say that either of us is right or wrong.

Incidentally, it's possible to generate an "info" version of
Perl's "pod" documentation. Grab the texinfo source tree, cd to "contrib/perldoc-all", and type "make". I understand that that's
exactly the opposite of what you want, but others might find it
useful. (Personally, I find perldoc's division into sections to
be annoying; it can be difficult to know which "perl*" document
I should be looking at, and I don't know of a clean way to search
the entire document set.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 28.08.2025 20:14, Richard wrote:

[Please do not mail me a copy of your followup]

gazelle@shell.xmission.com (Kenny McCormack) spake the secret code <108pfh0$1lv85$1@news.xmission.com> thusly:

But as Janis notes, fine granulatity of meaning is lost on the current
generation.

It's just passive aggressive argumentation rather than "fine
granularity".

Your tries to redefine common meanings of expression leads to
nowhere. My honest (and "not impolitely" meant) suggestion is
to not become embogged by such hopeless tries and just stop it
before you stultify yourself.

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 28.08.2025 23:41, Keith Thompson wrote:

legalize+jeeves@mail.xmission.com (Richard) writes:

Keith Thompson <Keith.S.Thompson+u@gmail.com> spake the secret code
<87v7m8m3qv.fsf@example.invalid> thusly:

legalize+jeeves@mail.xmission.com (Richard) writes:
[...]

Of all the Free Software Foundation/GNU projects, Info is the biggest
abomination.

I'm actually interested in *why* you dislike Info. You might think the
reasons are obvious, but they're not obvious to me.

Richard's post alleviates me from collecting all the arguments and
write an own post. (Thanks for that, Richard!) - So I skip a lot...

- it forces me into a GNU emacs like viewer in order to find information;
the assumption is that everyone likes the emacs style of interaction
and everyone is familiar with it.

man pages use your existing PAGER

Fair enough. info documents are usually viewed from within emacs

...so info is an emacs subsystem sort of? ;-) (No necessity to
reply on that hoax.)

(C-x i invokes the "info" function) or from the separate "info" command, which uses emacs-like keybindings by default.

(Of course that's not an issue for those of us who don't mind
emacs-style keybindings. I use vim for editing, but I'm typing
this message in emacs.)

This is something that really astonishes me. Emacs and Vi(m) are
so fundamentally different that I wonder why you like both sorts
of editing. (I could only explain that if you'd used only subsets
of the powerful editing capabilities of one of these editors. But
speculating here might sound offending and that's not intended.)

Myself I certainly prefer to use one powerful editor (I'm a Vim
user) and if I use other tools I try to configure those that they
also use Vi(m) as underlying editor. For example in shell I set
'set -o vi', and for HTML text-input areas I used an its-all-text
plugin to facilitate that, etc.

But many tools, sadly, are designed so badly that they come with
their own variant of some primitive editor instead of using the
one defined e.g. in the respective Unix environment variables.
Then we can be lucky if they at least are consistent with the
common primitive "standards" we know from earlier days of IT.

Some tools trying to emulate other editors; I recall a horrible
experience with a Vi-emulator in... - was it Eclipse? - ...the Java-GUI-framework. It implemented just something like 1-2% of
the Vim functionality, something like a very primitive subset
that Vi newbies may probably use; yet completely inappropriate
for serious users of that editor.

The fact that I use another editing capability when writing mail
oder news is just because of me using Thunderbird that supports
just all the simple editing functions commonly seen and known
since decades (also from MS tools). I'd certainly prefer to use
one powerful editor for all.

[...]

- it subdivides everything into very tiny sections (in all fairness,
this could be an author style guide problem and not something
intrinsic to info per se)

This leads to information being balkanized into tiny sections and
forces you to navigate between them instead of just pressing
SPACEBAR to scroll down in the document or use your PAGER's search
commands for locating text.

I haven't seen that in the info documents I use most (bash, gcc).
The sections seem to be of a reasonable size, and you can still search
across the entire document -- and if you press spacebar repeatedly, info
will go through (all sections of) the document.

I'm rather doing the opposite; the Awk manual, e.g. is available
online in two HTML forms, split into sections and all-in-one. I
generally use the latter. (There's just no advantage [for me]; to
click only the page-locally available links is very restricting.
(And "luckily" we have (nowadays, for many decades now) no issues
any more with slow connections or any lack of restricting memory.)

Janis

[...]

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

legalize+jeeves@mail.xmission.com (Richard) writes:


[...]

This leads to information being balkanized into tiny sections and
forces you to navigate between them instead of just pressing
SPACEBAR to scroll down in the document or use your PAGER's search
commands for locating text.

In INFO when you just press the SPACEBAR, it indeed scrolls down through
the whole document and the extremly complicated and obscur command to
search the whole document is C-s. You seem to have a strong opinion on something you're not curious about. Just say you don't care and move
on. And by the way the MAN's pager has also some commands that 99% people
will never use.

[...]
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

phako <phako@invalid.net> writes:

legalize+jeeves@mail.xmission.com (Richard) writes:

[...]

This leads to information being balkanized into tiny sections and
forces you to navigate between them instead of just pressing
SPACEBAR to scroll down in the document or use your PAGER's search
commands for locating text.

In INFO when you just press the SPACEBAR, it indeed scrolls down through
the whole document and the extremly complicated and obscur command to
search the whole document is C-s. You seem to have a strong opinion on something you're not curious about. Just say you don't care and move
on. And by the way the MAN's pager has also some commands that 99% people will never use.

Richard listed the things he dislikes about Info *because I asked him
to*. And it's hardly surprising that someone who dislikes a tools isn't
going to have taken the time to learn all its features. BTW, both '/'
and Ctrl-S perform searches in the "info" command, with some subtle differences.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 28.08.2025 23:41, Keith Thompson wrote:

[...]

(C-x i invokes the "info" function) or from the separate "info" command,
which uses emacs-like keybindings by default.

(Of course that's not an issue for those of us who don't mind
emacs-style keybindings. I use vim for editing, but I'm typing
this message in emacs.)

This is something that really astonishes me. Emacs and Vi(m) are
so fundamentally different that I wonder why you like both sorts
of editing. (I could only explain that if you'd used only subsets
of the powerful editing capabilities of one of these editors. But
speculating here might sound offending and that's not intended.)

Yeah, I've come to accept that I'm just weird that way.

I use vim as my main editor, and I'm much more comfortable with it
for editing files. I use emacs mostly because it provides the Gnus
newsreader, which I like -- and I'm mostly reading and writing text,
not modifying it. Emacs is perhaps slightly more convenient for
writing new text from scratch. For editing and moving around in
existing text, my fingers know vim's commands better than I do;
I think "jump to the beginning of the file" and my fingers type
"gg" before I know what they're doing.

Myself I certainly prefer to use one powerful editor (I'm a Vim
user) and if I use other tools I try to configure those that they
also use Vi(m) as underlying editor. For example in shell I set
'set -o vi', and for HTML text-input areas I used an its-all-text
plugin to facilitate that, etc.

I use emacs-style keybindings in bash. I think I've tried "set
-o vi", but I found it inconvenient. Perhaps entering and leaving
"insert" mode is less of a burden for editing files and more of a
burden when editing one-line bash commands? Not sure.

[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 29.08.2025 07:23, Keith Thompson wrote:

I use vim as my main editor, and I'm much more comfortable with it
for editing files. I use emacs mostly because it provides the Gnus newsreader, which I like -- and I'm mostly reading and writing text,
not modifying it. [...]

I see.

I use emacs-style keybindings in bash. I think I've tried "set
-o vi", but I found it inconvenient. Perhaps entering and leaving
"insert" mode is less of a burden for editing files and more of a
burden when editing one-line bash commands? Not sure.

I can't tell about bash (I'm using ksh). I can only say that
whenever I'm into a bash environment the first things I do is
typing ksh<Enter>set -o vi<Enter> and the world is okay for me.

What I find extremely annoying is if I land in an editor history
line with the cursor at the end of the line and in "insert mode"
(sort of). In 99% of all history editing I want to start at cursor
column 1 and in command mode to quickly get to the place(s) where
editing is required.

I also use <Esc><V> occasionally to have the command line(s) in a
Vi text window to edit in more than one line of a compound command.

Mileages vary, of course, and what one is used to matters most, I
guess.

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:


[...]

Richard listed the things he dislikes about Info *because I asked him
to*. And it's hardly surprising that someone who dislikes a tools isn't going to have taken the time to learn all its features. BTW, both '/'
and Ctrl-S perform searches in the "info" command, with some subtle differences.

I'm glad that you doesn't mind that his "technical" argument are based on his lack of knowledge of how Info works but I don't disagree with him
expressing his opinion just him being wrong, saying it doesn't do
something when it does, implying that all softwares should behave and
have the same keyboard shortcut for the same functions, a principle that
nobody holds anymore when it goes against their personnal preferences
(eg: I don't know one VI guy that put bash in VI mode, me included).
Just says it doesn't interest you or suit your personal preference,
there is no shame in that.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

As I said, I never knew about nor worked with
these /usr/share/doc information; I'm curious.

Often, one can find information there which is distributed with the original sources, think about README's and examples. Apart from that, more in-depth documentation can be found there.

That's the case on Debian, at least, with the "more in-depth" documentation often distributed in a package seperate from the package holding the binaries.

Cheers,

Bob
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

As I said, I never knew about nor worked with
these /usr/share/doc information; I'm curious.

On 2025-08-28, Bob Vloon <usenet@bananacorp.nl.invalid> wrote:

Often, one can find information there which is distributed with the original sources, think about README's and examples. Apart from that, more in-depth documentation can be found there.

That's the case on Debian, at least, with the "more in-depth" documentation often distributed in a package seperate from the package holding the binaries.

Likewise, on Fedora. Some packages have full manuals there. But ...
1) You never know what is there, or even if there is anything there for
the package you need help with.
2) There is not really a consistent mapping between package names and
folder/file names in /usr/share/doc
3) Even if it not in /usr/share/doc on your system, it may in fact be
available in your repos, but good luck figuring out what the
package is called.

So usually, it it simpler to just Google or ask on the support forum for
the distro.
--
- Lars
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Lars Poulsen <lars@cleo.beagle-ears.com> writes:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

As I said, I never knew about nor worked with
these /usr/share/doc information; I'm curious.

On 2025-08-28, Bob Vloon <usenet@bananacorp.nl.invalid> wrote:

Often, one can find information there which is distributed with the original >> sources, think about README's and examples. Apart from that, more in-depth >> documentation can be found there.

That's the case on Debian, at least, with the "more in-depth" documentation >> often distributed in a package seperate from the package holding the binaries.

Likewise, on Fedora. Some packages have full manuals there. But ...
1) You never know what is there, or even if there is anything there for
the package you need help with.
2) There is not really a consistent mapping between package names and
folder/file names in /usr/share/doc
3) Even if it not in /usr/share/doc on your system, it may in fact be
available in your repos, but good luck figuring out what the
package is called.

So usually, it it simpler to just Google or ask on the support forum for
the distro.

I can imagine that, certainly. However, I'd like to address your three points individuallly, since I cannot relate t all of them :)

Ad 1) True. One has to find out by exploring. That's in a way annoying.

Ad 2) In Debian, I have to disagree. The package maintainers seem to be doing
a nice job here. For example, if I want to know something about INN2, I can refer to /usr/share/doc/inn2 - and that is the name of the package. Most of
the time (I'm introducing some uncertainty here - but that's because I'm not familiar with all packages on my system ;) ) I'm able to find the right directory.

Ad 3) I assume that you mean that the accompanying documentation cannot be found
easily? If that's what you mean, it's not true over here. E.g. the GCC docs (package "gcc") are in "gcc-doc" - which is a optional dependency of "gcc".

All in all, over the years, I've seen documentation - and the accessibility of the documentation, being improved, and that's a good thing.

As a side note, thinking about "info", the thing that annoyed be often was the indication in the man-page that the "full documentation" was in the info pages. However, when I accessed that, it turned out to be the manual page ;) Nevertheless, I'm under the impression that that improved also.

Concluding, I'm "relatively happy".

Cheers,

Bob
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Bob Vloon <usenet@bananacorp.nl.invalid> writes:
[...]

Ad 2) In Debian, I have to disagree. The package maintainers seem to be doing a nice job here. For example, if I want to know something about INN2, I can refer to /usr/share/doc/inn2 - and that is the name of the package. Most of the time (I'm introducing some uncertainty here - but that's because I'm not familiar with all packages on my system ;) ) I'm able to find the right directory.

[...]

I just installed inn2 on one of my Ubuntu systems. Yes, there's some documentation under /usr/share/doc/inn2, but there are also 111 man
pages in sections 1, 3, 5, and 8.

$ ls -lF /usr/share/doc/inn2
total 184
-rw-r--r-- 1 root root 5129 Jan 31 2025 CONTRIBUTORS.gz
-rw-r--r-- 1 root root 25364 Jan 31 2025 FAQ.gz
-rw-r--r-- 1 root root 31663 Feb 21 2025 INSTALL.gz
-rw-r--r-- 1 root root 1909 Jan 31 2025 IPv6-info
-rw-r--r-- 1 root root 49649 Feb 21 2025 NEWS.gz
-rw-r--r-- 1 root root 3187 Feb 21 2025 README.Debian
-rw-r--r-- 1 root root 7207 Feb 21 2025 README.gz
-rw-r--r-- 1 root root 1638 Feb 21 2025 changelog.Debian.gz
-rw-r--r-- 1 root root 5005 Feb 21 2025 checklist.gz
-rw-r--r-- 1 root root 4590 Feb 21 2025 copyright
drwxr-xr-x 3 root root 4096 Aug 29 14:54 examples/
-rw-r--r-- 1 root root 1973 Feb 21 2025 external-auth.gz
-rw-r--r-- 1 root root 5280 Jan 31 2025 history.gz
-rw-r--r-- 1 root root 11176 Feb 21 2025 hook-perl.gz
$

The stuff in /usr/share/doc appears to be information that doesn't
fit into man pages, like the installation instructions and list
of contributors.

And there's not a lot of consistency across different packages
about what goes into /usr/share/doc .
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-08-28, Richard <legalize+jeeves@mail.xmission.com> wrote:

[Please do not mail me a copy of your followup]

Keith Thompson <Keith.S.Thompson+u@gmail.com> spake the secret code
<87v7m8m3qv.fsf@example.invalid> thusly:

legalize+jeeves@mail.xmission.com (Richard) writes:
[...]

Of all the Free Software Foundation/GNU projects, Info is the biggest
abomination.

I'm actually interested in *why* you dislike Info. You might think the >>reasons are obvious, but they're not obvious to me.

- it forces me into a GNU emacs like viewer in order to find information;
the assumption is that everyone likes the emacs style of interaction
and everyone is familiar with it.

man pages use your existing PAGER

You can render an info manual into one wall of text, and pipe
to your pager:

iman()
{
info --subnodes -o - $1 | less
}

This includes all the cruft including node navigation menus that
don't do anything.

Also spits out an Index at the bottom with weird line references that
don't even remotely match the output. For instance the last few
lines of the index of a version of the GNU Make manual:

* word: Text Functions. (line 159)
* wordlist: Text Functions. (line 168)
* words: Text Functions. (line 180)
* YACC: Implicit Variables. (line 76)
* YFLAGS: Implicit Variables. (line 153)

All the (line NNN) are three digit figures, whereas the entire text
is over 13,000 lines.

Otherwise, the flattened info is usable.

- it subdivides everything into very tiny sections (in all fairness,
this could be an author style guide problem and not something
intrinsic to info per se)

We tick this checkbox; all the sections are catenated in order in
the flat wall of text.

- It assumes that those people wishing to view the document as a whole
have access to LaTeX, etc., and are willing to process the document as
such.

Tick.

man pages are typically preformatted into something your PAGER can
scrub through without the user having to know anything about the man
macro package, *roff processors, etc.

Tick.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-08-29, phako <phako@invalid.net> wrote:

legalize+jeeves@mail.xmission.com (Richard) writes:

[...]

This leads to information being balkanized into tiny sections and
forces you to navigate between them instead of just pressing
SPACEBAR to scroll down in the document or use your PAGER's search
commands for locating text.

In INFO when you just press the SPACEBAR, it indeed scrolls down through
the whole document and the extremly complicated and obscur command to
search the whole document is C-s. You seem to have a strong opinion on something you're not curious about. Just say you don't care and move
on. And by the way the MAN's pager has also some commands that 99% people will never use.

The pager you use with man is the one you choose.

I use something called "mnpgr" I wrote myself, at least on systems where
I have installed it.

mnpgr runs man in such a way that it produces the terminal escape
sequences. It then translates these into a special notation.

Vim is then invoked on the result, along with a syntax definition
for concealing the special notation and highlighting according to it.

mnpgr also remembers your position in every man man page you have
viewed before. If you type "man foo" it jumps to the line number in the
foo man page where you were the last time you viewed foo under the same terminal width that you are using now.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 30.08.2025 00:57, Kaz Kylheku wrote:

[...]

I use something called "mnpgr" I wrote myself, at least on systems where
I have installed it.

mnpgr runs man in such a way that it produces the terminal escape
sequences. It then translates these into a special notation.

Vim is then invoked on the result, along with a syntax definition
for concealing the special notation and highlighting according to it.

mnpgr also remembers your position in every man man page you have
viewed before. If you type "man foo" it jumps to the line number in the
foo man page where you were the last time you viewed foo under the same terminal width that you are using now.

Sounds interesting. Is it a standalone tool? Is it publicly available?

(Just recently I looked for a 'man' tool that invokes vi; thought I'd
have such a beast stored in my environment but didn't find anything.)

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]

(Just recently I looked for a 'man' tool that invokes vi; thought I'd
have such a beast stored in my environment but didn't find anything.)

Here's something I just whipped up:

```
#!/bin/sh

tmpfile="$(mktemp)"
man "$@" >"$tmpfile"
vim -R "$tmpfile"
rm "$tmpfile"
```

When the output of "man" is not a terminal, it discards formatting
characters, making the result easier to read.

If you like, you can set $MANWIDTH to control the width of the formatted
text.

With a few more bells and whistles, it could more reliably delete the
temp file.

"man man" is likely to provide more ideas for funky ways to display man
pages (like "man --html").
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Lawrence DrCOOliveiro <ldo@nz.invalid> writes:

On Fri, 29 Aug 2025 12:12:45 -0000 (UTC), Lars Poulsen wrote:

2) There is not really a consistent mapping between package names and
folder/file names in /usr/share/doc

Listing the contents of the package will show where all the files go, including documentation files.

On Debian-based systems, including Ubuntu:

dpkg -L packagename

On RPM-based systems (Fedora et al):

dnf repoquery -l packagename

[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-08-30, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 30.08.2025 00:57, Kaz Kylheku wrote:

[...]

I use something called "mnpgr" I wrote myself, at least on systems where
I have installed it.

mnpgr runs man in such a way that it produces the terminal escape
sequences. It then translates these into a special notation.

Vim is then invoked on the result, along with a syntax definition
for concealing the special notation and highlighting according to it.

mnpgr also remembers your position in every man man page you have
viewed before. If you type "man foo" it jumps to the line number in the
foo man page where you were the last time you viewed foo under the same
terminal width that you are using now.

Sounds interesting. Is it a standalone tool? Is it publicly available?

Yes: https://www.kylheku.com/cgit/mnpgr/about/

The main part of it which does the filtering is writtten in TXR Lisp;
someone who doesn't want that dependency will have to rewrite it
in something else.

The output notation uses {B{...}B} markers for bold,
{I{...}I} for italic and {C{...}C} for bold + italic.

There is a filter that uses state machine logic to decode the
backspace overstrikes to produce these codes.

Also, it the filter detects uses of overstrikes to produce fake
accented letters; there are some occurrences of this in the GNU Awk
man page.

In that man page, look for the section Equivalence Classes. The
description contains some accented e characters. These don't look
with MANPAGER=less. Maybe there is a way to get Unicode out of man
instead of the backspace overstrikes; in any case, mnpgr handles them,
so that section ends up like this:

[Quote from GNU Awk man page]
Equivalence Classes
An equivalence class is a locale-specific name for a list of
characters that are equivalent. The name is enclosed in [= and
=]. For example, the name e might be used to represent all of
rCLerCY, rCL|-rCY, and rCL|?rCY. In this case, [[=e=]] is a regular expression
that matches any of e, |-, or |?.

Yay ...

Another feature is that various Unicode hyphens are all mapped to
the ASCII one. I've had issues with Unicode hyphens coming out of man.

(Isn't it ironic, though? man can put out gratuitous Unicode hyphens,
while failing to crank out accented e's which we have had since ISO
Latin.)

(Just recently I looked for a 'man' tool that invokes vi; thought I'd
have such a beast stored in my environment but didn't find anything.)

It is easy to to badly or so-so (and for some people that would be fine).

One early approach I used was to (somehow, can't remember how)
have the output go into plain text, without any TTY overstrikes. So no overstrike effects, no bold codes, no italic codes. That was loaded
straight into vim, and then some syntax highlighting package (that I
think is already bundled with Vim) sort of did a few things with the
result. Actually, wait, I think this was more or less simply just:

man whatever | vim -

vim somehow recognizes the text as a man page, and provides some basic
coloring based on structural heuristics or whatever. You don't get any emphasis for things that the man page marked up emphasized.

If you just MANPAGER='vim -', it doesn't work; man will not turn off
the TTY overstrikes.

When man issues the teletype overstrike codes, they are issued for every character, so if you literally do it that way, you end up not being able
to search for emphasized words.E.g. for each underlined character C, the sequence C^H_^HC is issued: put out C, backspace, underscore, backspace
C again. At one point I actually created a Vim syntax coloring
definition for this and it worked as far as visual appearance, but
regex searches for the colored words couldn't match anything.
I ended up with a script that could be used as a MANPAGER which
ran vim, instructing it to use the syntax highlighting def for the
overstrike stuff.

My current state machine consolidates all the characters with the same
effect. The resulting markup can still break up phrases. If the man
page contains "two words" that have a different effect applied, or one
is plain and the other one is italic or bold, then you cannot
successfully search for /two words, unfortunately. They turn into
somthing like "two {B{words}B}" if the first word is normal and the
second bold. Vim will hide the {B{ stuff thanks to the mnpgr.vim
definitions, and colorize the word. This is almost certainly a WONTFIX.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-08-30, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]

(Just recently I looked for a 'man' tool that invokes vi; thought I'd
have such a beast stored in my environment but didn't find anything.)

Here's something I just whipped up:

```
#!/bin/sh

tmpfile="$(mktemp)"
man "$@" >"$tmpfile"
vim -R "$tmpfile"
rm "$tmpfile"

If the invoocation of man is under your script's control, this
works:

#!/bin/sh
man "$@" | vim -

I often pipe things to "vim -" when the regular pager isn't doing
it for me for whatever reason.

When the output of "man" is not a terminal, it discards formatting characters, making the result easier to read.

As it does in the above case, piped to vim.

However, when man feeds output to the program indicated by the MANPAGER variable, even though that pipe is not a terminal, it does generate the
TTY overstrikes. This is because pagers handle them.

At one point, I made a Vim syntax definition file which processed
them to make them look nice.

I abandoned the approach because although things looked okay,
the text emphasized with overstrikes was not searchable.

And of course what is emphasized is often pretty important words
and other tokens in the man page: exactly the items you might
often want to search for.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 30.08.2025 03:35, Kaz Kylheku wrote:

On 2025-08-30, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 30.08.2025 00:57, Kaz Kylheku wrote:

I use something called "mnpgr" I wrote myself, [...]

Sounds interesting. Is it a standalone tool? Is it publicly available?

Yes: https://www.kylheku.com/cgit/mnpgr/about/

The main part of it which does the filtering is writtten in TXR Lisp;

Ah, I already suspected so. :-) That's why I was asking. ;-)

someone who doesn't want that dependency will have to rewrite it
in something else.

[...]

(Just recently I looked for a 'man' tool that invokes vi; thought I'd
have such a beast stored in my environment but didn't find anything.)

It is easy to to badly or so-so (and for some people that would be fine).

One early approach I used was [...]
Actually, wait, I think this was more or less simply just:

man whatever | vim -

Yeah. Maybe for my poor-man's use that might suffice already.

vim somehow recognizes the text as a man page, and provides some basic coloring based on structural heuristics or whatever. [...]

Hmm.. - not in my environment. (I have to set the syntax explicitly.)
No biggie, though.

[...]

Thanks for your thorough elaboration!

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-08-30, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 30.08.2025 03:35, Kaz Kylheku wrote:

man whatever | vim -

Yeah. Maybe for my poor-man's use that might suffice already.

vim somehow recognizes the text as a man page, and provides some basic
coloring based on structural heuristics or whatever. [...]

Hmm.. - not in my environment. (I have to set the syntax explicitly.)
No biggie, though.

Slapforehead. OK, that tells me it must be something I did, and forgot
about, since I stopped using that approach.

Aha! The following in my ~/.vimrc is doing that:

:au BufWinEnter * if bufname("%") == "" && getline(3) == "NAME" | set ft=man | endif

If the buffer has no name (e.g. stdin capture), and the third line
is exactly NAME then turn on the "man" syntax highlighting
(which comes with Vim).

* * *

Speaking of which, you should also know about "vim +MANPAGER" stuff
and the :Man command.

:help MANPAGER
:help Man

The Vim manual suggests that you can do this:

export MANPAGER="env MAN_PN=1 vim -M +MANPAGER -"

You do not need the env MAN_PN=1 if your man sets that
variable, like the commonly packaged one on GNU/Linuxes.
My mnpgr stuff also depends on man exporting MAN_PN:

export MANPAGER="vim -M +MANPAGER -"

Now, hwowever, note that MANPAGER set up above ultimately
does not owrk any better or worse than the above discussed:

man whatever | vim -

when that is combined with my ~/.vimrc trick to set the filetype!!!

Either way you get the same syntax highlighting, and the
same recognition of man page names that you can jump to with
Ctrl-].

In other words, it is the "man" filetype mode that is doing
all that.

I had been obviously trying various things, because now I remember that
what was puzzling me was ... when you have MANPAGER set to "vim
+MANPAGER", what is happening with the overstrikes that would go to
another pager like less? They are disappearing.

If you just do:

export MANPAGER="vim -M -"

then you see the unprocessed overstrikes in every man page. If you then manually turn on ":set filetype=man", weird things happen; the syntax highlighting seems to be trying to do something with the overstrikes,
but incompletely/incorrectly. Something is missing.

If you look that the "man.vim" file in /usr/share/vim/...
you find it contains this line:

" Get the CTRL-H syntax to handle backspaced text
runtime! syntax/ctrlh.vim

But it seems that this "syntax/ctrlh.vim" is inadequate,
and the +MANPAGER mode doesn't use it due to the overstrikes
being stripped.

Right, so that reconstructs my past investigation into this more or
less. Realizing the ctrlh.vim stuff doesn't work, at some point I
developed a clone of "ctrl.vim" that did things properly, but ran into
the problem that the text made of individually overstricken characters
was not searchable.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 30/08/2025 at 03:57, Janis Papanagnou wrote:

On 30.08.2025 03:35, Kaz Kylheku wrote:

On 2025-08-30, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 30.08.2025 00:57, Kaz Kylheku wrote:

I use something called "mnpgr" I wrote myself, [...]

Sounds interesting. Is it a standalone tool? Is it publicly available?

Yes: https://www.kylheku.com/cgit/mnpgr/about/

The main part of it which does the filtering is writtten in TXR Lisp;

Ah, I already suspected so. :-) That's why I was asking. ;-)

someone who doesn't want that dependency will have to rewrite it
in something else.

[...]

(Just recently I looked for a 'man' tool that invokes vi; thought I'd
have such a beast stored in my environment but didn't find anything.)

It is easy to to badly or so-so (and for some people that would be fine).

One early approach I used was [...]
Actually, wait, I think this was more or less simply just:

man whatever | vim -

Yeah. Maybe for my poor-man's use that might suffice already.

vim somehow recognizes the text as a man page, and provides some basic
coloring based on structural heuristics or whatever. [...]

Hmm.. - not in my environment. (I have to set the syntax explicitly.)
No biggie, though.

[...]

Thanks for your thorough elaboration!

Janis

I use a function:

vman ()
{
COLUMNS=$((COLUMNS-5)) /usr/bin/man ${@-man} | col -bpx | iconv -c
| view -c 'set ft=man nomod' -c 'set noeb vb t_vb=' -c 'map q
<Esc>:q!<cr>' -c 'map i <nop>' -
}

which (mostly) works, sometimes having problem with fonts not being
available.
--
Chris Elvidge, England
A BELCH IS NOT AN ORAL REPORT
Bart Simpson on chalkboard in episode BABF11

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 30.08.2025 07:47, Kaz Kylheku wrote:

[...]
Aha! The following in my ~/.vimrc is doing that:

:au BufWinEnter * if bufname("%") == "" && getline(3) == "NAME" | set ft=man | endif

If the buffer has no name (e.g. stdin capture), and the third line
is exactly NAME then turn on the "man" syntax highlighting
(which comes with Vim).

It seems [in my environment] the *roff formatting creates in Vim
empty lines, maybe from some skipped control code lines; normally
the man command shows NAME in line 3, but with 'vim -' it's seen
in line 5 (with some preceding empty lines). (Changing 3->5 fixes
that but there's some uncertainty remaining that it may misbehave
depending on the formatting of the actual man page data.)
I'll observe it and will see... :-)

Thanks.

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 30.08.2025 14:28, Chris Elvidge wrote:

[...]

I use a function:

vman ()
{
COLUMNS=$((COLUMNS-5)) /usr/bin/man ${@-man} | col -bpx | iconv -c |
view -c 'set ft=man nomod' -c 'set noeb vb t_vb=' -c 'map q
<Esc>:q!<cr>' -c 'map i <nop>' -
}

which (mostly) works, sometimes having problem with fonts not being available.

Works fine for me. (Though I'll need to look up some of
the settings you used to fully understand it.) - Thanks.

BTW, why did you use multiple '-c' parameters for 'set'?

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 31/08/2025 at 07:10, Janis Papanagnou wrote:

On 30.08.2025 14:28, Chris Elvidge wrote:

[...]

I use a function:

vman ()
{
COLUMNS=$((COLUMNS-5)) /usr/bin/man ${@-man} | col -bpx | iconv -c |
view -c 'set ft=man nomod' -c 'set noeb vb t_vb=' -c 'map q
<Esc>:q!<cr>' -c 'map i <nop>' -
}

which (mostly) works, sometimes having problem with fonts not being
available.

Works fine for me. (Though I'll need to look up some of
the settings you used to fully understand it.) - Thanks.

BTW, why did you use multiple '-c' parameters for 'set'?

Janis

Can't remember. Possibly so I could chop bits out when developing and
never got round to fixing. Does work with only one '-c set' though.
--
Chris Elvidge, England
WEDGIES ARE UNHEALTHY FOR CHILDREN AND OTHER LIVING THINGS
Bart Simpson on chalkboard in episode 3F08

--- Synchronet 3.21a-Linux NewsLink 1.2