I know that Apple's Terminal.app provides a bash shell. Are there any differences between this and a bash on Linux?
Bash – How similar is Apple’s terminal.app to a bash terminal on Linux
bashosx
Related Solutions
The whole ABI is different, not just the binary format (Mach-O versus ELF) as sepp2k mentioned.
For example, while both Linux and Darwin/XNU (the kernel of OS X) use sc on PowerPC and int 0x80/sysenter/syscall on x86 for syscall entry, there's not much more in common from there on.
Darwin directs negative syscall numbers at the Mach microkernel and positive syscall numbers at the BSD monolithic kernel — see xnu/osfmk/mach/syscall_sw.h and xnu/bsd/kern/syscalls.master. Linux's syscall numbers vary by architecture — see linux/arch/powerpc/include/asm/unistd.h, linux/arch/x86/include/asm/unistd_32.h, and linux/arch/x86/include/asm/unistd_64.h — but are all nonnegative. So obviously syscall numbers, syscall arguments, and even which syscalls exist are different.
The standard C runtime libraries are different too; Darwin mostly inherits FreeBSD's libc, while Linux typically uses glibc (but there are alternatives, like eglibc and dietlibc and uclibc and Bionic).
Not to mention that the whole graphics stack is different; ignoring the whole Cocoa Objective-C libraries, GUI programs on OS X talk to WindowServer over Mach ports, while on Linux, GUI programs usually talk to the X server over UNIX domain sockets using the X11 protocol. Of course there are exceptions; you can run X on Darwin, and you can bypass X on Linux, but OS X applications definitely do not talk X.
Like Wine, if somebody put the work into
- implementing a binary loader for Mach-O
- trapping every XNU syscall and converting it to appropriate Linux syscalls
- writing replacements for OS X libraries like CoreFoundation as needed
- writing replacements for OS X services like WindowServer as needed
then running an OS X program "natively" on Linux could be possible. Years ago, Kyle Moffet did some work on the first item, creating a prototype binfmt_mach-o for Linux, but it was never completed, and I know of no other similar projects.
(In theory this is quite possible, and similar efforts have been done many times; in addition to Wine, Linux itself has support for running binaries from other UNIXes like HP-UX and Tru64, and the Glendix project aims to bring Plan 9 compatiblity to Linux.)
Somebody has put in the effort to implement a Mach-O binary loader and API translator for Linux!
shinh/maloader - GitHub takes the Wine-like approach of loading the binary and trapping/translating all the library calls in userspace. It completely ignores syscalls and all graphical-related libraries, but is enough to get many console programs working.
Darling builds upon maloader, adding libraries and other supporting runtime bits.
The short answer is because linux is really GNU/Linux. Only the kernel is linux but the base collection of utilities providing the Unix like environment is provided by GNU and the GNU shell is bash
As I said, that's the short answer ;)
edited to add some additional commentary...
Let me prefix by saying that I'm not a Unix historian, so I can only answer IMHO
A few points, first of all bash is the kitchen sink of shells, as emacs is to editors.
At the time bash was released there were no free ksh implementations, tcsh was a free csh replacement, but Stallman had a rant against csh for shell programming.
As an interactive shell bash had excellent history/command recall, along with the saving of history from session to session. It was a drop in replacement for sh, bsh, ksh for shell programming and made for a decent interactive shell.
Like a snowball rolling downhill, bash has gained momentum and size.
Yes, there are dozens of other shells; shells that are better suited for individual purpose or taste, but for a single all around shell bash does a decent job and has had a lot of eyes on it for over 20 years.
Best Answer
Terminal is a terminal emulator. It interprets various control sequences sent by programs (control characters like CR, LF, BS and longer control sequences for commands like “clear screen”, “move cursor up 3 lines”, etc.). Terminal is the same kind of program as xterm, rxvt, Konsole, or GNOME Terminal. Almost all modern terminal emulators support the “xterm” control sequences, so they are generally highly compatible (and most programs use the ncurses library and its terminfo database to abstract over the actual control sequences).
bash is a shell. It interprets commands that usually involve running other programs. In normal, interactive use the shell’s input comes from a user via a terminal emulator. The terminal emulator and the shell are connected via a “pseudo tty” device (e.g.
/dev/pts/24, or/dev/ttyp9).Because the tty devices are the only interface between Terminal and bash, they are completely independent. You can use bash with iTerm instead of Terminal, and you can use zsh instead of bash inside a Terminal window.
The version of bash installed on your Mac OS X and Linux systems may be different, but should be fairly easy to install pretty much whatever version of bash you want on either system. You might look at MacPorts, homebrew, or Fink for ways to install recent versions of bash (and other shells) on Mac OS X. Whatever Linux distribution you are using surely comes with packages for common shells.