"Every programmer occasionally, when nobody's home, turns off the lights, pours a glass of scotch, puts on some light German electronica, and opens up a file on their computer. It's a different file for every programmer. Sometimes they wrote it, sometimes they found it and knew they had to save it. They read over the lines, and weep at their beauty, then the tears turn bitter as they remember the rest of the files and the inevitable collapse of all that is good and true in the world."
Laphroaig, if you will.
"The only reason coders' computers work better than non-coders' computers is coders know computers are schizophrenic little children with auto-immune diseases and we don't beat them when they're bad."
"He told me that Germany’s battlefield telephone lines used sheathed-wire pairs in clamshell enclosures. A small lever energized a machined, cam-operated mechanism that smoothly slid the connector halves into engagement."
The problem:
echo "foo" | ncat -u <ip> <port>
closes before printing any return value from the (UDP, in this case) server.
There are various solutions proposed. The -q or -Q options don't exist on my system. Using echo -n doesn't help. I didn't try to do a mkfifo. The quick and dirty way worked best (adjust delay based on latency):
1 | (echo "foo" && sleep 0.1) | ncat -u <ip> <port>
|
Installing libftdi on a mac is easy these days.
123 | $ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
$ brew install libusb
$ brew install libftdi
|
But then you write a program using libftdi, and surprise surprise, it won't let your program open the FTDI device. Something like:
FTDI USB open error: unable to claim usb device. Make sure the default FTDI driver is not in use (-t)
So we can check which FTDI kernel extensions are loaded using
, and if there are any, on a modern system, it'll be AppleUSBFTDI. It can be unloaded easily:
sudo kextunload -bundle-id com.apple.driver.AppleUSBFTDI
And if you're lucky, you can now run your programs against libftdi with no issue. When you're done,
kextload replacing
kextunload in the command above re-loads the driver.
However, you may face a seemingly impossible problem: you unload the kext, you try to run your program, and you get the same exact error. Unplugging and replugging the device doesn't help. It clearly enumerates - it's visible when you do
system_profiler SPUSBDataType
- yet you can't take it!
If this happens, try running
again; you'll likely see that the legacy FTDI driver -
com.FTDI.driver.FTDIUSBSerialDriver - is now present! Once you unload
this too, re-run your code, and it should be able to talk to the FTDI device.
Note: Originally written 11/4/2015, updated 5/4/2021 to note Homebrew's new installer.