Re: [PATCH] Unix domain socket filename redirection

[Eduardo A . Bustamante López]

On Tue, Jun 20, 2017 at 11:49:56AM -0400, tetsujin@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/