![]() So, what's the difference? Well, TTY devices are for calling into UNIX systems, whereas CU (Call-Up) devices are for calling out from them (eg, modems). You might notice that each serial device shows up twice in /dev, once as a tty.* and once as a cu.*. Note: Check your adapter works after an OS Update, as you may have to re-install the driver. Select this port name in a terminal program. This indicates the USB-Serial driver is working. ![]() dev/cu.Bluetooth-PDA-Sync /dev/cu.usbserial dev/cu.Bluetooth-Modem /dev/cu.iPhone-WirelessiAP Keyspan serial-USB adapter drivers can be found in their Support Section.Īfter installing the correct driver, plug in your USB-Serial adapter, and open a Terminal session (Applications/Utilities).Įnter the command ls /dev/cu.*, and look for something like usbserial (or similar):.Belkin - USB Serial Adapters: F5U257, F5U103, F5U003 (poor OS X support).Silicon Labs - CP210x USB to UART Bridge Virtual COM Port (VCP) drivers.If your adapter doesn't work with either of these, try the following sources: NOTE: It may be necessary to remove any previous driver before installing a newer one,Įg: $ sudo rm -rf /System/Library/Extensions/ProlificUsbSerial.kext UPDATE: Mavericks (10.9) includes a driver for FTDI-based Serial-to-USB adapters. Most Serial-to-USB adapters will work on a Mac with one of the following OS X drivers. You can use screen, although Minicom (or a GUI program) offer more features and functionality. You just need a serial to USB adapter, the right driver, and some Terminal software. Thanks in advance for any suggestion or doubt.Mac's are excellent tools for accessing serial device TTY ports (to console into PBX's, switches, and routers). Whatever I do, the best I can get is the -10829 error message. Password " pswd" with administrator privileges I also have tried to correct possible privilege issues and, to do that, tried to use the recommended shell commmand I have verified permissions on files and directories (tried different combinations as well) ssh -i /var/root/.ssh/jxxxxxx_rsa osascript /path_to_apple_script/apple_script Second example: any attempt to directly trigger the applescript also fails. It fails with the error code : "execution error: An error of type -10829 has occurred. Ssh -i /var/root/.ssh/jxxxxxx_rsa /path_to_shellScript/shellScript Ssh -i /var/root/.ssh/jxxxxxx_rsa script works when requested to execute simple tasks on the Client mac (like listing files seen in a directory), but fails when used to trigger the applescript above, directly using osascript or indirectly.Įxample: any attempt to indirectly trigger the applescript through a shell script command fails. To trigger the applescript from the Server mac (away from the Client mac), I have first tested a ssh shell script having root privileges on both machines Osascript /path_to_apple_script/apple_script ![]() The above applescript, located in any directory of the Client mac, works when addressed manually and locally: I can trigger it (1) locally on the Client mac by hand on the applescript or (2) it works by a local manual command to a shell script located in a directory of the same Client mac the job of which being to trigger the applescript or (3) by the below line of command in terminal ("shellScript"). SPowerDownD2.scpt ("apple_script") Tell application "xTension" Both macs are running high Sierra and the Client mac must run the following applescript upon receipt of the appropriate instruction from Server (xtension.app is a home automation software having applescript interface but no shell script interface). The purpose of this instruction is to trigger (through the Client mac automation software) the shut down of the backup disk power supply, to save energy. ![]() I face a vexing problem on my home set-up involving a Server mac advising a Client mac that a task (a back-up task) was successfully implemented.
0 Comments
Leave a Reply. |