On Tue, Jun 20, 2017 at 11:49:56AM -0400, tetsu...@scope-eye.net wrote: [...] > So implementing Unix Domain Sockets in the shell would give you the > ability to connect to existing services on the machine that use named > sockets for control (systemd, dbus, cups, etc.) or you could use the > feature to implement new services and connect to them with shell > scripts, or just use them to connect different scripts and programs > together for various forms of IPC.
AFAICT, dbus uses a binary wire protocol [1], so we will also need a new builtin that provides some of the functionality to read binary data as described by Pierre in [2]. My point: in order to do something useful with UNIX domain sockets, which in my experience are usually binary wire protocols, bash would need a robust mechanism to read, manipulate, and write binary strings. Why not implement both as loadable builtins? > (As a side note, the shell somewhat defines the user's operating > environment. I think that not providing a feature because of a > perception that "no one uses it" becomes somewhat self-fulfilling: No > one writes shell-friendly Unix Domain Socket servers because the shell > doesn't support connecting to them, and the definition of what's > "shell-friendly" is rather narrow.) I didn't claim that this feature is not desired or useful. I just claimed that it seems to be targetted to a very small set of users. And if this is correct, it might be better to provide this functionality as a loadable builtin. I'm happy to be proven wrong here. > Though even with the benefits of redirection, personally I oppose the > idea of spoofing more fake devices in /dev. (The shell spoofs some > stuff in /dev already, and it's all long-established at this > point... But I don't think more such fake devices should be added.) > In this patch, spoofing /dev grants us the ability to specify a single > socket option. It's not a great way to set options, though. What if > the API changed, and we suddenly wanted to be able to specify two > options? Specifying options as command arguments is both clearer and > more flexible. I agree. > I've given some thought to how the two approaches could be combined: > use a command to open a file descriptor, but bind the file > descriptor's lifetime to a redirection. For instance, consider this > concept for a new redirection syntax: I'm more in favor of a shell builtin, with the user having to explicity close the descriptors, instead of bloating the parser. It is incredibly complex as it is now. Please don't add more complexity. [1] https://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-marshaling [2] https://lists.gnu.org/archive/html/bug-bash/2017-06/msg00096.html P.S. I enjoy reading your emails, but please, get a better MUA! -- Eduardo Bustamante https://dualbus.me/
