Hi Jan, Jan Stary wrote on Thu, Feb 12, 2015 at 02:52:33PM +0100:
> I have some man pages installed in $HOME/man > so I augment my manpath like this in my ~/.shrc > > test -d $HOME/man && alias man="man -m $HOME/man" > > Now man(1) complains saying > > $ man ls > man: -m/home/hans/man: Bad argument I fail to reproduce on -current, it works for me. Jan Stary wrote on Thu, Feb 12, 2015 at 05:17:52PM +0100: > With man unaliased, it works just fine. > With 'man -m ~/man', or with man aliased to that, > 'man ls' gave me the error above. [...] > current/amd64 How old is that -current, exactly? As a rough indication, please show the output of "dmesg | head -n2". If you snapshot is older than http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/main.c#rev1.115 (December 21, 2014), you are falling prey to a bug reported almost two months ago by Alessandro de Laurenzis (and fixed back then). John Merriam wrote on Thu, Feb 12, 2015 at 10:15:08AM -0500: > I noticed that in the error message there is no space between -m > and the path. That seems a bit odd. It is odd. It is a remnant from the pre-POSIX past. Traditional roff programs did not use spaces between their options and option arguments, and that tradition is still somewhat alive. For example, most people would probably consider groff -mdoc -Tascii -P-c /usr/share/man/man1/ls.1 more natural than groff -m doc -T ascii -P -c /usr/share/man/man1/ls.1 even though both work exactly the same way. The mandoc(1) utility handles both forms, too. In the documentation, i use the modern form at some places (for example, see the man(1) manual in -current) but the traditional form in other places (for example, see the mandoc(1) manual in -current). I should probably clean that up to use the modern form everywhere. The error messages all used the traditional form in the past, but used the modern form now (changed in the same commit main.c rev. 1.115 mentioned above). > Your `test -d $HOME/man && alias man="man -m $HOME/man"` works fine > for me in ksh when I put it in a .profile on 5.6 -stable. Oh, -stable is a completely different beast. While -current is using the mandoc implementation of man(1), -stable is using the traditional BSD implementation. trondd wrote on Thu, Feb 12, 2015 at 11:29:18AM -0500: > $ man -V > mandoc 1.13.2 That means very little on OpenBSD, mandoc(1) and man(1) are moving targets on OpenBSD and i only crank the version number rarely, when doing portable releases. The version number is mostly for the benefit of non-OpenBSD systems, in particular NetBSD, FreeBSD, DragonFly, illumos and the Linux distributions using it, that is, currently Void, Alpine, Arch and Crux Linux. John Merriam wrote on Thu, Feb 12, 2015 at 11:45:21AM -0500: > Hmmm. There was one small change to man.c on January 16th > but it doesn't look like that should be the problem I wouldn't > think. Previous change was back in 2013. Oh, you mean Theo's commit http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/man/man.c#rev1.49 That's actually changing dead code that is no longer compiled, and on top of that, it's changing the code in an incorrect way such that it won't compile even if you try to build it manually: $ cd /usr/src/usr.bin/man $ make man.o [...] /usr/src/usr.bin/man/man.c:228: error: 'MACHINE' undeclared [...] I didn't complain because, well, people can break dead code as much as they like. After unlock, i'm planning to delete that file from CVS anyway. The code we are talking about is in /usr/src/usr.bin/mandoc/main.c, not in /usr/src/usr.bin/man/man.c. > If no one else answers the thread on misc I would recommend > sumitting a bug with sendbug. Correct in general, but not really needed for issues with mandoc(1) and man(1). I do read misc@. trondd wrote on Thu, Feb 12, 2015 at 12:05:40PM -0500: > Ok, I don't know how this is controled, but the problem is, you are > actually running mandoc for which, -m means something different. Which implementation of man(1) you are using depends on which version of OpenBSD you are running... ;-) Indeed, "mandoc -m" means "select macro language" while "man -m" means "prepend to man path". But the mandoc implementation of man(1) and mandoc(1) is supposed to know the difference and handle both correctly. Yours, Ingo
