- Tiny tiny font in Outlook for Mac Hi all, In Outlook for Mac, all is normal when reading mail. However, when composing mail, the font is micro sized, too small to read. When I send such an email, it reads perfectly normal. The problem seemed to start when I attached a link to a large movie file to an email.
- Testing conducted by Apple in October 2020 using preproduction Mac mini systems with Apple M1 chip, and production 3.6GHz quad‑core Intel Core i3‑based Mac mini systems, all configured with 16GB of RAM and 2TB SSD. Open source project built with prerelease Xcode 12.2 with Apple Clang 12.0.0, Ninja 1.10.0.git, and CMake 3.16.5.
- A Happy Mac is the normal bootup (startup) icon of an Apple Macintosh computer running older versions of the Mac operating system.It was designed by Susan Kare in the 1980s, drawing inspiration from the design of the Compact Macintosh series and from the Batman character Two-Face.
- Sep 06, 2011 I just picked up my first Arduino Mega 2560 the other day. Hooked it up to my Mac Pro and made my first sketch - basically a blinking pattern with the onboard pin 13 LED (tinkered with the simple Blink example a bit). Today, I go to tinker with it some more, and the long list of serial ports is gone, and only 4 bluetooth options are there (cu.Bluetooth-Modem, cu.Bluetooth-PDA-Sync, tty.
By Bless Hackintosh Malang Jawa Timur.
| Click here to return to the 'Use minicom as a serial-interface terminal application' hint |
Won't build in 10.2.8 - which is too bad because the fink version has trouble with my eMac's modem. Always takes a couple tries before it can talk to the modem. Then it works flawlessly.
Anybody else seen this behaviour? I've been living with it for a year or so now.
Greg Shenaut
In the past minicom haws had numerous security vulnerabilities, so if past experience is any indication I would continue to use Kermit. Besides kermit has a ton of very powerful features. (Like you can use kermit between a HP48 calculator.)
I'm curious: what are serial interfaces? What's an example or two of the things you are talking about?
I'm curious, but I imagine this might be useful if it's what I think it is. A coworker manages a digital closed-circuit television system that has something to do with RS-232, I hear.
---
--
osxpounder
Greg Shenaut
The open source 'screen' command is pre-installed in the Mac OS X.
Solaris users will recall the 'tip' command. I use 'screen' and a
USB-serial adapter when I need quick-and-dirty terminal emulation
via a serial port.
screen man page:
screen -r [[pid.]tty[.host]]
screen -r sessionowner/[[pid.]tty[.host]]
DESCRIPTION
Screen is a full-screen window manager that multiplexes a
physical terminal between several processes (typically
interactive shells). Each virtual terminal provides the
functions of a DEC VT100 terminal and, in addition, sev-
eral control functions from the ISO 6492 (ECMA 48, ANSI
The spirit of tlaloc mac os. X3.64) and ISO 2022 standards (e.g. insert/delete line and
support for multiple character sets). There is a scroll-
back history buffer for each virtual terminal and a copy-
and-paste mechanism that allows moving text regions
between windows.
clip
For the curious - the FreeBSD tip(1) source builds and runs on MacOSX as is - just remove the FreeBSD macros `__FBSDID($FREEBSD$);' and use bsdmake(1). To attach to the modem, use `cu -l /dev/tty.modem'.
I would absolutely love to recover my old cu utility, but I searched through the FreeBSD ports database and they don't have a specific 'tip' port. Could you give us more details on how to get tip or cu to work on OSX (where to find the source, what to change in the code to get it to compile it, ect.).
I did try to compile UUCP a while back but I was never able to squeeze a binary out of the source code.
Thanks for the 'TIP'
CU
;-)
I should not have alluded to 'tip' in Solaris. it confused folks.
The command that's pre-installed in Jaguar/Panther is 'screen'
(refer to the 'screen' man pages via the terminal).
I'll leave comments about 'cu' to someone else.
Could you please give the exact syntax of the screen-command you use to connect to tty.modem and to your USB-Serial-Adapter.
---
Jean-Claude Eischen
Swiss Federal Institute of Technology
Zurich - Switzerland
Thank you!!! I've been trying to figure out how to get tip/cu finctionality out of OSX. I was using zterm, but it crashes hard, and I can't kill it, even with a 'kill -9' I have a soekris Net4801 that I would like to connect to via a IOGear USB-Serial adapter. This did the trick!
FYI, the command was:
screen /dev/tty.usbserial (depends on the device your driver creates)
-Andy
I just compiled minicom on an XServe. Here are a few things to be aware of re: the serial port.
1) Just like any cisco router or HP switch, etc, the XServe is configured to listen with a secure terminal on the serial port, for config purposes. Disable this before trying to use the serial port for other purposes.
You might *think* of editing /etc/ttys, but you actually want to edit /System/Library/StartupItems/SerialTerminalSupport/SerialTerminalSupport -- and edit the line halfway through to say,
ENABLE_SERIAL_TERMINAL=$FALSE
Once this is done, it's easiest to just reboot the machine.
2) As mentioned above, the serial port is /dev/tty.serial. Here are some of the defaults I compiled into the program:
./configure --enable-dfl-port=/dev/tty.serial --enable-lock-dir=/var/spool/lock --enable-dfl-baud=9600
(of course, that's because my application is to talk to a device at 9600N81, YMMV.)
3) Notice the lock dir mentioned above. There is no /usr/spool/uucp, or /var/lock, as mentioned in the man page. That's why I compiled it with /var/spool/lock instead. I also ended up modifying the permissions on the lock directory, but there's probably a better way to do that. Again, just FWIW.
Hope this is helpful to someone.
One of two things is generally meant by this, either using a Mac as the interface to a serial device (accomplished by running a terminal emulator program on the Mac), or using another machine to connect to the Mac over serial and accessing the shell provided by the Mac. This page is dedicated to the latter.
I first tried googling around, and I encountered a few references to this issue on various Mac forums. Many were quite old, and it appears that the process has gotten more difficult with more recent versions of OS X (at least Snow Leopard 10.5+). People have generally had more success with the Xserve OS X server versions. I was working with 10.6, non-server edition. The technique described here has been reported to work at least as recently as 10.10.4.
For completeness, here are some links to several of the sites I encountered, which should give you the basic idea of the problem:
Getting a serial port
The first step is to get an RS232 serial port on your Mac, which hasn't been built-in for a long, long time. You probably want a USB to serial converter, of which there are a variety. Given variability in driver quality and compatibility, you may want to try a few models and driver implementation. For instance, two common chips include the FTDI series (official driver here) and the Prolific PL2303 chipset (open source driver here, closed source driver here). Of the two, I found the open source PL2303 driver to be slow and observed occasional data corruption (I did not try the closed source driver but heard worse things). I have found FTDI devices to perform more consistently.
Mac OS X 10.9 and below
These versions do not come with drivers for any USB to serial converter of which I am aware. You will need to install a third-party driver, e.g. from one of the above links.Mac OS X 10.10 and above
Starting with 10.10, a driver for at least FTDI-based converters now ships with the OS. Drivers for other converters may also be present, but I have not used them.
If you are lucky enough to have a converter identifying itself using one of the common FTDI USB product IDs, then the serial device will simply appear. If not, you will have to alter the expected device ID in the driver configuration. If you encounter strange issues of any kind with the built-in driver, try the official FTDI driver as well. Supposedly, the driver priority of the built-in driver is set so that installing the official driver will override it without causing any conflicts, however I have not conclusively verified this. For an example of how to alter the device ID or disable the built-in driver (follow just step 1), see this blog post. For official documentation on manipulating the FTDI driver or uninstalling it, see FTDI Application Note 134.
In the process of doing this myself, I learned a bit about the kernel extension (of which these drivers are each an instance) system in OS X. The basic idea is that each has a [drivername].kext directory somewhere under /System/Library/Extensions or /Library/Extensions, which if removed or renamed to not end with .kext (e.g. by switching .kext with .disabled) will prevent the driver from being loaded in the future. For an immediate load or unload, run kextload [path to .kext directory] or kextunload [path to .kext directory] as root. To see the list of currently installed extensions, run kextstat (e.g. | grep -i ftdi). After re-enabling a driver, the driver may not reload even after the next reboot because a separate cache of kernel extensions is kept to speed up enumeration on boot. This can be manipulated directly by the kextcache program, or more easily by simply running touch /System/Library/Extensions (which updates its timestamp to the current time) so that the cache is rebuilt on next boot.
Testing your serial port
If you have this working, a new device file should show up in /dev. Run ls /dev/tty.* to see what yours is showing up as. The next step is to test the serial port using some sort of terminal emulation program. I used goSerial, which happened to be the first one I found. It worked fine for my purposes, but better ones may exist.
Getting a getty running
In the Unix world, getty is the program that presents a login prompt. In earlier versions of Mac OS, one could add the appropriate line to /etc/ttys and have a prompt appear on a serial port. It appears that as of 10.6 (and possibly somewhat earlier), this is no longer possible.
Instead, I found that creating a script to spawn the getty that is run by launchd does the trick. Note that running the getty on the command line appears to fail because the login_tty Rainbow riches slot. syscall can only be invoked by the init process (which on Mac OS is launchd). I therefore created a file called serialconsole.plist (name it as you wish) in /Library/LaunchDaemons/ containing the following:
Note that first bit sets the daemon name, the second bit sets the program arguments (one 'string' per argument), and the last bit (keepalive) instructs launchd to restart the daemon when it exits (eg, the user logs out of the console). The first program argument is the getty program to execute, the second is the relevant line in /etc/gettytab that defines the desired serial port configuration (in this case the typical 115200 baud, 8 data bits, no parity, 1 stop bit; '8N1'), and the third argument to getty must be the name of the serial port device in /dev https://bestyload820.weebly.com/bounce-itch-lensj-taengyi-mac-os.html. , which for the two devices I had were one of the two listed. As noted later, the 'cu.' version of the serial port rather than the 'tty.' version may need to be used. Initially, this was reported in only some cases but seems to be the norm as of 10.10
Lic. soledad d. amor mac os. Using the program launchctl, you can manually reload these configuration files and restart daemons. Here are some self-explanatory commands you might use, of which only the first two should be necessary to start the getty manually after creating the configuration file above.
Of course, rebooting should also work if you're lazy. Super kittens mac os. Note that in my case, the usb serial device appears in /devafter launchd attempts to run the getty, causing an error message to be logged to this effect in /var/log/system.log. However, the next time it attempts to restart it (within a minute or so), it should succeed. Check that log file for other errors.
As of 10.10, launchctl load and launchctl unload are considered legacy (but still supported for now), and a new scheme should be used. Supposedly the following is the preferred sequence:
However, in my case these did not seem to be sufficient, whereas launchctl load did the trick. Let me know what seems to work for you.
Automatic login
For my application, I wanted a shell prompt to be immediately presented, without asking for username or password or displaying the login messages (last time logged in, new mail, etc.). To accomplish this, I needed to add the following entry to /etc/gettytab:
as well as change the std.115200 to custom.115200 in the serialconsole.plist file. Note that this changes the login banner message to just a carriage return and newline, automatically logs in as user , and spawns the login program /usr/bin/quietlogin.sh, which is a script I wrote (that wraps the default /usr/bin/login) containing the following:
The reason this additional script was required was due to stupidity on the part of the login program that I observed. First, it seems to ignore the presence of a .hushlogin in the user's home directory requesting that no welcome messages be printed. Further, the -f argument passed to login must be first on the command line (before a '-q' which forces quite mode). (See the login man page for some of idea of what I'm talking about.) The above script performs this necessary munging.
Hiccups
Things not working? I'm not a mac user myself, so I can't offer too much help with debugging. Serial stuff in Mac OS appears to be of little interest to Apple, so things may change and break with each new version. If you learn something new during your own tinkering, let me know and I'll post it here. My email address may be derived from the URL of this document.
Tiny Tty Mac Os Download
If you're using the 'tty' device and it's not working, definitely try the 'cu' device (replacing tty. with cu., thus using the 'cu' call-out device instead of 'tty' terminal device). This was first reported when using somewhat unusual hardware as a Hackintosh, but more recent reports suggest this is now the norm. Perhaps it depends on the usb-to-serial driver used? I'm seeking input on this, so send me email with datapoints.
Other thoughts
Won't build in 10.2.8 - which is too bad because the fink version has trouble with my eMac's modem. Always takes a couple tries before it can talk to the modem. Then it works flawlessly.
Anybody else seen this behaviour? I've been living with it for a year or so now.
Greg Shenaut
In the past minicom haws had numerous security vulnerabilities, so if past experience is any indication I would continue to use Kermit. Besides kermit has a ton of very powerful features. (Like you can use kermit between a HP48 calculator.)
I'm curious: what are serial interfaces? What's an example or two of the things you are talking about?
I'm curious, but I imagine this might be useful if it's what I think it is. A coworker manages a digital closed-circuit television system that has something to do with RS-232, I hear.
---
--
osxpounder
Greg Shenaut
The open source 'screen' command is pre-installed in the Mac OS X.
Solaris users will recall the 'tip' command. I use 'screen' and a
USB-serial adapter when I need quick-and-dirty terminal emulation
via a serial port.
screen man page:
screen -r [[pid.]tty[.host]]
screen -r sessionowner/[[pid.]tty[.host]]
DESCRIPTION
Screen is a full-screen window manager that multiplexes a
physical terminal between several processes (typically
interactive shells). Each virtual terminal provides the
functions of a DEC VT100 terminal and, in addition, sev-
eral control functions from the ISO 6492 (ECMA 48, ANSI
The spirit of tlaloc mac os. X3.64) and ISO 2022 standards (e.g. insert/delete line and
support for multiple character sets). There is a scroll-
back history buffer for each virtual terminal and a copy-
and-paste mechanism that allows moving text regions
between windows.
clip
For the curious - the FreeBSD tip(1) source builds and runs on MacOSX as is - just remove the FreeBSD macros `__FBSDID($FREEBSD$);' and use bsdmake(1). To attach to the modem, use `cu -l /dev/tty.modem'.
I would absolutely love to recover my old cu utility, but I searched through the FreeBSD ports database and they don't have a specific 'tip' port. Could you give us more details on how to get tip or cu to work on OSX (where to find the source, what to change in the code to get it to compile it, ect.).
I did try to compile UUCP a while back but I was never able to squeeze a binary out of the source code.
Thanks for the 'TIP'
CU
;-)
I should not have alluded to 'tip' in Solaris. it confused folks.
The command that's pre-installed in Jaguar/Panther is 'screen'
(refer to the 'screen' man pages via the terminal).
I'll leave comments about 'cu' to someone else.
Could you please give the exact syntax of the screen-command you use to connect to tty.modem and to your USB-Serial-Adapter.
---
Jean-Claude Eischen
Swiss Federal Institute of Technology
Zurich - Switzerland
Thank you!!! I've been trying to figure out how to get tip/cu finctionality out of OSX. I was using zterm, but it crashes hard, and I can't kill it, even with a 'kill -9' I have a soekris Net4801 that I would like to connect to via a IOGear USB-Serial adapter. This did the trick!
FYI, the command was:
screen /dev/tty.usbserial (depends on the device your driver creates)
-Andy
I just compiled minicom on an XServe. Here are a few things to be aware of re: the serial port.
1) Just like any cisco router or HP switch, etc, the XServe is configured to listen with a secure terminal on the serial port, for config purposes. Disable this before trying to use the serial port for other purposes.
You might *think* of editing /etc/ttys, but you actually want to edit /System/Library/StartupItems/SerialTerminalSupport/SerialTerminalSupport -- and edit the line halfway through to say,
ENABLE_SERIAL_TERMINAL=$FALSE
Once this is done, it's easiest to just reboot the machine.
2) As mentioned above, the serial port is /dev/tty.serial. Here are some of the defaults I compiled into the program:
./configure --enable-dfl-port=/dev/tty.serial --enable-lock-dir=/var/spool/lock --enable-dfl-baud=9600
(of course, that's because my application is to talk to a device at 9600N81, YMMV.)
3) Notice the lock dir mentioned above. There is no /usr/spool/uucp, or /var/lock, as mentioned in the man page. That's why I compiled it with /var/spool/lock instead. I also ended up modifying the permissions on the lock directory, but there's probably a better way to do that. Again, just FWIW.
Hope this is helpful to someone.
One of two things is generally meant by this, either using a Mac as the interface to a serial device (accomplished by running a terminal emulator program on the Mac), or using another machine to connect to the Mac over serial and accessing the shell provided by the Mac. This page is dedicated to the latter.
I first tried googling around, and I encountered a few references to this issue on various Mac forums. Many were quite old, and it appears that the process has gotten more difficult with more recent versions of OS X (at least Snow Leopard 10.5+). People have generally had more success with the Xserve OS X server versions. I was working with 10.6, non-server edition. The technique described here has been reported to work at least as recently as 10.10.4.
For completeness, here are some links to several of the sites I encountered, which should give you the basic idea of the problem:
Getting a serial port
The first step is to get an RS232 serial port on your Mac, which hasn't been built-in for a long, long time. You probably want a USB to serial converter, of which there are a variety. Given variability in driver quality and compatibility, you may want to try a few models and driver implementation. For instance, two common chips include the FTDI series (official driver here) and the Prolific PL2303 chipset (open source driver here, closed source driver here). Of the two, I found the open source PL2303 driver to be slow and observed occasional data corruption (I did not try the closed source driver but heard worse things). I have found FTDI devices to perform more consistently.
Mac OS X 10.9 and below
These versions do not come with drivers for any USB to serial converter of which I am aware. You will need to install a third-party driver, e.g. from one of the above links.Mac OS X 10.10 and above
Starting with 10.10, a driver for at least FTDI-based converters now ships with the OS. Drivers for other converters may also be present, but I have not used them.
If you are lucky enough to have a converter identifying itself using one of the common FTDI USB product IDs, then the serial device will simply appear. If not, you will have to alter the expected device ID in the driver configuration. If you encounter strange issues of any kind with the built-in driver, try the official FTDI driver as well. Supposedly, the driver priority of the built-in driver is set so that installing the official driver will override it without causing any conflicts, however I have not conclusively verified this. For an example of how to alter the device ID or disable the built-in driver (follow just step 1), see this blog post. For official documentation on manipulating the FTDI driver or uninstalling it, see FTDI Application Note 134.
In the process of doing this myself, I learned a bit about the kernel extension (of which these drivers are each an instance) system in OS X. The basic idea is that each has a [drivername].kext directory somewhere under /System/Library/Extensions or /Library/Extensions, which if removed or renamed to not end with .kext (e.g. by switching .kext with .disabled) will prevent the driver from being loaded in the future. For an immediate load or unload, run kextload [path to .kext directory] or kextunload [path to .kext directory] as root. To see the list of currently installed extensions, run kextstat (e.g. | grep -i ftdi). After re-enabling a driver, the driver may not reload even after the next reboot because a separate cache of kernel extensions is kept to speed up enumeration on boot. This can be manipulated directly by the kextcache program, or more easily by simply running touch /System/Library/Extensions (which updates its timestamp to the current time) so that the cache is rebuilt on next boot.
Testing your serial port
If you have this working, a new device file should show up in /dev. Run ls /dev/tty.* to see what yours is showing up as. The next step is to test the serial port using some sort of terminal emulation program. I used goSerial, which happened to be the first one I found. It worked fine for my purposes, but better ones may exist.
Getting a getty running
In the Unix world, getty is the program that presents a login prompt. In earlier versions of Mac OS, one could add the appropriate line to /etc/ttys and have a prompt appear on a serial port. It appears that as of 10.6 (and possibly somewhat earlier), this is no longer possible.
Instead, I found that creating a script to spawn the getty that is run by launchd does the trick. Note that running the getty on the command line appears to fail because the login_tty Rainbow riches slot. syscall can only be invoked by the init process (which on Mac OS is launchd). I therefore created a file called serialconsole.plist (name it as you wish) in /Library/LaunchDaemons/ containing the following:
Note that first bit sets the daemon name, the second bit sets the program arguments (one 'string' per argument), and the last bit (keepalive) instructs launchd to restart the daemon when it exits (eg, the user logs out of the console). The first program argument is the getty program to execute, the second is the relevant line in /etc/gettytab that defines the desired serial port configuration (in this case the typical 115200 baud, 8 data bits, no parity, 1 stop bit; '8N1'), and the third argument to getty must be the name of the serial port device in /dev https://bestyload820.weebly.com/bounce-itch-lensj-taengyi-mac-os.html. , which for the two devices I had were one of the two listed. As noted later, the 'cu.' version of the serial port rather than the 'tty.' version may need to be used. Initially, this was reported in only some cases but seems to be the norm as of 10.10
Lic. soledad d. amor mac os. Using the program launchctl, you can manually reload these configuration files and restart daemons. Here are some self-explanatory commands you might use, of which only the first two should be necessary to start the getty manually after creating the configuration file above.
Of course, rebooting should also work if you're lazy. Super kittens mac os. Note that in my case, the usb serial device appears in /devafter launchd attempts to run the getty, causing an error message to be logged to this effect in /var/log/system.log. However, the next time it attempts to restart it (within a minute or so), it should succeed. Check that log file for other errors.
As of 10.10, launchctl load and launchctl unload are considered legacy (but still supported for now), and a new scheme should be used. Supposedly the following is the preferred sequence:
However, in my case these did not seem to be sufficient, whereas launchctl load did the trick. Let me know what seems to work for you.
Automatic login
For my application, I wanted a shell prompt to be immediately presented, without asking for username or password or displaying the login messages (last time logged in, new mail, etc.). To accomplish this, I needed to add the following entry to /etc/gettytab:
as well as change the std.115200 to custom.115200 in the serialconsole.plist file. Note that this changes the login banner message to just a carriage return and newline, automatically logs in as user , and spawns the login program /usr/bin/quietlogin.sh, which is a script I wrote (that wraps the default /usr/bin/login) containing the following:
The reason this additional script was required was due to stupidity on the part of the login program that I observed. First, it seems to ignore the presence of a .hushlogin in the user's home directory requesting that no welcome messages be printed. Further, the -f argument passed to login must be first on the command line (before a '-q' which forces quite mode). (See the login man page for some of idea of what I'm talking about.) The above script performs this necessary munging.
Hiccups
Things not working? I'm not a mac user myself, so I can't offer too much help with debugging. Serial stuff in Mac OS appears to be of little interest to Apple, so things may change and break with each new version. If you learn something new during your own tinkering, let me know and I'll post it here. My email address may be derived from the URL of this document.
Tiny Tty Mac Os Download
If you're using the 'tty' device and it's not working, definitely try the 'cu' device (replacing tty. with cu., thus using the 'cu' call-out device instead of 'tty' terminal device). This was first reported when using somewhat unusual hardware as a Hackintosh, but more recent reports suggest this is now the norm. Perhaps it depends on the usb-to-serial driver used? I'm seeking input on this, so send me email with datapoints.
Other thoughts
One reader suggested the possibility of using serial port emulation on a bluetooth connection as an alternative to USB-to-serial dongles. I would be curious to hear reports from anyone attempting this, particularly on behavior prior to bluetooth peering, during radio hiccups, and after reconnects (assuming the idea works at all). Before going too far down this road, do remember you can run IP over bluetooth and just use proper networking if your application permits.
Changelog
Tiny Tty Mac Os 11
- [2015-08-09] Updated for 10.10
- [2014-09-04] Example launchctl commands, confirmation still works on 10.9.4, and additional note on 'cu' device reported by an anonymous reader
- [2014-01-05] Confirmation still works on 10.9.1 and bluetooth alternative suggestion by Alex Kudlov
- [2013-01-08] Fixed missing '' after the al= in automatic login section
- [2012-01-22] Added info on 'cu' device instead of 'tty' reported by David Roach
- [2011-08-10] Fixed several since-broken links (damn you apple)
- [2010-03-20] Initial version
Last modified 8/9/2015
Tiny Tty Mac Os Catalina
