This library has an unfortunate name. When pronounced, it sounds like "libcocks". "Cock" is American slang for "penis". "Cocks" refers to multiple penises.
I know it may seem minor or irrelevant to some here, but a name like that could cause problems for some users, ultimately preventing them from using this library, even if it were the best option available.
These kinds of users are in environments where the use of the word "cock", or even a word that could be misconstrued as being "cock", are not considered acceptable.
I could very well be feeding a troll here but I found your point, frankly, ludicrous. Cox is itself a valid word [1] with meaning entirely unrelated to the male genitalia. I don't think the library was named after, for instance, a certain English apple but I find the idea of avoiding a library simply because its name happens to be a homophone of a crude word to be absurd; perhaps it is further indicative that one has a tendency to think of others as juvenile?
Nothing wrong with the name. Almost any combination of letters is a slang for something 'inappropriate' somewhere in the world. [edit] e.g. this is absolutely hilarious to a German: http://de.wix.com/ (wix sounds like German slang for masturbating)
Not sure if climbing this high on HN on a U.S. holiday indicates a real need or clever marketing for this new project, but congratulations to them for getting the word out.
Thanks also to you for sharing a couple well-established alternatives.
As it explains quite clearly, this is "portable system calls". Lightweight indeed, it's the whole point!
So if you ask this question, you might as well ask why system calls are not more expansive in their capabilities.
I think there's a reason, system calls are much simpler. They are building bricks. If you want to layer something complex on top, you're free to do so.
About your suggestions, ACE's documentation is particularly bad. I wouldn't recommend it to anyone.
This project is using the phrase "system call" idiosyncratically / incorrectly: by it they mean "calls to the system() function", not "low-level OS facilities". POCO and ACE seem to be about actual system calls (network programming, threads, pipes, etc.) They're for very different purposes.
libcox is for when your existing code would do something like system("uname") or system("ls") (... except not even with system(), with popen() or something), and you want it portable to Windows.
Thought it was either written by Russ Cox or it had something to do with Roosters. But seriously, it's more of a personal problem if someone can't make the minute mental leap to discriminate between cox and cocks-the name is perfectly fine and doesn't need to be changed.
rc = libcox_exec_fmt(pHandle,&pResult,"ls '%s'",zDir); /*Don't forget the single quotes around 'zDir' */
This is either insecure, or so different from a shell as to make it not worth using shell syntax.
I really like the concept though. Took me to figure out what the concept is because "system calls" doesn't mean "shell commands" to me, but having figured that out, operating on shell commands has a lot of things going for it.
Hi, this is due to the fact that zDir may contain spaces especially under windows which confuse the command processor to interpret it as multiple arguments and not a single one as with single or double quotes (http://libcox.net/arch.html)
So what are the quote parsing rules for libcox, and given an arbitrary string, how do I correctly escape them?
(In the absence of this, and certainly in the absence of official docs/examples that do the right thing, that's a security vulnerability waiting to happen.)
Why do you take care of space escaping but not others (quotation marks)? This might lead to false expectations, i.e. that you take care of everything, security-wise.
Why use command processing (e.g. `libcox_exec(pHandle,&pResult,"uname",-1)`) rather than plain function (could be `libcox_uname(pHandle, &pResult)` for instance) ?
no need to release a new version by a adding a new public API function each time a command is added. You would simply create a new foreign command in your application, register it via libcox_register_command()[1] without modifying the library core.
30 comments
[ 2.9 ms ] story [ 76.4 ms ] threadI know it may seem minor or irrelevant to some here, but a name like that could cause problems for some users, ultimately preventing them from using this library, even if it were the best option available.
These kinds of users are in environments where the use of the word "cock", or even a word that could be misconstrued as being "cock", are not considered acceptable.
[1] https://dictionary.cambridge.org/dictionary/english/cox
Other than that: fantastic work.
their loss.
[1] http://www.cox.com/
Thanks also to you for sharing a couple well-established alternatives.
So if you ask this question, you might as well ask why system calls are not more expansive in their capabilities.
I think there's a reason, system calls are much simpler. They are building bricks. If you want to layer something complex on top, you're free to do so.
About your suggestions, ACE's documentation is particularly bad. I wouldn't recommend it to anyone.
libcox is for when your existing code would do something like system("uname") or system("ls") (... except not even with system(), with popen() or something), and you want it portable to Windows.
I really like the concept though. Took me to figure out what the concept is because "system calls" doesn't mean "shell commands" to me, but having figured that out, operating on shell commands has a lot of things going for it.
That'd be my guess, at least, but, i guess, single quotes aren't valid characters for zDir.
(In the absence of this, and certainly in the absence of official docs/examples that do the right thing, that's a security vulnerability waiting to happen.)
[1]: http://libcox.net/c_api/libcox_register_command.html