5 ms·
> What about UNIX shells that allow to call public functions in dynamic libraries as if they were shell commands? dlcall > Or interact with running applicatio
by vasilia 8y ago
> What about UNIX shells that allow to call public functions in dynamic libraries as if they were shell commands?
dlcall
> Or interact with running applications using the OS APIs like Powershell allows with WMI, COM, OLE Automation and .NET?
Depends what you need. You can use nc -U /var/run/socket or pipes with expect. If you have root permissions you can use gdb scripting/ebpf to communicate with user-space/kernel-space data of your application.
> Yes, there is DBUS, but isn't really integrated across the whole stack.
DBUS is a bus for desktops/mobile. I never saw that someone use it for server applications. The main idea(after KISS) of the Linux shell is that if you can't write something in awk it will be better to use python. Actually, in the Linux world, GRPC/REST is more common than OS-level API.
- pjmlp 8y agoSo a couple of Linuxisms not portable across UNIX, which was my point.
- laumars 8y agoNope. Your point was to argue personal preference as fact rather than simply accepting that some people like apples and others prefer oranges. I get so utterly sick of stupid arguments where people compare their tools and then proceed to makes claims that one is objectively better than another when it’s clearly just a matter of personal taste
- vasilia 8y agoUnix sockets and pipes are portable across all Unix(POSIX, because Linux is not Unix, but OS X is). Furthermore Unix sockets and pipes backwards compatible to 4.4BSD Unix or older OS. Actually, this comparison is not correct. Windows and Unix have a different philosophy of kernel<->user level interaction. While Windows tries to add all functionality to the kernel, Unix does this on user level. Remember the KISS principle. So If you comfortable with Windows OS level API it's good for you, but for Unix world, it's not necessary to do something because we already have a different inter-process communication approach.
- pjmlp 8y agoWhich is why UNIX shells are a poor man's REPL quite far from what a Xerox inspired user/developer interaction aspired to achieve. Pipe based interactions work properly only across CLI based applications, and even then the applications need to be explicitly written to accept and parse the data. PowerShell or other Xerox inspired shells don't need kernel support to achieve their workflows.
- vasilia 8y ago> Which is why UNIX shells are a poor man's REPL quite far from what a Xerox inspired user/developer interaction aspired to achieve. Unix shells are quite good for their purpose. It's not a full-featured programming language. Can you explain what is "poor man's REPL"? > Pipe based interactions work properly only across CLI based applications Yes. If you want to find something in logs or looking at any other text data pipes is a good solution. In any other case(like binary data) it will be better to choose GRPC(or any other RPC). I never have seen GUI apps on servers, sorry. > PowerShell or other Xerox inspired shells don't need kernel support to achieve their workflows. Good for them :)
- pjmlp 8y agoA poor man's REPL is a shell that fails short of everything that was possible to do across the OS infrastructure with what Lisp/Smalltalk/Oberon/XDE/Cedar REPLs allowed to do. An approximation of it would be to have a shell that is a Jupyter netbook with access to the whole set of OS APIs, shared libraries and applications, with the ability to jump into the debugger at any given step of the pipeline, and redo the current step. I bet you saw GUI apps on UNIX workstations, though. Then again, maybe Steve Jobs was right after all. https://www.usenix.org/blog/vault-steve-jobs-keynotes-1987-usenix-atc https://www.usenix.org/blog/vault-steve-jobs-keynotes-1987-u... https://www.cake.co/conversations/rZXhqtP/that-time-i-had-steve-jobs-keynote-at-unix-expo https://www.cake.co/conversations/rZXhqtP/that-time-i-had-st...
- vasilia 8y ago