From: Zach Riggle <firstname.lastname@example.org>
To: Ray Andrews <email@example.com>
Cc: Zsh Users <firstname.lastname@example.org>
Subject: Re: Better Help Docs Searching?
Date: Tue, 3 Aug 2021 03:03:35 -0500 [thread overview]
Message-ID: <CAMP9c5mTroPxHHYBvGtNGPNskP51CaB0+WRtT0P0ZxyuCEqqaA@mail.gmail.com> (raw)
Okay, I'm a bit of an idiot. I've been so spoiled by "brew install"
that I forgot to "autoconf && ./configure".
This explains the "make" failures I was getting above. "make info"
now works for me, and generates "Docs/zsh.texi".
I don't want to "make install" and break things by putting stuff in
/usr/local (and I expect that using --prefix=some/other/directory will
prevent "info" from actually finding that content) -- so information
on how to generate the indices for the "info" command would still be
I spent a while on Google searching things like "gnu info generate
(index|indices)" but can't really find much. "man info" isn't
helpful, and "info info" is doubly unhelpful.
On Tue, Aug 3, 2021 at 12:45 AM Zach Riggle <email@example.com> wrote:
> Thanks for all of the info (pun intended!), guys.
> I've never intentionally used the "info" command, only used it
> accidentally when I didn't import my zsh logging library (which
> defines debug/info/warn/err/die etc for use in my various scripts).
> ## Using Info
> When I invoke "info zsh" on my system (macOS 12) I do get some output.
> However when I hit shift-i, the status line at the bottom states "No
> indices found."
> Invoking manually doesn't work either, so I think there's something
> broken about the default install of Zsh on macOS (though I *also* have
> it installed via homebrew).
> $ info --index-search=read zsh
> no index entries found for `read'
> The "g" command works to jump between commands (e.g. "g read" takes me
> to the equivalent of read(2) man pages).
> I get "No indices found" for "info read" as well. :(
> ## Building Info from Source
> It seems that I'm doing this incorrectly. I inspected the Makefile
> and there is *definitely* an "info" target, but Make doesn't seem to
> like it. I tried both with the OS-provided GNU Make (3.81), and also
> with Homebrew installed GNU Make (4.3).
> $ make info
> make: *** No rule to make target `info'. Stop.
> There is definitely an "info" target.
> $ grep -E '\binfo\b' Makefile.in | head -1
> dvi ps html info pdf:
> Even trying to make it manually doesn't work
> $ make -C Doc -f Makefile.in info
> Makefile.in:30: *** missing separator. Stop.
> ## Other Info Curiosities
> One thing that I really like / prefer about man pages is the $MANPAGER
> variable, which I have configured to use bat(3)  as my pager, which
> gives syntax highlighting, highlights command names, and flag names.
> Is there an equivalent for "info" pages?
> Here's a few examples:
> * sh: https://i.imgur.com/rGjQo9v.png
> * bash: https://i.imgur.com/ymnDh5V.png
> * git: https://i.imgur.com/ABqbZmE.png
> : export MANPAGER="sh -c 'col -bx | bat -l man -p'"
> (See https://github.com/sharkdp/bat#man. The entire "bat" project
> is truly amazing.)
> Zach Riggle
> On Sun, Aug 1, 2021 at 3:11 PM Ray Andrews <firstname.lastname@example.org> wrote:
> > On 2021-08-01 11:52 a.m., Bart Schaefer wrote:
> > > On Sun, Aug 1, 2021 at 9:33 AM Stephane Chazelas <email@example.com> wrote:
> > >> It's really astonishing that so few people know about it after
> > >> so many decades it's been around.
> > Little tidbits like you guys have just coughed up would have saved God
> > knows how much frustration here. There's always a solution, but finding
> > it might not be so easy.
> > > GNU made a push some years ago to try to move everything from "man" to
> > > "info", but it never really took hold.
> > Strange, isn't it? Something in the culture sticks to the trusted
> > tradition even when a clear improvement is available. Seems to be a
> > Linux/Unix wide thing. I still remember my first successful install of
> > Linux. Bash without even command recall and no DELETE key, and one was
> > expected to either already know emacs or to use the nano editor. DOS
> > seemed advanced by comparison. Even zsh, one might think there's be
> > some default to user friendly setup out of the box but that's not the
> > way. Anyway not to whine -- thanks for the 'info' tips.
> > >
next prev parent reply other threads:[~2021-08-03 8:04 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-01 10:44 Zach Riggle
2021-08-01 11:01 ` Roman Perepelitsa
2021-08-01 16:21 ` Mikael Magnusson
2021-08-01 16:33 ` Stephane Chazelas
2021-08-01 18:52 ` Bart Schaefer
2021-08-01 20:11 ` Ray Andrews
2021-08-03 5:45 ` Zach Riggle
2021-08-03 8:03 ` Zach Riggle [this message]
2021-08-03 8:09 ` Zach Riggle
2021-08-03 8:44 ` Peter Stephenson
2021-08-03 9:40 ` Zach Riggle
2021-08-03 9:57 ` Peter Stephenson
2021-08-03 16:47 ` Bart Schaefer
2021-08-03 11:28 ` david rayner
2021-08-05 15:31 ` Vincent Lefevre
2021-08-03 16:52 ` Bart Schaefer
2021-08-01 16:25 ` Bart Schaefer
2021-08-05 9:56 ` Vincent Lefevre
2021-08-04 6:30 ` Roman Neuhauser
2021-08-04 14:56 ` Ray Andrews
2021-08-04 16:08 ` Bart Schaefer
2021-08-05 12:00 ` Ray Andrews
2021-08-04 16:38 ` Roman Neuhauser
2021-08-04 16:05 ` Bart Schaefer
2021-08-04 16:45 ` Roman Neuhauser
2021-08-14 15:41 ` Daniel Shahaf
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).