I respectfully disagree - if you don’t want open() to block on you, the /dev/cu device is to go-to device. Most of the terminal programs default to the cu device also. IN fact that post you link to says the same thing, /dev/tty blocks. That’s my experience also.
> On 9 Jun 2015, at 09:01, Jack Brindle <[email protected]> wrote: > > Actually it is probably the other way. The cu (call unix) device was > primarily for UUCP communications. The tty port is mostly used these days. > Both do the exact same thing, it is > the defaults when they are opened that are different. You should immediately > set the port for whatever handshaking and control you need after opening > which tends to negate the defaults and give you the desired environment. > > See: http://lists.apple.com/archives/darwin-dev/2009/Nov/msg00099.html > <http://lists.apple.com/archives/darwin-dev/2009/Nov/msg00099.html> > for some interesting discussion. > > - Jack > >> On Jun 8, 2015, at 5:54 PM, Carl Hoefs <[email protected] >> <mailto:[email protected]>> wrote: >> >> >>> On Jun 8, 2015, at 5:25 PM, Roland King <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> The difference between the tty device and the cu device is that ttys were >>> traditionally used to connect a terminal to, so opening a tty should block >>> until the device on the other end raises DTR (ie you turn it on). getty >>> opens tty devices and blocks in this way. The cu devices were designed for >>> callups where you needed to connect to say a modem first, then dial, and >>> only when the connection was established does DTR go high; so open doesn’t >>> block. >>> >> Okay, that sounds like in general /dev/cu would almost always be called for >> (unless you’re doing actual terminal or modem work!) The way USB/serial >> devices seem to work on OS X is that they don’t even show up with a mount >> point unless they’re ready to communicate (perhaps at some level simulating >> DTR high?). In practice it hasn’t made any difference which I’ve used, cu or >> tty, but this info is good to know regardless. >> -Carl >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Usb mailing list ([email protected] <mailto:[email protected]>) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/usb/jackbrindle%40me.com >> <https://lists.apple.com/mailman/options/usb/jackbrindle%40me.com> >> >> This email sent to [email protected] >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Usb mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/usb/archive%40mail-archive.com This email sent to [email protected]
