Earlier quoted context omitted.
It would be cool if help2man worked perfectly. In fact the output needs a few fixups -- it looks like it has problems with non-ASCII characters? But if those fixups can be made automatically it's not bad and I agree might be worth adding to the build.
Yes, the output of help2man is not perfect. My main gripe is that it imposes a rather strict format for the manpage, and not all manpage markup is available. But it is better than not having a manpage at all. The problem with non-ascii characters can be solved, though. Just add an option like "-L en_US.UTF-8" to the help2man call.
BCHS: OpenBSD, C, httpd and SQLite web stack
131–140 of 158 posts
Re: BCHS: OpenBSD, C, httpd and SQLite web stack
#132Earlier quoted context omitted.
Yes, the output of help2man is not perfect. My main gripe is that it imposes a rather strict format for the manpage, and not all manpage markup is available. But it is better than not having a manpage at all. The problem with non-ascii characters can be solved, though. Just add an option like "-L en_US.UTF-8" to the help2man call.
Thanks. However, now help2man is outputting the unicode character correctly, but `man $help2manOutput` is displaying things like `a(R)` and `a` instead of the unicode character. I've also tried with the `LOCALE=en_US.UTF-8` env var set.
Re: BCHS: OpenBSD, C, httpd and SQLite web stack
#133Earlier quoted context omitted.
Thanks. However, now help2man is outputting the unicode character correctly, but `man $help2manOutput` is displaying things like `a(R)` and `a` instead of the unicode character. I've also tried with the `LOCALE=en_US.UTF-8` env var set.
This sounds like a problem with your pager, that is used to scroll the output of man pages in the terminal. Do accents appear correctly on other manpages in your system? If I recall correctly, on macos catalina I had to set my locale variable LC_CTYPE (and not LOCALE) so that the less pager recognized the accents.
- If I do `man help2manOutput | cat` then it does not page, but I still see `a` and `a(R)` in place of the desired unicode characters
- `less help2manOutput` renders them correctly
- In general I have no problem viewing unicode characters in less: I'm familiar with env vars such as LESS and PAGER.
Re: BCHS: OpenBSD, C, httpd and SQLite web stack
#134Earlier quoted context omitted.
OpenBSD pages ( https://man.openbsd.org/ ) absolutely rock and other, proper BSDs do quite well. Also, man pages are for more than just system utilities (man(1)). Which binary should hold pledge(2) ( https://man.openbsd.org/pledge ), exactly? Your man pages should be updated when the associated tool is updated. You are describing a MacOS issue, with its terrible package management, and frustrating toolchains.
You seem to be missing my point which is that, as a maintainer of a command line tool, I need to and want to cater to users of all OSs. And in fact, I will allocate my efforts more towards popular OSs. I genuinely am sure that your BSDs are a nice environment, but surely you understand how fringe they are? The majority of my users are MacOS+Windows, with substantial Linux also. In fact MacOS has an excellent package…
Re: BCHS: OpenBSD, C, httpd and SQLite web stack
#135Earlier quoted context omitted.
This sounds like a problem with your pager, that is used to scroll the output of man pages in the terminal. Do accents appear correctly on other manpages in your system? If I recall correctly, on macos catalina I had to set my locale variable LC_CTYPE (and not LOCALE) so that the less pager recognized the accents.
I don't think it's a pager problem for the following reasons: - If I do `man help2manOutput | cat` then it does not page, but I still see `a` and `a(R)` in place of the desired unicode characters - `less help2manOutput` renders them correctly - In general I have no problem viewing unicode characters in less: I'm familiar with env vars such as LESS and PAGER.
The main site of development for help2man seems to be this:
https://salsa.debian.org/bod/help2man
I'm sure they'll accept pull requests that fix problems. Happy hacking!
Re: BCHS: OpenBSD, C, httpd and SQLite web stack
#136I'd be fine with this, even totally on-board, if C weren't so awful with respect to text. You don't even have to worry too much about free()ing your malloc()s if you design around short-lived processes. But this is just asking for security concerns among the tangled web of string and input processing your bespoke C routines are likely to develop into. Pair it with a better, more modern, and safer native-compiled lang…
I just wish there were better tools for navigating C codebases. There’s been more than one time where I’m in some large auto tools based project trying to figure something out and there’s a call out to some dependencies I have no idea of. Also many of the projects lack and sort of documentation or source code commenting. These aren’t someones pet project either. One of them was from a notable name in the open source…
Re: BCHS: OpenBSD, C, httpd and SQLite web stack
#137Earlier quoted context omitted.
It totally is, as long as you don't use C instead. There are plenty of good, less complex languages than C++ out there: Java is quite close and way, way less complex, for example. But C is non of them. Pointers are more complex in C than in C++ (pointer provenance). Casts are more complicated in C than in C++, as C++ named casts are less powerful and therefore give you less opportunity to shoot yourself in the foot.…
> There are plenty of good, less complex languages than C++ out there […] But C is non of them. To this day I cannot understand how anybody can claim that. C++ is so ridiculously complex that it’s not a superset of C mostly because of added keywords and rules , some of them implicit . > I suggest using a c++ compiler to write C with enum classes, std::span, either a typed std::span wrapper for malloc or std::vector ,…
Yes, and I agree that that's a problem. But to a much lager degree it removes implicity from C. If you don't write member functions and ust inheritance (and I'm serious about this) I don't see any added implicity.
>How on earth do you write that and expect me to believe it’s simpler than C? Y
Because It is. Let me walk you thu:
- enum classes: work just like enums, minus the implicit conversions.
- std::span: incredibly simple: A struct with a pointer and a size. All wrapped up in a struct to signify indent: You don't own this. This is very simple and removes implicit assumptions from c apis. Putting data that belongs together in one struct is not alien to C. AFAIK it's considered good design.
- either a typed std::span wrapper for malloc: This is just a malloc that replaces void * for a proper type. Again, adding simplicity and removing implitity. And a facility to bounds check in way that is harder to mix up. Again, placing data that belongs together in a struct. However, if you do this, you give up the conventions that spans are not owing. That's because you might consider a std::vector (same but also can to realloc), or just write a owing_span template that does the same. The name is just very convenient documentation. By the way, the suggest classes so far can reasonably written by yourself in a few lines of code.
-std::string : This one is the first to be non trivial to implement by your self, but dont be picky, just use the one from the standard. It very easy to use. And C Strings just suck.
-std::string_view: This is a struct{const char*; size_t;}, plus a few member functions, without any magic. While I suggest you don't write you own member functions, using this is just fine. And significantly harder to make mistakes with than with C.
-std::variant: This is just a union. But with most footguns removed. If you don't use unions in C, dont juse this.
-std::unique_ptr: This is this first bit of code that is somewhat magic, as it cleans up after itself. Just always correctly placed free()s. It also signifies ownership. I see how this is somewhat controversial, but for me this a massive simplification. But see, this list was ordered, and this was towards the end.
- std::fmt: Enjoy how C-Style var args don't have any type safety? Love the good old printf-exploits? Then this is not for you. Otherwise it's pythons easy and loved string interpolation.
-std::optional, templates, std::vector: This is definitifly getting more c++ is, but not complicated. Std::optional is a struct with a bool and one additional member, templates are way to do generic programming in a way easier way than preprocessor macros. But yes, may to much C++ fore some peoples liking. That's why these are last.
>That’s impossible from you own statement.
C does some pretty IMHO insane stuff called pointer provenance. AFAIK C++ doesn't. Also named casts. Harder to remove const by accident.
>You’ve just listed a number of options on how to implement an enum of all things.
Uhm.. What?
>but I’m just trying to get my job done.
If there is one pragmatic language out there, It's c++ (or maybe perl). In fact I'd say that why is so complex compared to more academic languages like scheme, haskell, prolog and pascal.
Re: BCHS: OpenBSD, C, httpd and SQLite web stack
#138Earlier quoted context omitted.
It totally is, as long as you don't use C instead. There are plenty of good, less complex languages than C++ out there: Java is quite close and way, way less complex, for example. But C is non of them. Pointers are more complex in C than in C++ (pointer provenance). Casts are more complicated in C than in C++, as C++ named casts are less powerful and therefore give you less opportunity to shoot yourself in the foot.…
Yeah, I'm just going to keep writing C. Thanks.
Re: BCHS: OpenBSD, C, httpd and SQLite web stack
#139Interesting CGI content linked on there. I've been reading about / hacking on CGI recently, and it's been kinda fun! Question: One thing I keep reading is how inefficient it is to start a new process for each incoming connection. Could someone explain to me why that's such a bottleneck? I imagine it being an issue back when CGI was used everywhere, people moving away from CGI, and forgetting about it. But hasn't ther…
Re: BCHS: OpenBSD, C, httpd and SQLite web stack
#140Earlier quoted context omitted.
> There are plenty of good, less complex languages than C++ out there […] But C is non of them. To this day I cannot understand how anybody can claim that. C++ is so ridiculously complex that it’s not a superset of C mostly because of added keywords and rules , some of them implicit . > I suggest using a c++ compiler to write C with enum classes, std::span, either a typed std::span wrapper for malloc or std::vector ,…
> Mikrotik version of C ? Reference to the Latvian network kit manufacturer?
Doing something as simple as adding an access point will take you a full day if you aren’t familiar with it.