FYI: With our apologies for the delays, the manual and the HCL are back online; i.e., illumos.org/man and illumos.org/hcl

Hi. I have a documentation patch for memory(3c), but I have no idea where to send the patch. I've read illumos.org/docs/contributing and it points to create an account on issue tracker, but no mention where to submit the patch.

in general, once you have the account, you can post it to gerrit -- code.illumos.org (I hope the steps are documented).

Oh nice, thanks @tsoome!

of course, the problem with updates to manuals is pain with gerrit - it does not provide diffs for renrered text and such

rendered*

historically we have had webrev reviews as well (see /opt/onbld/bin/webrev), but that requires web server

and today we practically do not see webrev reviews even for manual page updates

interestingly, cr.illumos.org is still pinging:)

ah, and it is providing link to gerrit guide as well:)

the other steps for Gerrit reviews and RTI are described in the Code Review/Submitting A Patch sections of that docs page, though this is a good reminder to nudge folks about illumos/docs #100

the docs changes aren't anything super fundamental but i think it helps some of the whys make a little more sense :)

IMO we should have something better for manuals, it is such an important part and is usually most annoying to review:D

well, unless its really small change ofc

yeah i basically assume right now you'd just want to pull the change and see how it looks locally to review and that's not the best...

whaaat, there is no zilstat. pity...

Hurray, the HCL is up again :). If anybody is interested, I asked whether Broadcom PEX 8747 is compatible with Illumos (specifically this card for NVMe SSDs: delock.com/produkt/90078/merkmale.html). I was able to test it today on the latest SmartOS release and format sees all four NVMes, so looks good!

Maybe somebody in charge of the HCL wants to add that?

.oO 5368709120 bytes (5 GiB) transferred in 7272,137029 secs (721 KiB/sec)

[illumos-gate] 16879 pkglint fails on openindiana with more unexpected /32 packages -- Bill Sommerfeld <sommerfeld⊙ho>

[illumos-gate] 17202 unix needs memstr.c -- Toomas Soome <toomas.soome⊙mi>

errm, is it just me or man -M switch is broken?

man appears to search system path and ignores path from -M (for me)

How are you using it?

I use it a bunch while developing manual pages in illumos and haven't had issues.

for example: man -M /code/illumos-gate/usr/src/man memory

there is small fix in memory.3c (we are missing const from memchr and memrchr)

That works for me on my system.

I modified a file in the clone.

And seems to be fine whether I use the absolute or relative path.

so it must be me

Just to confirm, it is /usr/bin/man?

yes, according to which... I'm double checking, it really does not seem to make sense...

are you sure you gave it the -M switch there, and didn't accidentally give it the manN directory?

sigh, got it. this vim in omnios is creating backup file with ~ at the end and man command is picking up 951: open64("/code/illumos-gate/usr/src/man/./man3c/memory.3c~", O_RDONLY) = 3

it treats memory.3c~ as memory(3C)?

not memory(3C~)?

eugh

yes, it seems so

it seems like another bug to me

but well...

this is the command and check: pastebin.com/FTAvnq7Z

and thanks!

So, here's what's going on.

reading the code in man.c's searchdir() I see why this is happening - when checking for a match, it's ignoring everything in the filename after the last '.', and returning the first match

The thing is we're not specifying a section.

Yeah, exactly.

This would be the same thing with same why you get section 1 before section 4/7 of the same thing.

If you did man -a you'd get all of them.

So in this case, man is doing what it kind of expects, but in a weird way.

If you said memory.3c then it wouldn't find that.

But the same would be true if you made man/man3c/memory.a man/man1/memory, etc.

ok, so the .sectionname suffix is just a decoration

Well... it's a bit of a hack.

If you don't specify -s to suggest a specific manual, man will always search all sections for something that matches.

And .3c~ matches ahead of .3c in this case. And without -a it stops after the first.

If you specify foo.3c then it does try to find a file named that in all sections, which it'll only find in 3c.

At least, IIRC.

I think the assumption toomas (and I, honestly) had was that the directory implied in the search and the extension had to match for man to care

at least its amusing way to shoot myself into the leg:D

that is, that manfoo/page.bar would never hit

more generally man(.*)/page.\1

Well, I think that would be an optimization that man could imply, but you are saying logically search for every file named foo in the path.

So it's just a simple for each path entry, for each section, is page present. But it would be reasonable for it to append something in that search.

so if I do `man -s 3c foo`, does man search for 'foo.3c' in the entire path, or man3c/foo.*?

or man3c/foo.3c

It just appears to search for foo.3c with upper/lower case logic.

I know it finds the right thing, but I haven't looked at how it does.

yeah, I'm just wondering how wrong my assumptions have been

it's not like I ever drop random files into my man path, and I have long configured editor files to go somewhere else because of similar disasters to this (though not this one)

I dunno. I mean, it'd be reasonable to me to have man only look for foo.X in it's looking in manX.