Why Apple hates Home/End/Page Up/Page Down?

open a terminal, type in a command and I want to go to the beginning of the line and then back to the end of the line. How do you do this? I've never understood why Apple doesn't have a backspace and a delete button as well as a simple home and end.


Any pointers would be a appreciated.


G

MacBook Pro with Retina display, OS X Mountain Lion, 16gb RAM 512MB HD

Posted on Sep 5, 2012 8:30 AM

Reply
Question marked as Top-ranking reply

Posted on Mar 5, 2014 6:38 PM

I'll take a stab at this as I'm new to Mac, and a veteran of the *nix, VMS (not VMs) and Windows world.


First a little background:

The DOS command prompt did not support HOME, END, UP, DOWN, LEFT or RIGHT for years. It only supported F3 to recall last line and BACKSPACE to erase the character to the left of the cursor. Then around Windows 95 or so, it added the ability to use LEFT and RIGHT and INS to move left and insert characters. And finally, with the NT-based command prompt (essentially from DEC VMS, but that's another story), they added a full command-line history and editing modes. There had been replacement command shells, and overlays that provided these functions for years, but out of the box, nope.


*nix, Linux and Unixen included, have been worse off. stty is the program in *nix that controls the terminal interface for most of the shells (sh, csh, ksh, bash) and it has fairly limited support of special keys (special keys didn't have standard key codes until the 90s). So, if you sat at an IBM Terminal connected to an IBM Server running IBM AIX, and ran an AIX ksh in an aixterm, then for some applications your keys would work correctly and the command line worked mostly as expected within the limits of ksh. But, it was super inconsistent, and as soon as you ssh(neé rsh)ed in from another host, all bets were off.


When linux started it, it was much in the same boat. And even upgrading your keyboard caused no end of grief on how the command line behaved (and in some cases even the graphical interface had issues with keys).


But, now in the glorious future, all these problems have gone away. Kind of.


Terminal is a barely enhanced version of the xterm applicaiton OS X inherited from BSD(?). There are advantages in OS X for making this a very lean change, it's fast, it performs predictably, it acts like the X Terminal that command line apps expect, and it behaves almost exactly how *nix nerds expect it to.


But, it is not the rich command line application that CMD.EXE is, in fact, it's not a comand line application at all, it's a terminal emulator, which launches the default shell (usually bash, or Bourne Again Shell).


Now, PuTTY is a terminal emulator, more specifically it's a ANSI terminal emulator that does PC keyboard conversions on the fly. If it mates up with your target OS and can set the key mappings correctly, you're in like Flynt, but when it screws up, it takes some doing to fix.


So, back to Mac OS X Terminal. It runs a fairly simple wrapper around xterm, in fact, if you ask bash what terminal it thinks it's running (echo ${TERM} ), it reports 'xterm-256color' (an xterm that supports ansi 256 color text mode).


As an old unix nerd myself, when I login and I see the fixt width font and the obvious bash prompts, I expect my session to default to Emacs editing mode (which it does).

http://www.math.utah.edu/docs/info/features_7.html


And subsequently, I can Ctrl-A, Ctrl-E, Ctrl-D, Ctrl-P and Ctrl-N to my hearts content. Heck even DELETE, LEFT and RIGHT work as expected. But, what gives with HOME, END, PAGE UP and PAGE DOWN?


Well, in the olden days most terminals didn't have those keys, and keyboard implement them a little differently. They have escape codes in them (like ESC]0x2C). So, a lot of the legacy unix shells and utilties cannot interpret them.


How does Linux do it? Well, Gnome Terminal has a lot of enhancements, and the shell understands Gnome Terminal, and Gnome Terminal has keyboard mappings for all the special keys.


But, and this is key, Linux is built for command line hackers, so the self-same command line hackers have invested an inordinate amount of time fixing these things. And, Linux ships with a clone of xterm, for when Gnome Terminal screws something up.


Mac OS X does not ship with a fancy Gnome Terminal (but you can install it if you want), it comes with the basic debugging terminal, that they don't expect their core users to use. I don't think early Mac OS even shipped with a terminal application, until they switched to the BSD core for Mac OS X.


But, it provides all the hooks for one to be developed a quick google shows:

http://lifehacker.com/5857046/the-best-terminal-emulator-for-mac-os-x

http://iterm.sourceforge.net/

http://software.jessies.org/terminator/


And the App Store has over 30 terminal emulators.


I doubt that the company credited with the popularization of the GUI, will do much more than an xterm. I'd recommend experimenting with some of these alternatives (I'd start with the free ones, and google for reviews).

21 replies
Question marked as Top-ranking reply

Mar 5, 2014 6:38 PM in response to jamestsnell

I'll take a stab at this as I'm new to Mac, and a veteran of the *nix, VMS (not VMs) and Windows world.


First a little background:

The DOS command prompt did not support HOME, END, UP, DOWN, LEFT or RIGHT for years. It only supported F3 to recall last line and BACKSPACE to erase the character to the left of the cursor. Then around Windows 95 or so, it added the ability to use LEFT and RIGHT and INS to move left and insert characters. And finally, with the NT-based command prompt (essentially from DEC VMS, but that's another story), they added a full command-line history and editing modes. There had been replacement command shells, and overlays that provided these functions for years, but out of the box, nope.


*nix, Linux and Unixen included, have been worse off. stty is the program in *nix that controls the terminal interface for most of the shells (sh, csh, ksh, bash) and it has fairly limited support of special keys (special keys didn't have standard key codes until the 90s). So, if you sat at an IBM Terminal connected to an IBM Server running IBM AIX, and ran an AIX ksh in an aixterm, then for some applications your keys would work correctly and the command line worked mostly as expected within the limits of ksh. But, it was super inconsistent, and as soon as you ssh(neé rsh)ed in from another host, all bets were off.


When linux started it, it was much in the same boat. And even upgrading your keyboard caused no end of grief on how the command line behaved (and in some cases even the graphical interface had issues with keys).


But, now in the glorious future, all these problems have gone away. Kind of.


Terminal is a barely enhanced version of the xterm applicaiton OS X inherited from BSD(?). There are advantages in OS X for making this a very lean change, it's fast, it performs predictably, it acts like the X Terminal that command line apps expect, and it behaves almost exactly how *nix nerds expect it to.


But, it is not the rich command line application that CMD.EXE is, in fact, it's not a comand line application at all, it's a terminal emulator, which launches the default shell (usually bash, or Bourne Again Shell).


Now, PuTTY is a terminal emulator, more specifically it's a ANSI terminal emulator that does PC keyboard conversions on the fly. If it mates up with your target OS and can set the key mappings correctly, you're in like Flynt, but when it screws up, it takes some doing to fix.


So, back to Mac OS X Terminal. It runs a fairly simple wrapper around xterm, in fact, if you ask bash what terminal it thinks it's running (echo ${TERM} ), it reports 'xterm-256color' (an xterm that supports ansi 256 color text mode).


As an old unix nerd myself, when I login and I see the fixt width font and the obvious bash prompts, I expect my session to default to Emacs editing mode (which it does).

http://www.math.utah.edu/docs/info/features_7.html


And subsequently, I can Ctrl-A, Ctrl-E, Ctrl-D, Ctrl-P and Ctrl-N to my hearts content. Heck even DELETE, LEFT and RIGHT work as expected. But, what gives with HOME, END, PAGE UP and PAGE DOWN?


Well, in the olden days most terminals didn't have those keys, and keyboard implement them a little differently. They have escape codes in them (like ESC]0x2C). So, a lot of the legacy unix shells and utilties cannot interpret them.


How does Linux do it? Well, Gnome Terminal has a lot of enhancements, and the shell understands Gnome Terminal, and Gnome Terminal has keyboard mappings for all the special keys.


But, and this is key, Linux is built for command line hackers, so the self-same command line hackers have invested an inordinate amount of time fixing these things. And, Linux ships with a clone of xterm, for when Gnome Terminal screws something up.


Mac OS X does not ship with a fancy Gnome Terminal (but you can install it if you want), it comes with the basic debugging terminal, that they don't expect their core users to use. I don't think early Mac OS even shipped with a terminal application, until they switched to the BSD core for Mac OS X.


But, it provides all the hooks for one to be developed a quick google shows:

http://lifehacker.com/5857046/the-best-terminal-emulator-for-mac-os-x

http://iterm.sourceforge.net/

http://software.jessies.org/terminator/


And the App Store has over 30 terminal emulators.


I doubt that the company credited with the popularization of the GUI, will do much more than an xterm. I'd recommend experimenting with some of these alternatives (I'd start with the free ones, and google for reviews).

Sep 6, 2012 5:45 PM in response to Jeffrey Jones2

I wish you'd actually go try what you're posting here. Ctrl A and Ctrl E don't work either. I'm also well aware of what terminal is and how to use it. I'm also well aware of keyboards and how to use them. Comments of not putting keys on a keyboard because there is no room is frankly BS because smaller computers have more keys on them than Apple puts. With that being said, whether Apple thinks you ever use Home and End keys doesn't mean people don't. I have people that work with me that refuse to use Apple computers simply because they hate their keyboards and how the leave things out for absolutely no good reason. I'd love to see the actual research where anyone has ever concluded you didn't need those keys.


Sorry, I just get tired of hearing excuses for lame decisions made by Apple. I live in the terminal and I make mistakes and need a quick way to jump back and forth on the command line. Every single OS out there gives me this ability, EXCEPT APPLE!. I spent almost $3500 buying a new MBPr and accessories and something so basic missing all this time drives me crazy.


Sorry, there are no excuses!


G

Mar 6, 2013 7:54 PM in response to cybercrypt13

I have to agree with cybercrypt13.. I get what you're all saying, but you see, as someone coming from Windows and Linux, home, end, pg up and pg down have always functioned the exact same, across all applications and versions of those platforms. Yet upon arriving in OSX, which I do ADORE, I've casually checked for about 5 years and yet to find a universal solution. I can confirm that in the text editor I'm using right now, yes control+{a,e} works as pg up/down, but it isn't so in the default terminal.


As a software engineer, I feel equipped to comprehend the details of why this is different... But it doesn't matter.. This is an issue fit for the 80s and one developer should have fixed it back in the NeXT days.


I am irritated beyond rationality about this. I don't care what the details are, I just am comfounded this remains an actual issue. It should be unified with the other major platforms and just work. Is this the last relic of the "Think Different" campagin? Everything else about OSX is basically perfect and unchallenged for usability, except this issue.


My only theory is that this issue has managed to be neglected for some really really backward reason and there is no actual rational thought involved.


I'm not interested in any explanations. I just want Apple to FIX this serious usability issue. This is behaviour I'd expect from Microsoft, who doesn't at all have this particular problem.


Thank you Internet, I needed to get that off my chest. I'll probably have to vent again, in a few years.


(*sheds a tear of rage*)

Sep 5, 2012 8:39 AM in response to cybercrypt13

cybercrypt13 wrote:


open a terminal, type in a command and I want to go to the beginning of the line and then back to the end of the line. How do you do this?


Hold down the option key and use the left and right arrows.



I've never understood why Apple doesn't have a backspace and a delete button as well as a simple home and end.


They do, on the full size heyboard. Not on the compact keyboard or on laptops, where there isn't room for them. For Home and End, use fn-option-up and down keys. fn-delete will do a delete-right.


User uploaded file

Sep 5, 2012 8:39 AM in response to cybercrypt13

Because they don't feel the user needs them, Wrong or right.


Home = Command+Left arrow key

End = Cmd+Right arrow.


P^Pv = Cmd+up/down arrow.

Backspace = fn+delete (sometimes, other times not)

Delete = Delete (sometimes, then not sometimes)



All key combo above, as noted with delete key, work sometimes and most of the time not when you really need it.


It's a Mac and Steve Jobs Knows Best what is good for all users. Just ask him.

Sep 5, 2012 8:49 AM in response to stevenfrombrownsburg

stevenfrombrownsburg wrote:


Actually, in most cases the Delete key functions like a Backspace key. To delete characters to the right of the cursor, use Fn+Delete. First thing I learned as a former Windows user converting to the Mac way a couple months back.

Yup right Delete = Backspace, forgot for a second.


Delete to the right of cursor, what is normally known as the function of the REAL Delete key, is fn+Delete (Sometimes).

Sep 6, 2012 2:44 PM in response to cybercrypt13

Terminal is not a text editor. It is a tool for running Unix shells. You must follow the conventions determined by your shell and your shell configuration.


A typical configuration in bash uses Control-A for the beginning of the line, and Control-E for the end of the line. This is a bash convention, not set by Apple. However Apple has provided a feature: if you Option-Click anywhere on the line to move the cursor to the clicked point. (Terminal sends the necessary commands to the shell to move the cursor to that point.)

Sep 6, 2012 6:19 PM in response to cybercrypt13

If you are comfortable with the vi or emacs editor, you can set command-line editing with the editor name:


$ set -o vi


Now, up arrow, walks you back up the bash command history tree. When you see a command you want to edit, hit esc to enter view and navigate mode.


i - insert mode

esc - exit insert mode

h - left one char

l - right one char

home - beginning of line

end - end of line

delete - remove char right of cursor

usual vi line commands


If you are at the terminal prompt, Page up will jump a page back in command-line history. Page down moves forward a page.

if your terminal session loses destructive backspace or Ctrl-U destructive line delete, here is a command that still provides fond memories to some us:


$ stty dec

Sep 6, 2012 6:28 PM in response to cybercrypt13

I open a Terminal window, type in history, and home, end, page up, and page down keys work normally. I don't do ssh stuff so can't check your example.


If i'm typing code or recalling past commands using the arrow keys, CNTRL+A goes to the line's beginning and CNTRL+E goes to the line's end. More at http://osxdaily.com/2006/12/19/command-line-keyboard-shortcuts-for-mac-os-x/. If it's not working for you, create a new admin user account, log into it, and try there. You might have some mucked up Terminal prefs.


What else might you be wanting, since I didn't read every entry.😉

Sep 7, 2012 1:58 PM in response to cybercrypt13

Just to add to this... Control-A and Control-E do in fact work to go to the beginning and ending of the line respectivelly in terminal.app. t's been that way since pretty much the beginning of UNIX shells. Jeffry Jones is correct. Cybercript13, if you lived in the shell, you would know this 🙂. At any rate, it might be a nice gesture if you apologized to Jeffry Jones, and retracted your statements about Apple. (you're beginning to sound like "pts").


If you are in a default shell for Terminal.app, this should all work. What keyboard are you using?

Mar 20, 2013 7:40 AM in response to jamestsnell

The behavior of keys when you are in a Terminal window is governed by what is running in that window (i.e. bash, vi, emacs, etc.), by the traditional tty driver and terminal emulation layers ("man terminfo" and "man stty" are starting points for that rathole), and by the settings of Terminal, including "Profiles" that define many of the tty parameters and keyboard->character mappings. Having spent many years as a sysadmin of diverse Unix-ish machines, I assure you that they do NOT all behave identically. Even across commonly used Bourne-like shells (e.g. bash, ksh, and BSD sh) the behavior of "vi" & "emacs" key bindings is not uniform. As the existence of shell options named after text editors demonstrates, the behaviors of various keys in text editors isn't even intended to be consistent. However, if you dive into the Terminal settings and make them match the default expectations of whatever non-Mac platform you are used to AND modify your shell initialization to not mangle that, you can get very good consistency between how the same programs behave between MacOS and other platforms. For example, I have a single Terminal Profile and common ~/.profile file that I use across 3 versions of MacOS, 3 versions of FreeBSD, 2 versions of Solaris, and multiple versions of 3 Linux distros that provides me almost perfect keyboard consistency across them all. It may not be encouraging to note that I've been tweaking that .profile for over a decade, not because of MacOS so much but rather because I keep running into new edge cases in narrow classes of (mostly Linux) systems.


The core problem that started this thread is that laptop keyboards are short on keys, and it isn't particularly obvious on Mac laptops how Apple makes up for that basic common problem. The critical unmentioned clue is the "fn" key, which swaps the functions of the Function keys between "standard" (i.e. app-visible) and Mac-specific system controls. Its lesser-known effects are to switch the arrow keys to Home/PageUp/PageDown/End keys, swap the Return key from CR to LF, and swap the delete key from DEL (0x7f) to the VT100 backspace sequence (ESC[3~).


As for GUI text editors, it is wrong to blame Apple for inconsistency there. They have long published guidelines, provided the example of TextEdit (and SimpleText before it) and provided usable basic text editing widgetry in every Mac API going back to 1984. Also dating back that far is the mostly delusional insistence of developers that their UI preferences and/or alternative implementations of editable text views are better than Apple's.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Why Apple hates Home/End/Page Up/Page Down?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.