lingo.lol is one of the many independent Mastodon servers you can use to participate in the fediverse.
A place for linguists, philologists, and other lovers of languages.

Server stats:

66
active users

#manpage

0 posts0 participants0 posts today
Mark T. Tomczak<p>(Possibly relevant to <span class="h-card" translate="no"><a href="https://social.jvns.ca/@b0rk" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>b0rk</span></a></span> 's interests)</p><p>So I hit a flag in diff, <code>--unchanged-group-format</code>. It does not show up in the manpage. It does not show up in --help. You can search both those channels for that string and you will not find it.</p><p>You know where it shows up first? If you Google it, you'll get an example in <a href="https://www.gnu.org/software/diffutils/manual/html_node/Line-Group-Formats.html" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="ellipsis">gnu.org/software/diffutils/man</span><span class="invisible">ual/html_node/Line-Group-Formats.html</span></a>.</p><p>So why doesn't it show up in the manpage? Well, it does! If you read the entire manpage. With your eyes.</p><pre><code> -D, --ifdef=NAME output merged file with '#ifdef NAME' diffs <br> --GTYPE-group-format=GFMT format GTYPE input groups with GFMT <br> --line-format=LFMT format all input lines with LFMT <br> --LTYPE-line-format=LFMT format LTYPE input lines with LFMT <br> These format options provide fine-grained control over the output <br> of diff, generalizing -D/--ifdef. <br> LTYPE is 'old', 'new', or 'unchanged'. GTYPE is LTYPE or 'changed'. <br></code></pre><p>"What do you mean it isn't documented? Of course it's documented. You did read every line and do some template-substitution in your brain, didn't you?"</p><p>This isn't advocating for <em>not</em> reading the manpage. If you really want to understand how the tool works, you read the whole manpage. And probably the source code. 😉 </p><p>... but I <em>don't</em> want to understand how the tool works. I want to diff two files and not have the lines that are the same get emitted.</p><p>And I think a lot of application- and solution-generating computer people, most of the time, in most of their careers, are operating on that level of depth. Problems come in too fast and with too much variety. You <em>absolutely</em> go deep on some things. There is <em>no time</em> to go deep on everything.</p><p>So how do we address this (other than throw up our hands and say "Relying on Google's fuzzy search of the whole Internet and vibe-coding LLMs is the future actually")? I don't have magic bullets, but a "fuzzy search" mode in something like <code>less</code> that could take an input like <code>--unchanged-group-format</code> and twig that it if there's no exact match, it <em>might</em> be related to <code>--GTYPE-group-format</code> would be nice.</p><p>Maybe I should mock that up in emacs. Actually, I bet someone already put it in emacs. ;)</p><p><a href="https://mastodon.fixermark.com/tags/emacs" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>emacs</span></a> <a href="https://mastodon.fixermark.com/tags/manpage" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>manpage</span></a> <a href="https://mastodon.fixermark.com/tags/less" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>less</span></a></p>
Eelco Mulder :mastodon: 🇪🇺<p><span class="h-card" translate="no"><a href="https://mastodon.nl/@mboelen" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>mboelen</span></a></span> </p><p>Wow Michael, wat een werk en wat een boel nuttige info! Rustig uitgelegd en helder verwoord.</p><p>Ik heb zelfs geleerd dat alle package managers TODO heten 🙃 😇 </p><p>Maar alle gekheid op een stokkie, kudo's voor al je werk! Ik ga er zeker zelf nog van leren en zeker naar verwijzen bij mijn geïnteresseerde leerlingen!</p><p><a href="https://mastodon.nl/tags/linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>linux</span></a> <a href="https://mastodon.nl/tags/manpage" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>manpage</span></a></p>
Lars Wirzenius<p>On this day in 1971 the first edition of the Unix Programmer's Manual was published, with the first man pages.</p><p><a href="https://en.wikipedia.org/wiki/Man_page" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="">en.wikipedia.org/wiki/Man_page</span><span class="invisible"></span></a></p><p><a href="https://toot.liw.fi/tags/OTD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OTD</span></a> <a href="https://toot.liw.fi/tags/Unix" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Unix</span></a> <a href="https://toot.liw.fi/tags/Manual" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Manual</span></a> <a href="https://toot.liw.fi/tags/ManPage" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ManPage</span></a></p>
zirias (on snac)It just came to my mind that another thing should probably go on the V1.0 roadmap for <a href="https://snac.bsd.cafe?t=xmoji" class="mention hashtag" rel="nofollow noopener" target="_blank">#Xmoji</a>: A <a href="https://snac.bsd.cafe?t=manpage" class="mention hashtag" rel="nofollow noopener" target="_blank">#manpage</a>. But then, this reminds me of doubts I had ever so often: <a href="https://snac.bsd.cafe?t=documentation" class="mention hashtag" rel="nofollow noopener" target="_blank">#Documentation</a> should have a <b>single source of truth</b> (otherwise it will go out of sync <i>eventually</i>).<br><br>I could just declare that's the manpage now, which would mean to remove everything I put there from the <code>README.md</code>. Not ideal though, this markdown file is accessible for direct reading on github (and would be on other "hosted git" solutions), while it's still well readable as plain text. This certainly isn't true for some roff-like markup. 😞 There's the additional problem of which markup flavor to choose: the modern <code>mandoc</code> (which is native on <a href="https://snac.bsd.cafe?t=freebsd" class="mention hashtag" rel="nofollow noopener" target="_blank">#FreeBSD</a>), or the classic troff <code>man</code> macro package (which still seems "native" in <a href="https://snac.bsd.cafe?t=gnu" class="mention hashtag" rel="nofollow noopener" target="_blank">#GNU</a><span></span>'s man-db)... Modern installations support both flavors, but conversions aren't "perfect".<br><br>There are also many "document generators" around that typically allow output as <code>html</code>, <code>pdf</code>, <code>man</code>, ... but I didn't find one so far that really gave satisfactory results for man. A while ago, I wrote my own tool which can generate <a href="https://snac.bsd.cafe?t=c" class="mention hashtag" rel="nofollow noopener" target="_blank">#C</a> source for "help" output, <code>man</code> (in both flavors) and <code>html</code>, and this worked pretty nicely, but the key was a very limited scope, it only supports a few sections (general description, options, environment variables) and only options in the classic <a href="https://snac.bsd.cafe?t=posix" class="mention hashtag" rel="nofollow noopener" target="_blank">#POSIX</a> style (single letter, collapsible). So, it wouldn't fit the bill for Xmoji.<br><br>Great ideas anyone? 😁<br>