Why is lsblk not included in base install?

Well, the problem is that source codes manpages is hard to read / write / edit.
It's a different language other than C, /bin/sh, ... and not used for other than manpages.

Requested to review manpage updates / Handbook (written in asciidoc) is quite a pain.

If plain and not marked up text which looks like rendered manpages without formattings can be easily compiled into the source codes for manpages, in my humble opinion, it would make authors of small software including small shell scripts to add manpage of their codes more than currently.
 
Not exemplary.

Have you seen Linux lsblk(8) options? There are many.

See for yourself: https://linux.die.net/man/8/lsblk

THAT amount of options justifies a man page.

Do you know beadm(8)?

It also has a lot of options ... and has a man page.

Code:
% beadm     
usage:
  beadm activate <beName>
  beadm create [-e nonActiveBe | -e beName@snapshot] <beName>
  beadm create <beName@snapshot>
  beadm destroy [-F] <beName | beName@snapshot>
  beadm export [-v] <beName>
  beadm import [-v] <beName>
  beadm list [-a] [-s] [-D] [-H]
  beadm rename <origBeName> <newBeName>
  beadm mount <beName> [mountpoint]
  beadm { umount | unmount } [-f] <beName>
  beadm chroot <beName>
  beadm reroot <beName>
  beadm version

Now - mine lsblk(8) for FreeBSD has ONE option -d to list only the devices - without that option it prints devices and partitions.

That does not justifies a man page effort for me ... and we can disagree here.
 
If plain and not marked up text which looks like rendered manpages without formattings can be easily compiled into the source codes for manpages, in my humble opinion, it would make authors of small software including small shell scripts to add manpage of their codes more than currently.
For example, graphics/zathura uses textproc/py-sphinx to generate its man pages.
zathura(1)
 
Well, the problem is that source codes manpages is hard to read / write / edit.
It's a different language other than C, /bin/sh, ... and not used for other than manpages.

Requested to review manpage updates / Handbook (written in asciidoc) is quite a pain.

If plain and not marked up text which looks like rendered manpages without formattings can be easily compiled into the source codes for manpages, in my humble opinion, it would make authors of small software including small shell scripts to add manpage of their codes more than currently.
A few: Sphinx and Pandoc (and I believe even doxygen can too) produce groff man pages (but mdoc is the standard these days because it includes a whole slew of other formatting elements).

T-Aoki, please see the program I linked to in post #5, it allows you to write your manpages like the following. The program to compiles the below into a manpage can be called by your makefile upon build.

I'm really not sure how you'd be able to convert plain text -e.g., how would you recognize a section header (-i.e., that would make for complicated parsing or you would only be allowed to support a given set of header names). ...I dont think the below is hard to read and it gets converted to a manpage. *shrug*

Code:
date: Feb 03 2026
title: progname 7
author: John

# NAME
progname -- a program to change the world.

# SYNOPSIS
progname [-abc] [-f file] inpputfile outputfile

# DESCRIPTION
This utility will change the world because
it will remove all leading spaces from lines
in a text file.

# OPTIONS
-a
    Append to the outout file.

-B
    Use backward searching patterns (?...?).

-f file
    Pass a file argument to this option.

- inputfile
    The file to pass as an input.

- outputfile
    The file to write.

-

# CODE EXAMPLE
```c
    unsigned long   str_version;    /* version number */
    unsigned long   str_numstr;     /* # of strings in the file */
    unsigned long   str_longlen;    /* length of longest string */
```
 
That does not justifies a man page effort for me ... and we can disagree here.
Okay.
Frankly I didn't really checked your software out; just glimpsed at some ubuntu help pages I found.

It's simply that by principle I (personally) insist on everything has to have a man page, even when there are no options. To me the man page is always first look. If there is none, to me the SW feels undocumented. To me a software on a unix[like] system ain't not complete without a man page. I just took this opportunity to make my point clear, because in general there is so much software out there, really inexcusably insufficiently documented, sometimes even not documented at all. To me that's really a nuisance. I simply don't get it, why someone spends dozens, sometimes even hundreds of hours in writing a SW, and then don't have the time (being too lazy?), to just write at least a micro-pico docu, that at least tells, what the SW does.
As I said: Software not documented cannot be used. SW that cannot be used is useless - no matter how brilliant the SW itself may be. Especially when I stumble over developers whining why their "brilliant" SW ain't not used more, while they didn't spent any effort at all to document it halfway usably, and I think by myself:"Guess why. Who can drive your Ferrari when there is no key to even unlock the door?"

This ain't the case in this particular case, and I might be seen as a bit beancounting, okay. But I think it's also important to tell in general in an open forums, that not everybody is okay with insufficient documented software, just because (almost) nobody complains about it, and why. Because I also know and had all this discussions dozens of times for decades by developers about why their SW doesn't need to be documented at all, why in fact it really needed to. And I'm talking way more complex things as having just one -d as the only option.

I wish you have a nice weekend.:beer:
 
It's simply that by principle I (personally) insist on everything has to have a man page, even when there are no options. To me the man page is always first look. If there is none, to me the SW feels undocumented. To me a software on a unix[like] system ain't not complete without a man page.
I don't think you're wrong about a project's documentation but, yes, at the end of the day, it's up to the developer whether or not they want to provide a manpage (you cannot force anyone to write a mdoc manpage). However, you can also provide your own manpage for their tool (on your system) too. For example: even heir(7) will tell you that it's up to you--as a system admin--to maintain the documentation for directory layout -i.e. update heir(7) with your changes.

But, I get a kick out of some of the "arguments" I've had with others.
Me: "I'll write it for you. Will you accept a PR?"
Them: "No. It's a simple, and small, assumption that the user has access to the internet these days. They can use the readme on github if they need help."
 
My tool (md2mdoc) has zero dependencies. Compile and run as you would any other program. `md2mdoc ./manpage.md ./manpage.8`. Although, I have some syntax settings in my Vim which makes markdown pretty but that's not a requirement for typing a plain text file.
Make a port of it. It will first get to the ports. If it works fine and has no dependencies except cc possibilty it is it makes to the base.
 
Make a port of it. It will first get to the ports. If it works fine and has no dependencies except cc possibilty it is it makes to the base.
I've been told (by an active committer I believe/assume) that a port will not get approved unless it has a "real use for other people". I'm not sure how to show that other people "like" my tool so, I flat-out asked here for opinions on several of my tools and each time I was told "no" by user(s) here. ...I now use a custom script to compile and make my own packages locally and distribute those packages to my systems.
 
(you cannot force anyone to write a mdoc manpage).
Of course not. That's not my intension. I simply try to reason, why a man page is a useful thing, while several developers see it otherwise.
Them: "No. It's a simple, and small, assumption that the user has access to the internet these days. They can use the readme on github if they need help."
Yes. That's such a point they mostly bring up, also like to refer to some website, not getting with man pages you not only get the docu on your machine, even when there is no internet connection, or 404 - as we all know, every link to every pages is always and forever reachable at the exact same address, right? - not seeing by what shall I know, where the website with the docu is, when I don't have a man page at least containing this info (I know manpages referring to websites for eleborated docu and tutorials; which is okay, since the link in the man page can be updated, when the link changes), but above all breaking the idea of having a full comprehensive documentation in one location, instead splattering it all over the net...
Me: "I'll write it for you. Will you accept a PR?"
Yeah. That's exactly what I think about at the moment myself, to write vermaden a man page - if I insist on it, and it's no big deal, as he says, why shouldn't I do it?
 
I've been told (by an active committer I believe/assume) that a port will not get approved unless it has a "real use for other people".
...I know at least two or three ports that could be removed then, because they are absolutely useless, at least in my eyes. :cool:
 
:)

I'll help too: I'm sure it's just a "time" issue and vermaden has given a lot with his blog so, I'd have no problem helping writing a manpage. NOTE: I'll totally mess up the wording and terms.
 
I know at least two or three ports that could be removed then, because they are absolutely useless
That's hitting a little too close to home not to comment so, not sure if you just read my previous posts wrong but none of my tools (aka: 'useless tools') are ports so I'm not sure how you're going to accomplish removing my tools from my system.

:)
 
That's hitting a little too close to home not to comment so, not sure if you just read my previous posts wrong but none of my tools (aka: 'useless tools') are ports so I'm not sure how you're going to accomplish removing my tools from my system.
No, no, no,... I didn't meant any of your ports/SW (I even don't know, what you've written.)
I simply know ports that seems pretty useless. And if useless ports are not allowed in the first place, IMO useless ones can/should be removed, again.
But don't get us started on this. At least not here.
 
...I know at least two or three ports that could be removed then, because they are absolutely useless, at least in my eyes. :cool:
This kind of discussions can be seen between committers.
Not sure for which one, but when a quite active committer committed a new port, another active committer asked "why is this needed? Don't commit unneeded new ports." and the answer was something like "It is going to be required by upcoming another ports.", while, if I'm not overlooked, the port requiring it is not yet committed.
 
The problem with removing unpopular ports is what may not be useful for you may be useful for somebody else.

Like all the py* ports or p5* ports. Some of those programs were only written for one person. Nobody else uses it.
Should it go? I have stumbled on useful ports that nobody knew existed. So I have to say don't tear things down. Build them up.
This is not a popularity contest.
 
Since 35000+ ports are alot is there a chart or metrix for package downloads.
What are the bottom 5 packages by download count.
Just for vanity sakes. What are the least downloaded packages.
 
I've been told (by an active committer I believe/assume) that a port will not get approved unless it has a "real use for other people". I'm not sure how to show that other people "like" my tool so, I flat-out asked here for opinions on several of my tools and each time I was told "no" by user(s) here. ...I now use a custom script to compile and make my own packages locally and distribute those packages to my systems.
If any of ports using textproc/py-sphinx for manpages switch to yours, it is a clear reason your program is worth to be a new port.
In some cases (at least x11/kitty with DOCS option enabled), sphinx didn't work properly on poudriere, while bare metal environment is OK.
Shpinx didn't output any messages nor resulting codes and timed out.
This may be a kind of "dependency hell" that something needed are NOT properly described as dependencies.

In such a cases, switching to yours would be worth considering, if upstream noticed your codes.
 
If any of ports using textproc/py-sphinx for manpages switch to yours, it is a clear reason your program is worth to be a new port.
In some cases (at least x11/kitty with DOCS option enabled), sphinx didn't work properly on poudriere, while bare metal environment is OK.
Shpinx didn't output any messages nor resulting codes and timed out.
This may be a kind of "dependency hell" that something needed are NOT properly described as dependencies.

In such a cases, switching to yours would be worth considering, if upstream noticed your codes.
Thank you for a good explanation. I have no idea how to determine if any package/port/or anyone for that matter uses my tool or even thinks it's useful. Based on the number of "stars" (I assume that ='s "like" or "used"), I think it would be a safe bet that I do not need to create a port for it.

But again, I'm pretty sure Sphinx, Doxygen, and/or pandoc don't use the mdoc macros in their output (or maybe I just read their docs wrong) so, the above also makes me want to either delete my public repo and/or refactor the code to be more robust.
 
I've been told (by an active committer I believe/assume) that a port will not get approved unless it has a "real use for other people". I'm not sure how to show that other people "like" my tool so, I flat-out asked here for opinions on several of my tools and each time I was told "no" by user(s) here. ...I now use a custom script to compile and make my own packages locally and distribute those packages to my systems.
The fact that i has no dependencies is already very usefull
 
Because no one eats soup with a fork or spaghetti with a spoon. And FreeBSD _IS_NOT_ Linux.

% geom disk list

What is your XY problem?
 
I've looked at the code by Vermaden. It collects more information and presents the collected information is a reasonable way.
E.g. labels from zfs partitions , ext2fs mounts , etc ...

Boehaha geom disk list, it even does not tell you which gpt labels refer to which disk partition labels. A frequent problem.
When i issued "zpool list -v", i saw gpt & then damned which partion is it ?
 
Back
Top