Talk:Unix shell

From Wikipedia, the free encyclopedia

 This article is within the scope of Computing WikiProject, an attempt to build a comprehensive and detailed guide to computers and computing. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.
??? This article has not yet received a rating on the quality scale.
??? This article has not yet received an rating on the importance scale.

Contents

[edit] What is a "Unix shell"?

1) This descriptions is somewhat primitive and wrong.

2) The best definition comes form th man page of the kornshell: As shell .. is a command and programming language that executes commands read from a terminal or a file.

The ingenuity is that Unix separates between a character terminal (and its emulation like xterm) , were you do all the typing and the shell which executes them. A terminal is usually remote and, in the most basic form, the shell does not see an commands one typed until you hit enter.

A console is a HUI that is directly connected to the Unix node (Keyboard, graphic card, screen) were a character terminal, such as a vt100, is a self contained unit of keyboard and a screen and a little memory that is connected via a serial line.

Today with the use of graphic (X11) terminals th scenario is more complex but the basic the principal is the same.

The fore the DOSish term "command line" is not correct and not used in the proper Unix documentation and should be removed.

3) cmd and similar Windows apps may be POSIX compatible but certain no Unix-Shells and references should be removed.

4) Users can select the login shell with cnsh and change there current shell with

exec <shell name> e.g. exec zsh

These are two things.

5) No not any program can be a login shell. Only thin mentioned in:

cat /etc/shells 
/bin/sh
/bin/bash
/sbin/nologin
/bin/tcsh
/bin/csh
/bin/ksh

6) A shell distinguishes from other programming languages in the way that it almost always calls external commands to implement a functionality combined with pipelines /filters ....

—Preceding unsigned comment added by Ahaack29 (talk • contribs) 04:10, 14 November 2007 (UTC)

2) The first sentence of the Korn shell man page on my system, "Ksh is a command and programming language that executes commands read from a terminal or a file.", is missing the word "interpreter" between "programming language" and "that executes commands". A language doesn't execute commands; an interpreter for the language does.
Unix was, and is, not the only system that "separates between a character terminal (and its emulation like xterm) [where] you do all the typing and the shell which executes them" - that dates back at least as far as CTSS.
That separation means, on Unix, that it's irrelevant to a shell whether the commands come from a real terminal on a serial line, a console (i.e., a terminal emulator implemented using a computer keyboard and display without a window system), a terminal emulator such as xterm or Konsole or GNOME Terminal or Terminal, or a remote connection using TELNET or rsh or ssh or....
It's relevant to mention a command line interface in this context, even if we don't say that a Unix shell is "the command line". The term "command line" isn't "DOSish"; it appears, for example, about 25 times on the [multicians.org] Web site, so it appears to have been used in Multics - an OS that antedated both MS-DOS and Unix.
3) The Windows command interpreters might not be Unix shells, but the article wasn't claiming that they are - it was just saying they were analogous to command interpreters on Unix systems. That analogy might be useful to somebody reading the article if they are used to Windows and unfamiliar with Unix.
4) The term "login shell" isn't used in the article. Your "login shell" is just the program run as the first program run if you do a non-GUI login - it might or might not be a Unix shell (it might, for example, be a specialized program, e.g. you might have a Unix-based point of sale system, and users who log in to that system might get the point of sale application as their login shell). For people with a Unix shell as their login shell, that shell is their initial "current shell".
5) Any program that can handle being run as a login shell can be a login shell. On most current Unix systems the only programs that the user can specify as their login shell with chsh are the ones in "/etc/shells", but a system administrator could make programs other than that, e.g. a point of sale program of the sort described in the previous paragraph, the login shell for an account. Guy Harris 11:44, 14 November 2007 (UTC)

[edit] Nomenclature

I couldn't really decide on the proper naming here. I've tried to use unix shell as the more generic term, and a better one than shell, and use things like bourne shell for the more particular terms. comments? --drj

What's wrong with "command-line shell"? "Unix shell" might be too specific- look at rc, which is from Plan 9. --Maru 02:46, 6 August 2005 (UTC)


[edit] Supercession of sh

On a lot of linux (and bsd?) systems out there, /bin/sh is still the default, but it is really just a symlink to /bin/bash or similar. Perhaps this could be incorporated?

Oh those poor linux users. On the systems _I_ administrate /bin/sh is not a link to /bin/bash. I'll mention it. --drj

In Mac OS X v10.4 sh is installed, but bash is the default shell. Dread Lord CyberSkull ✎☠ 10:49, 2005 September 1 (UTC)

Debian offers a shell called dash [1], which is designed to be small and sh-compatible, and can be used as the symlink at /bin/sh; searching for that, I also came upon something called shish [2] . The point being that many shell-scripts use this as their shebang line, so they'll run more efficiently if you symlink it to something more efficient. - IMSoP 12:45, 1 September 2005 (UTC)

[edit] Missing content

There's lots more could go in here. It doesn't take too long to describe the family tree of the various Unix shells, and compare a few features. Is it really true to describe Bourne as merely the de facto standard? I remember (but can't remember the details) that there was a "shell war" in the Early Days, which Bourne won (over another Bell Labs competitor, I think; definitely not csh). I assume all these curious links to a subpage called bin are just overzealous wikification? User:Tim Goodwin


[edit] Etymology of term "shell"

I was searching the wikipedia to know why a unix "shell" is called so. Might be a good idea to put it in... --BilboEd

Oh, I see, this is an old question which was never explicitly answered. The article now covers this point. - IMSoP 14:31, 1 September 2005 (UTC)

[edit] Shells listed by compatibility

I've resorted the list of shells at the bottom of the page by whether they are compatible with Bourne, C shell, or neither. (And before you ask why rc and es don't get their own category...because Bourne and C-shell are the traditional major Unix shells, while rc doesn't seem to be widely used outside of Plan 9 and es, the only rc-compatible shell, has apparently been abandoned since 1997, that's why.) Beinsane 07:18, 25 December 2005 (UTC)

[edit] Unsorted comments on the Unix shell topic

Just wanted to point out some inaccuracies on those pages. Please bear with me, I'm not familiar with wikipedia, and English is not my mother tongue.

I read:

The term shell also refers to a particular program, namely the Bourne shell, sh.

That is quite an incorrect way to approach it. I would rather say that. The term shell refers to the sh program. sh having taken different forms along Unix history from the Thomson shell, going through the Bourne shells (all its implementations) and now modern shs. modern shs are now defined by an open specification that is mostly a superset of the Bourne shells. So the "sh" of the modern Unices are one implementation or the other of that specification. Known implementations of the sh specification are ksh (the first one and from which was derived the specification), bash (when called as sh), FreeBSD shs (Almquist shell based), zsh (when called as sh), pdksh and its derivatives (posh, MirBSD ksh...). Some systems like Solaris have more than one sh program: the standard one and a Bourne shell for backward compatibility for scripts written in a Bourne syntax before the sh specification was released (somewhere in the early nineties).

The Bourne shell is generally no longer located as /bin/sh. It is only the case on some very rare systems (like Solaris cited above). Many systems don't have a Bourne shell at all anymore, and when they have one, it's generally either in a non standard place such as /usr/old/bin or has a different name such as bsh or sh.bourne. The sh code wasn't made free until very recently. That's why no Free Unix system ever had it (exception of early BSDs which was the cause of law suites, BSDs then adopted the Almquist shell which was a free reimplementation of the Bourne shell as it could be found on SysV with some extensions and has now been made POSIX (modern sh) conformant).

Many scripts are still written in a Bourne compatible syntax, but just because it is the greatest common denominator of the shs of the past and current Unices. sh is often confused with the Bourne shell because sh has been the Bourne shell on many systems for a long period of time.

Some comments about Windows shells. It can be noted that all the Free Unix shells (zsh, bash, pdksh...) are available to Windows via the Cygwin free Unix adaptation software.

The echo $SHELL to determine the current shell is not correct. $SHELL is the prefered shell of the user. It is initialised by "login" as the user's login shell and can be modified by the user to tell applications which is his shell of choice. ps -p "$$" is more likely to tell which shell is currently interpreting that command line (ps -p $pid for rc/es) —Preceding unsigned comment added by Stephane Chazelas (talk • contribs) 16:50, 9 September 2006 (UTC)

Not all Unix shells are compatible with the Bourne shell; the C shell, and variants such as tcsh, aren't, and the shells in Version 6 Unix (the Thompson shell) and PWB/UNIX (the PWB shell or "Mashey shell) antedated the Bourne shell and weren't compatible with it.
I suspect some commercial Unixes other than Solaris also have the Bourne shell as /bin/sh. Guy Harris 12:06, 14 November 2007 (UTC)