/* [ʞ] bgrd.c
* ~ lexi hale <lexi@hale.su>
* $ cc -Ofast bgread.c -lutil -obgrd
* © affero general public license 3.0
* i am angry beyond words that this program had to
* be written
*
* bgrd "background read" is a tool for launching an
* application and retrieving the first line of output.
* this is a nontrivial task for a number of reasons,
* all of which are incredibly stupid, however, most
* saliently: buffered io.
*
* the suckmore web browser `surf` has an option '-x'
* which is intended to print the X window id of the
* window it opens, so it can be captured and used in
* scripts. so far so good.
*
* except unix has two distinctly different concepts
* of IO. there's POSIX IO, and then there's libc IO.
*
* POSIX IO uses the shit in <fcntl.h> and <unistd.h>;
* syscalls like read(2), write(2), and pipe(2) - the
* good, simple shit God made unix for. this is really
* bare-metal; these are basically C wrappers over
* kernel syscalls. POSIX IO uses plain old ints as
* file descriptors, and it doesn't fuck around. when
* you say "write," god dammit, it WRITES.
*
* libc is a very different beast. libc has opinions.
* libc has abstractions. libc has its own entire
* goddamn DSL by which to specify format strings,
* because apparently someone felt called to reinvent
* FORTRAN except worse. printf(), you know, the first
* function they ever teach you in C 101? (more like CS
* 403 these days, but aghhh) it's actually a heinously
* complicated, dangerous, slow, insecure mess that drags
* a ridiculous amount of background bullshit into the
* frame. such as BUFFERING.
*
* libc, you see, is too good to just wrap write() and
* read(). no, it also has to decide when to SEND them.
* this is responsible for that behavior every c coder
* trips over eventually - you know the one, where if
* you don't end your format string in '\n' it isn't
* printed, sometimes even if the program exits. this
* is not actually a POSIX thing; it's a libc thing.
*
* libc has a couple different kinds of buffering tactics
* (set with setvbuf(), a function nobody seems to know
* exists) that it uses in different circumstances.
* the printf \n gotcha behavior is what's known as
* "line buffering." however, because libc thinks it's
* fucking smart or something, it's not content to just
* pick one predictable behavior and stick to it. oh no.
*
* ever noticed how programs can seem to tell whether
* they're connected to a terminal (and thus can output
* all those fancy ansi formatting codes), or whether
* you're redirecting their stdout to a file? that's
* because there's more than one kind of pipe. the kind
* you create with pipe(2) - and the kind you create with
* openpty(2).
*
* a pty is, essentially, a kind of pipe that carries
* extra information around, the information you access
* via ioctl and termios. it's designed to imitate a TTY,
* so that a shell can create one, aim a process at it,
* and then that process can draw TUIs and shit on it.
* and some programs are designed to behave differently
* depending on whether they're hooked up to a pipe or a
* pty.
*
* libc, tragically, is among them.
*
* if libc notices it's hooked up to a pipe instead of a pty,
* it will change its default buffering strategy. newlines
* will suddenly cease flushing stdout, and libc will
* only print its buffer in one of two circumstances: the
* buffer is filled up, or the program exits.
*
* this is a problem if you are, say, trying to output a
* handle that scripts can use to control the running
* program.
*
* the `surf` developers had a couple of options. they
* could have simply broken out the POSIX headers and
* sent the X id to stdout with a call to write(2), the
* correct thing to do. they could have thrown in a call
* to setvbuf(3) to explicitly pick a buffering strategy
* compatible with their usecase, the sensibly wrong
* thing to do. they could have explicitly flushed stdout
* after printf(3)'ing to it, the dumb and error-pront
* thing to do.
*
* instead, they did *nothing.*
*
* so if you run `surf -x` from a terminal, great!
* you'll see it print the x window id first thing.
* you'll then try to capture it via any number of
* increasing desperate means, all of which will fail
* hilariously. finally, you'll spend four goddamn hours
* after midnight reading source code and manpages and
* frantically googling around and digging up unix lore
* and finally, FINALLY figure out what the batshit FUCK
* is going on, and write this goddamn utility to hack
* around the suckmore crowd's suckitude.
*
* so i figured i'd save you some time.
*
* i am probably going to submit a PR eventually because
* holy hell this is just so monumentally bozotic.
*
* in the mean time, you can use this extremely
* no-bullshit wrapper by running `set surfwin (bgrd
* (which surf) surf -x <params>` or whatever the bash
* equivalent is and it will immediately launch surf in
* the background, printing the X window and exiting
* as soon as it hits a newline. it should be adaptable
* to similar scenarios if you find yourself dealing with
* similarly broken software tho.
*
* in conclusion, read lenin. */
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <stdint.h>
#include <pty.h>
int main(int argc, char** argv) {
// pipe fd handles
int wr, rd;
// populate the pipe
openpty(&wr, &rd, NULL, NULL, NULL);
// note ptys and pipes use basically the same
// interface; you can use one as a drop-in
// replacement for the other, tho the creation
// function syntax is a bit different.
if(fork()) goto master;
else goto child;
master: {
close(wr);
char buf[256]; size_t sz;
while(sz = read(rd, buf, 255)) {
buf[sz]=0;
for (size_t i=0;i<sz;++i) {
if (buf[i] == '\n') {
write(1,buf,i);
// got what we came for, time to blow
// this popsicle stand.
goto leave; // bite me, dijkstra
}
}
write(1,buf,sz);
}
}
leave: {
close(rd);
return 0;
}
child: {
close(rd);
// redirect stdout and stderr to our pty master
dup2(wr, 1);
dup2(wr, 2);
close(wr);
execv(argv[1],argv+2);
return 1; // THIS SHOULD NEVER HAPPEN
}
}