Archive for the ‘unix’ Category

Why Do Long Options Start with Two Dashes?

August 2, 2019

Around 1990, Richard Stallman (RMS) and I were writing the GNU C library getopt() and he wanted to extend it to support long (multi-character) option names for user-friendliness. He considered Unix inferior in this regard to other operating systems such as TOPS-20 which supported long options (that could be abbreviated). He wanted GNU to be better than Unix while still compatible. There were a few programs that ran on Unix systems and used long option names starting with either - or no prefix at all, such as find, but those syntaxes were not compatible with Unix getopt() and were parsed by ad-hoc code.

Long options needed a prefix that wouldn’t clash with the Unix conventions, so programs could support both types of options without ambiguity. Richard chose +, since logically if - (for a small number mathematically) is for short options then + would be for long options, and it’s no additional typing. We created an extended interface called getopt_long() to support specifying long options.

But when the IEEE POSIX shell and utilities standard was published in 1992, the + syntax was disallowed. GNU developers discussed what to do over email. We considered -+ as the long options prefix, but that was hard to type, so we settled on --, which wouldn’t violate POSIX or Unix compatibility and wasn’t hard to type.

For a few months, GNU getopt() supported both + and -- to allow time for people to transition their scripts. I’m pretty sure support for + during that transition could be disabled by setting the environment variable POSIX_ME_HARDER (RMS’s exasperation with standards showing there), later changed to the more polite POSIXLY_CORRECT, which also disables recognizing options intermixed with positional arguments.

Because GNU software was popular and the solution was logical, everyone else adopted the -- prefix and implemented variations of it in their own argument parsers. Perl was probably one of the first.

From Novice to Master, and Back Again

January 14, 2013

In 1985, I was a freshman at St. Olaf College in Minnesota. The college had a VAX 11/780 running 4.2BSD and a PDP-11/70 running v7 with some Berkeley and local code hacked in. It was my first experience with multi-user systems other than dialing into an MS-DOS BBS or two.

The college’s Academic Computing Center had printouts of the 4.2BSD manuals, plus some home-grown documentation, available for sale so students could learn how to use UNIX. One week I sat in the Science Center terminal room and started going through the alphabetical list of the commands available on the VAX, trying each one and reading its man page to learn what it did.

Eventually I got to “su”. “Become the super-user”? What’s that? Does it involve wearing a cape? Sounds interesting, so I tried it. To my disappointment, it just asked for a password, and wouldn’t do anything.

Shortly thereafter, someone came running into the room and asked, “Are you David MacKenzie? Did you just run ‘su’?” “Yeah… what does it do?” “Uh, don’t do that.” My failed “su” attempt had been logged on the system console and one of the sysadmins was worried about an attempted breakin.

Within a year, I did have root access on the VAX, as I learned enough to be hired as a student system programmer. I contributed to upgrading the machine to 4.3BSD when that was released.

Recently I was working on a CentOS Linux virtual machine and needed to look up the command-line options to “su”. I had worked for the past several years mostly on Macs where “sudo” is preferred, so my “su” skills were rusty. I ran “man su” and got the information I needed. Then at the bottom of the screen I sheepishly read “Written by David MacKenzie.”

In the 1990s, while filling in gaps in the GNU toolset, I wrote the GNU “su”, and I had forgotten about it. It’s still what Red Hat and other distributions are shipping.

At least I know what it does now.

MacOS Screen Sharing over the Internet using SSH

May 11, 2009

You don’t need to subscribe to iCloud (MobileMe) to access a Mac desktop remotely over the Internet from another Mac (“Back to My Mac”). You just need to do some setup. This description assumes (for simplicity) that you’re using Leopard (MacOS 10.5) or later on both Macs. If you’re still on Tiger (10.4) you’ll need a third-party VNC client like Chicken of the VNC; I haven’t tested that.

It’s also possible to access a Mac desktop from Windows or other operating systems using a VNC client such as UltraVNC. That is described here as well.

This setup runs the Apple Screen Sharing through an encrypted tunnel using SSH, for security.

  1. One-time setup on the Mac you’ll be connecting to, which we will call the “remote Mac”. In System Preferences>Sharing, turn on Remote Login (aka SSH). In System Preferences>Sharing, turn on Screen Sharing. In Computer Settings, select “VNC viewers may control screen with password:”. Choose a password.
  2. One-time setup on the Internet router/firewall for the network your remote Mac is on. Forward TCP port 22 (SSH) from the Internet to your remote Mac’s internal/private IP address. You might find this option under something like “NAT Rules” on your firewall’s setup screens, which are web pages for most routers. If you haven’t assigned the remote Mac a static IP address, you might want to. Otherwise, find out the IP address that your router assigned it by looking in System Preferences>Network.
  3. One-time setup of a host name for your remote Mac’s Internet connection. It’s convenient to give your your firewall’s external IP address a host name, especially if its IP address is dynamically assigned by DHCP and subject to change without notice. A dynamic DNS service like DynDNS.com allows you to create an account and choose a host name for your Internet connection. Some router/firewalls have the ability to keep a DynDNS entry updated.
  4. One-time setup on your local Mac that you’ll be using to connect to the remote Mac. (Not applicable for a Windows or other client OS.) Allow Screen Sharing to connect to 127.0.0.1 (aka localhost); in Terminal run (all on one line):

    sudo defaults write com.apple.ScreenSharing skipLocalAddressCheck -boolean YES

    and type your password when prompted.
  5. To prepare to access your remote Mac’s desktop over the Internet from the local Mac, in Terminal on your local Mac run (all on one line):

    ssh -N -L 6900:127.0.0.1:5900  your_login_short_name@your.dyndns.host.name

    If it asks if you want to add or trust the host key or something like that, respond yes. That should only happen once. When prompted, type the password for your account on the remote Mac.

    your_login_short_name is the name of your home folder on the remote Mac; it will be lowercase with no spaces. The -L option creates a local tunnel which forwards TCP port 5900 (the standard VNC server port) on the remote Mac to port 6900 on your local Mac. The -N option to ssh prevents it from opening a command-line connection; omit it if you want one in addition to the port forwarding.

  6. For a Windows client, you can use the plink program from the PuTTY SSH package:

    "C:\Program Files\PuTTY\plink.exe" -N -L 6900:127.0.0.1:5900 your_login_short_name@your.dyndns.host.name

    plink.exe might be in “C:\Program Files (x86)” or another folder on your computer.

    Alternately, you can use the graphical PuTTY program and in Connection>SSH>Tunnels set

    Source port 6900
    Destination 127.0.0.1:5900

    Then click Add.

  7. Run the Screen Sharing client on your local Mac; in Finder:
    Go>Connect to Server (or Command-k)
    In the Server Address box, type:

    vnc://127.0.0.1:6900

    A login box will pop up; enter your_login_short_name and your password for the remote Mac.
    You can click the + to save this address as a favorite for the future.

    Your remote Mac’s desktop should appear!

    In the Screen Sharing preferences, you might want to try the option “Show the screen at full quality (more detailed)” if needed and you have fast Internet connections at both ends.

  8. For a Windows client, UltraVNC Viewer is known to work. In the “VNC Server” box, enter “127.0.0.1::6900” (yes, two colons), then click Connect. Then enter the VNC password you set earlier on the remote Mac. You will see the Mac’s lock screen; type your account password to unlock it.
  9. When you’re done with your screen sharing session, quit the Screen Sharing app on your local Mac and press Ctrl-c in the Terminal window to disconnect the ssh tunnel.

Design a site like this with WordPress.com
Get started