On Tue, 2017-06-20 at 23:47 -0500, Eduardo A. Bustamante López wrote:
> 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?
> >
> > 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.
>
>
> P.S. I enjoy reading your emails, but please, get a better MUA!
>
>
Certainly I'd have no objections to *also* having the ability to work with
binary data in the shell, in addition to the ability to work with unix
domain sockets. And this is absolutely the sort of thing I try to address in
the library I'm working on. But I haven't been able to figure out an
approach I'm happy with yet. Because of the way Bash variables work internally,
there has to be the textual representation stored in memory, and
there's really no provision to store anything else as part of the variable. So
effectively you store the data twice, more than doubling the storage
requirements. At that point you may as well just use a storage solution that
_merely_ doubles the storage requirements, like hexadecimal. I don't love
that kind of approach (kind of on principle I'd prefer to avoid solutions that
require dealing with a transfromed version of the data, rather than the
actual data) but it works.
As for the redirection syntax... I guess new syntax is a bit much to hope for,
but when faced with a situation like this I try to look for a solution
that will be generally useful. In this case, the discussion started with a
patch to add a new connection method to the redirection syntax. Adding one
such feature isn't a big deal. But I look at the situation and think, wouldn't
it be nice to have a more general solution that could address this
case, and future ones as well? The redirection syntax concept does that, though
the cost of adding syntax to the language is indeed not to be taken
lightly.
Generally speaking, having explored file descriptor passing functionality a bit
in the shell, it would be nice if the shell could support it a bit
better. For instance, this command in ksh + shell-pepper:
$ connect_to_socketfile ./s | recvmsg m fd
works in ksh because it's got the equivalent of "lastpipe", and because pipes
in ksh jobs are actually socket pairs, so FDs can be passed over them.
In Bash, because the pipe syntax creates a pipe and not a socketpair, the
caller must bascially create the pipeline themselves:
$ socketpair --cloexec s
$ connect_to_socketfile ./s >&${s[1]} &
$ recvmsg m fd <&${s[0]}
$ exec {s[0]}<&-
$ exec {s[1]}<&-
It makes the functionality feel much more alien. There are consequences to
ksh's choice to use socketpairs rather than pipes (for instance this breaks
/dev/fd on linux... Because the implementation of /dev/fd on Linux is kind of
dumb generally.) but it makes other Unix domain socket functionality integrate
quite nicely.
