I take it you're running that from a raw text console? Only things that logged in through your X server will have access to X these days. Yes. That's literally all there is to it (in userspace, anyway). BASH always uses direct system calls. read() and write() are direct system calls.

The shell doesn't care whether it's in a GUI or a real terminal. The kernel does all the legwork and makes them act the same.

IOW, what changes is what these system calls talk to. In a graphical terminal, the shell is probably talking to a virtual terminal device. That's something like an anonymous pipe -- user programs can create and destroy them -- but they have terminal behaviors added on. Also, they're bidirectional. Writing Ctrl-C into it causes SIGINT to anything belonging to it, etc, etc. The graphical program(i.e. xterm) reads what the program writes and draws it on the screen, and writes what you type into the keyboard into the terminal device for the shell to read and process.

A raw text terminal is a real terminal. It physically exists. Nothing had to create it, it was there all along as far as userspace is concerned, and it can't be destroyed. The kernel does it all. No intermediate program draws on the screen.

For that matter, a VGA terminal is pretty close to actually being a raw terminal. When you type 'a', the kernel doesn't need to do much more than stick the raw byte 'a' in video memory. Fancy framebuffer terminals are a bit more complicated(and slower), though still handled in the kernel. They're complicated and finicky enough that I'm not convinced they really belong in the kernel either.

Another kind of 'real' terminal is a serial port. Technically all terminal devices, real and virtual, act like serial ports. Try 'stty' in a GUI login -- it'll report a baud rate and everything! The baud rate does nothing in anything that's not a real serial port of course, but most of the other myriad options can still be configured to your liking.