I would say that most of the Unix tools make sense for *interactive* usage, where errors caused by text interface are more immediate and apparent. The things get hairy when people try to immortalize them in shell scripts without handling any edge cases.
-
-
I think I start to see your point. They could be libraries, but I don't think there is anything fundamentally wrong with them being programs and running in separate processes. "text as interface" is imo the problem, but that is caused by how OS implements the idea of a program.
-
If they are programs, then you *also* need libraries that do the same things, for software that doesn't want to suffer from the loose coupling / resource-hogging of running separate programs to accomplish tasks. This redundancy requires more work to understand and maintain.
-
I generally see Unix programs as acceptable only for interactive usage in shell. And yes I agree that if this would be done with shell just calling existing system libraries it would be better.
-
What I'm supporting here is model of exposing atomic functionally to user which can be then combined. I agree that it would be generally better to implement it as a set of libraries.
-
lemme... *cough*... um... terribly sorry for the intrusion... but lemme give you both a heart attack: https://github.com/Apple-FOSS-Mirror/Libc/blob/2ca2ae74647714acfc18674c3114b1a5d3325d7d/gen/wordexp.c#L192 … https://opensource.apple.com/source/Libc/Libc-1044.1.2/gen/FreeBSD/wordexp.c … *runs away*
-
lollercoaster
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.