man messed up in debian

[Ethan Azariah]

i'm back on linux with debian. i git-pulled and INSTALLed plan9port this morning, in /data/vm/9/plan9port/. man fails if i use the `9` script, but otherwise miraculously succeeds. success however pollutes the output with ANSI codes, even in 9term with TERM=dumb.

in xterm/bash:
$ 9 man 9term # pager displays empty file
man: command exited with status 255: (cd /data/vm/9/plan9port/man && /usr/libexec/man-db/zsoelim) | (cd /data/vm/9/plan9port/man && /usr/libexec/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE) | (cd /data/vm/9/plan9port/man && preconv -e UTF-8) | (cd /data/vm/9/plan9port/man && tbl) | (cd /data/vm/9/plan9port/man && nroff -mandoc -rLL=101n -rLT=101n -Tutf8)

in `9term rc -l`, results are the same. man attempts to run the pager which warns the terminal is not fully functional, but after you acknowledge the warning, the same "byte 0/0" prompt appears, confirming empty file. on quitting the pager, the identical error message is displayed.

all the files and the directory in the error message exist.

accidentally running bash in `9 9term` got a different error message:
$ man rc
bash: /data/vm/9/plan9port/bin/man: cannot execute: required file not found

/data/vm/9/plan9port/bin/man does not exist.

without the `9` script, i can get a man page for, say, acme simply by running `man acme` with no qualifiers. i imagine the man package in debian cached something the first time i ran `9 man [whatever]`. i wonder if it'll break the next time i `apt install` something and man indexes are updated. also, these pages are sent into PAGER regardless of TERM=dumb, and polluted with ansi color codes. tolerable in xterm, not so much in 9term. if i set PAGER=cat, the color codes remain.

getting man pages for acme, sam, rc (for the moment) and other programs which are not installed in debian works as above. for programs such as `ls`, it gets the debian (gnu coreutils) version. to get the manual page for the plan 9 version of ls, i apparently have to `man $PLAN9/man/man1/ls.1`, or i can `man -a ls`, quit the first pager, and press return at the prompt to view the second page.

acme with plumber, launched without `9`, shows man pages without color code pollution. it shows the coreutils version of ls(1).

acme with plumber, launched with `9`, shows a new error message. on plumbing `acme(1)`, a window named "/man/acme(1)" appears, but it contains this:
usage: col [-bfx]
troff: cannot open /data/vm/9/plan9port/troff/term/tab.utf8; stdin:1
man: command exited with status 255: (cd /data/vm/9/plan9port/man && /usr/libexec/man-db/zsoelim) | (cd /data/vm/9/plan9port/man && /usr/libexec/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE) | (cd /data/vm/9/plan9port/man && preconv -e UTF-8) | (cd /data/vm/9/plan9port/man && tbl) | (cd /data/vm/9/plan9port/man && nroff -mandoc -rLL=88n -rLT=88n -Tutf8)

plumbing `ls(1)` gets this. i think it's the same message but i'm done checking.
usage: col [-bfx]
troff: cannot open /data/vm/9/plan9port/troff/term/tab.utf8; stdin:1
man: command exited with status 255: (cd /data/vm/9/plan9port/man && /usr/libexec/man-db/zsoelim) | (cd /data/vm/9/plan9port/man && /usr/libexec/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE) | (cd /data/vm/9/plan9port/man && preconv -e UTF-8) | (cd /data/vm/9/plan9port/man && tbl) | (cd /data/vm/9/plan9port/man && nroff -mandoc -rLL=88n -rLT=88n -Tutf8)

note that almost all these tests were made with a pwd of $PLAN9/font . a few xterm tests were run in /home/eekee . in no case was pwd $PLAN9/man or any subdir.

i would like the setup i had years ago: p9p man pages are opened in p9p (under man), other man pages are not.

finally...
*swishes cloak over face to shield against crosses and garlic*
"emacs m-x man acme" doesn't find acme's man page.

[Dan Cross]

On Wed, Jun 17, 2026 at 8:16 AM Ethan Azariah <eek...@fastmail.fm> wrote:
> i'm back on linux with debian. [snip]

Hmm. It appears that the Plan 9 `man` command was not installed, and
the output you are seeing is coming from the system `man` command (not
terribly surprising). Did you see any errors when building? And are
you certain that your `9` command is the one that was installed from
plan9port?

[Ethan Azariah]

On Wed, Jun 17, 2026, at 2:56 PM, Dan Cross wrote:
> On Wed, Jun 17, 2026 at 8:16 AM Ethan Azariah <eek...@fastmail.fm> wrote:
>> i'm back on linux with debian. [snip]
>
> Hmm. It appears that the Plan 9 `man` command was not installed, and
> the output you are seeing is coming from the system `man` command (not
> terribly surprising).

i think i've found it. this is the first line of /data/vm/9/plan9port/bin/man:
#!/usr/local/plan9/bin/rc

the path mismatch is obvious. :) install(1) claims INSTALL will fix paths, but i guess it missed that one.

if i run `9 rc ./bin/man ls` i get the p9p ls man page with no pager or colors as expected, so the script itself works, it's just the #! line.

it looks like INSTALL doesn't fix any of the script paths. i've still got my old `fix-rc-scripts` script which can auto-fix rc and awk #! lines. i'll run that later.

> Did you see any errors when building?

there's nothing in install.log

> And are
> you certain that your `9` command is the one that was installed from
> plan9port?

it's not quite, but it's close. i checked the p9p `9` command and found these man issues are the same.

[Ethan Azariah]

On Wed, Jun 17, 2026, at 4:12 PM, Ethan Azariah wrote:
>
> i think i've found it. this is the first line of /data/vm/9/plan9port/bin/man:
> #!/usr/local/plan9/bin/rc
>
> the path mismatch is obvious. :) install(1) claims INSTALL will fix

> paths, [snip]

>
> it looks like INSTALL doesn't fix any of the script paths. i've still
> got my old `fix-rc-scripts` script which can auto-fix rc and awk #!
> lines. i'll run that later.

here's fix-rc-scripts. it gets a bit spammy given a deep tree, but that first echo can be removed to fix that. the echo is useful when you run it from somewhere other than a built p9p install.

% cat fix-rc-scripts
#!/usr/bin/env rc
rfork e

# Fix rc shell scripts to find rc without launching env every time.
# Invoke with rc and plan9 versions of grep and ed in $PATH
# Under Plan 9, source this in a subshell: @{. fix-rc-scripts}
# (it's not a disaster if you omit the subshell,
# it will just make 2 unnecessary environment variables.)

# changelog:
# * fixes awk scripts too
# * no longer requires which
# * fixed to source itself rather than run, and to rfork e

rc=() awk=()
rc=`{whatis rc}
firstline='#!'$"rc
awk=`{whatis awk}
firstline_awk='#!'$"awk' -f'
echo $firstline $firstline_awk

if(~ $#* 0) files = *
if not files = $*

myname = `{basename $0}

for(file in $files) {
if(test -d $file)
@{. $0 $file/*}
if not if(~ $file *$myname)
{}
if not if(sed 1q $file | grep '^#!/.*[/ ]rc$' > /dev/null) {
{
echo 1c
echo $firstline
echo .
echo wq
} | ed $file > /dev/null
}
if not if(sed 1q $file | grep '^#!/.*[/ ]awk[ ]+-f$' > /dev/null) {
{
echo 1c
echo $firstline_awk
echo .
echo wq
} | ed $file > /dev/null
}
}