awesome-client.c manipulates the string returned from getenv("DISPLAY"),
removing anything after the first dot ('.'). awesome.c however has no
such thing, leading to awesome listening on a '...0.0' socket. Anyway,
this seems like something that should be in get_client_addr as opposed
to hardwired in awesome-client.c or awesome.c. The attached patch moves
it into awesome-client-common.c:get_client_addr() and teaches
awesome-client.c of the change.
Hi there.
awesome-client is now linked against the whole hog of x-related libs
that awesome depends on. These get pulled in by awesome-client using the
same LDFLAGS as awesome. Removing x-related libs from the LDFLAGS for
awesome-client is only half of the story, as it also depends on util.c
which now has a couple of x-related functions. The attached patch also
splits these functions into a separate xutil.{c,h} file pair and teaches
the rest of the files to use them. Apart from the small difference in
file size (I see a 3-3.5% decrease in file size, both for a stripped and
a non-stripped awesome-client binary), this should also somewhat reduce
the startup time (since awesome-client won't have to map all of these
libraries).
Cheers...
\n\n
As discussed on #awesome, the attached patch makes awesome-client exit
with a meaningful value (i.e. that of errno) when it encounters an
error. Since the most frequent error with awesome-client is a mismatch
in the socket path, there is an explicit case for ENOENT errors. I
thought of adding a matching fprintf in awesome.c, but you can tell what
socket awesome is listening on by looking at what ~/.awesome_ctl.* file
you have.
CAVEAT: Exiting on error may break setups such as:
while true; do
echo "some text"
done | /path/to/awesome-client
which relied on awesome-client continuing to send to the given socket
(although failing) until EOF was encountered on stdin.
Nikos Ntarmos
Arnaud Fontaine
Julien Danjou
MATSUU Takuto
Toshihide Shimayama