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.
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.
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).
[...]
In article <108a8i6$1mc70$[email protected]>,
Janis Papanagnou <[email protected]> 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,
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'.
[Please do not mail me a copy of your followup]
[email protected] (Kenny McCormack) spake the secret code ><108afmi$piu7$[email protected]> 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.
[Please do not mail me a copy of your followup]
[email protected] (Kenny McCormack) spake the secret code
<108afmi$piu7$[email protected]> 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.
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× faster. I tried running it in bash, and
it flashed up in the blink of an eye.
In article <108ij2o$18u16$[email protected]>, 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 (*).
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.
On 2025-08-25, Richard <[email protected]> wrote:
Of all the Free Software Foundation/GNU projects, Info is the biggest
abomination.
Change my mind.
AutoConf, AutoMake
[Please do not mail me a copy of your followup]
[email protected] (Kenny McCormack) spake the secret code <108ima1$192n6$[email protected]> thusly:
In article <108ij2o$18u16$[email protected]>, 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.
On 27.08.2025 18:36, Richard wrote:
[Please do not mail me a copy of your followup]
[email protected] (Kenny McCormack) spake the secret code
<108ima1$192n6$[email protected]> thusly:
In article <108ij2o$18u16$[email protected]>, 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".
On 26.08.2025 04:04, Lawrence D’Oliveiro 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× 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
[...]
FWIW, I often use the phrase "I don't disagree" online - rather than the
more straightforward "I agree" - because I'm not really agreeing, [...]
[...] 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".
Janis Papanagnou wrote:
On 26.08.2025 04:04, Lawrence D’Oliveiro 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× 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`.
In article <108p852$17rs2$[email protected]>,
Nuno Silva <[email protected]d> 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.
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.
FWIW, I often use the phrase "I don't disagree" online - rather than the
more straightforward "I agree" - because I'm not really agreeing
[Please do not mail me a copy of your followup]
Janis Papanagnou <[email protected]> spake the secret code ><108ollu$13i08$[email protected]> 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.
[Please do not mail me a copy of your followup]
[email protected] (Kenny McCormack) spake the secret code <108pfh0$1lv85$[email protected]> 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".
[email protected] (Richard) writes:
Keith Thompson <[email protected]> spake the secret code
<[email protected]d> thusly:
[email protected] (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.)
[...]
- 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 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 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.
As I said, I never knew about nor worked with
these /usr/share/doc information; I'm curious.
[email protected] (Richard) writes:
[...]
This leads to information being balkanized into tiny sections andIn INFO when you just press the SPACEBAR, it indeed scrolls down through
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.
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.
[Please do not mail me a copy of your followup]
Keith Thompson <[email protected]> spake the secret code
<[email protected]d> thusly:
[email protected] (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)
- 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.
[...]
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.
Janis Papanagnou <[email protected]> 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.
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.)
On 2025-08-30, Janis Papanagnou <[email protected]> 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;
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 -
vim somehow recognizes the text as a man page, and provides some basic coloring based on structural heuristics or whatever. [...]
[...]
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.
On 30.08.2025 03:35, Kaz Kylheku wrote:
On 2025-08-30, Janis Papanagnou <[email protected]> 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
[...]
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).
[...]
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.
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
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 714 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 135:11:54 |
| Calls: | 12,087 |
| Files: | 14,997 |
| Messages: | 6,517,362 |