On some host system configurations, I’ve found that Docker containers that use the host’s X11 session to present a user interface, terminate with a dreaded:
Can't connect to X11 window server using 'unix:0.0' as the value of the DISPLAY variable
Seems that on these systems, access needs to be granted to users making connections to the X11 host. This is done using the xhost command, like so.
$ sudo xhost +
Your docker containers shouldn’t have any issues now.
A word of warning is given in the man page, when using this tool however:
In the usual case, ldd invokes the standard dynamic linker (see ld.so(8)) with the LD_TRACE_LOADED_OBJECTS environment variable set to 1, which causes the linker to display the library dependencies. Be aware, however, that n some circumstances, some versions of ldd may attempt to obtain the dependency information by directly executing the program. Thus, you should never employ ldd on an untrusted executable, since this may result in the execution of arbitrary code.
The suggestion from this manual page is to use the objdump command, as this won’t invoke anything extra to find the dependencies:
$ objdump -p program | grep NEEDED
For the same program, this gives me the following output:
The GNU Readline Library is a really useful library for creating single-line input style programs at the console. From the introduction:
The GNU Readline library provides a set of functions for use by applications that allow users to edit command lines as they are typed in.
There’s some really nice stuff added on top though. Being able to use emacs or vi editing modes are just some of them. This allows you to provide your users with consistent key bindings to what they use in their text editor.
Modules
Taking a look on your file system, you can find readline’s header files under /usr/include/readline/.
Taking a really brief tour of these headers, history.h provides the library with the ability to recount previously entered text blocks. This sort of behavior can be observed when using bash; pressing the up and down buttons allow you to scroll through previous commands. keymaps.h provides the library with the mapping abstraction to make your readline-based application behave like vi or emacs or any custom implemented map you wish.
Reading lines
The library’s purpose is to read lines of text. The function that you’ll use to do this is called readline. A simple example of this would be:
#include<stdlib.h>
#include<stdio.h>
#include<readline/readline.h>intmain(){char*name;name=readline("What is your name? ");printf("Hello %s!\n",name);free(name);return0;}
Note! The string that you’re given back from readline is allocated using malloc, so it’s your responsibility to ensure that the memory is freed using free.
Resulting with the following execution:
$ ./hello
What is your name? Joe
Hello Joe!
Historical and auto complete
You can quickly give your readline program a historical account of previously entered lines with the following sort of structure:
while(running){filename=readline("Enter a filename: ");// add the data to the input historyadd_history(filename);// perform some work on "filename"free(filename);}
The add_history method is available from the readline/history.h header.
Allowing your line edit to include file path auto completion is pretty easy also. You can bind this behavior to any key that you’d like; we’re all pretty used to the tab character doing this work for us though:
libxml2 is a C library that provides XML handling capabilities to your applications. It supports an extensive range of standards and specifications common in the XML community. It’s also a highly ported library between platforms and architectures making it a good choice when your application needs to move.
For a deeper-dive into the libxml2 library, I suggest a read through on their tutorial.
Building applications
The xml2-config program allows your Makefiles to remain relatively noise-free. To build any applications against libxml2, you just need the --cflags and --libs switches to compile and link respectively:
$ gcc `xml2-config --cflags--libs` prog.c -o prog
Writing programs
Rather than re-produce them all, I’ve just got a link to the set of examples on the libxml2 site.
There are a handful of really useful tools for dealing with character encoding. In today’s post, I’ll take you through identifying this characteristic and changing it.
What is Character Encoding?
Wikipedia has the most comprehensive breakdown on the topic. The simplest way to look at it though is that a character encoding assigns a code to each character in an alphabet.
Code
Encoding
Character
65
ASCII
A
U+2776
UNICODE
❶
0xd8
LATIN4
Ø
The unicode and latin4 characters don’t exist within the ASCII character space, therefore those characters simple don’t translate and can’t be encoded by ASCII.
Querying files
To determine what encoding is being used with a file, you can use the file unix utility.
$ echo"Here is some text"> a-test-file
$ file a-test-file
a-test-file: ASCII text
Using the -i switch, we can turn the ASCII text output into a mime string which can yield some more information:
Remember, these bytes are not only in hex; they’re also flipped according to how the string is written. Let’s take the first two bytes 6548:
0x65 = e
0x48 = H
We’re using an 8-bit encoding, our string has 17 characters plus a newline (18). Easy.
Changing the encoding of a file
We can use iconv to transition our text file from one encoding to another. We specify its current encoding with the -f switch and the encoding that we want to convert it to using the -t switch.
The file also starts with a BOM of feff which was unseen in the ASCII counterpart.
What encodings are supported
You can list the known coded character sets with iconv as well with the --list switch. This will dump a massive list of encodings (and aliases) that you can use.