Talk:Unix shell

What is a "Unix shell"?

1) This descriptions is somewhat primitive and wrong.

2) The best definition comes from the 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) , where 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)

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)

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)

BTW, shebang is a buzzword which should pbbly be present in this article. --Jerome Potts (talk) 03:52, 15 August 2009 (UTC)

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

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)

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)

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)

Questions

• "A Unix shell is a command-line interpreter (see shell) and script host that provides a traditional user interface for the Unix operating system and for Unix-like systems."
  • Can someone define script host?
• Can someone define POSIX shell?

Thanks, --Abdull (talk) 20:38, 3 March 2010 (UTC)

The suggestion to merge with the Shell article

A suggestion has been made by Hm2k that the Unix shell article be merged with the Shell (computing) article and that we should discuss here.

• Keep separate. Yes, a Unix shell is a type of shell, but all shells are types of software, so where does one stop merging? I think there are some defining characteristics of a Unix shell (e.g., it's command line oriented not graphical, it's a relatively thin layer meant to expose rather than hide the OS underneath and it includes certain characteristic features such as wildcarding, a vocabulary of filters like grep and sed connected via pipes, etc.) that previous generations of command line interfaces (e.g., IBM's VM/CMS or TSO) had not offered. It was seminal work. The reason we use words like pipes and wildcarding and shell to mean things in computer science is because the Unix shells introduced these terms. The current article could be a lot better at laying out those defining characteristics. For example, I'm a little skeptical (not being familiar with all of them) whether all of the "exotic" shells listed are actually Unix shells or merely shells that ran on Unix. But lumping Unix shells into a bucket with all other shells (which, let's face it, could mean anything with a UI) would, I think, do a disservice to the intellectual and historical significance of the Unix shells. Msnicki (talk) 15:45, 14 July 2010 (UTC)

Opinionated Article

Many users of a Unix system still find a modern command line shell more convenient for many tasks than any GUI application.

Should be removed. —Preceding unsigned comment added by 92.7.74.215 (talk) 07:00, 5 January 2011 (UTC)

Shell differences

What makes one shell different from another? The article explains what a shell is and goes through a list of them, but what is the difference? Doesn't one Unix/Linux command on one shell run on another? -Rolypolyman (talk) 05:27, 22 January 2011 (UTC)

Historical Accuracy

Pipeline notation existed in the Unix shell (for example in fifth-edition Unix) before the Bourne shell appeared; an early paragraph here implies that the Bourne shell introduced pipelines. -- Jack Waugh

Good call. I agree. The Mashey and Thompson shells both preceded the Bourne shell and each had some of the various features listed. More accurate would be something to the effect that the Bourne shell was the first one to get wide distribution and it's the one that defined this basic set of features that people expect of any Unix shell, especially after the release of Kernighan and Pike's book, "Unix Programming Environment". But you're absolutely right, it wasn't the first to have them all. We also need to find some actual citations. Msnicki (talk) 22:50, 16 March 2011 (UTC)

superuser permission required to choose a different shell?

The article currently says:

"In Unix, users who want to use a different syntax for typing commands can specify a different program as their shell, though in practice this usually requires administrator rights."

I could try to guess what this was supposed to really mean.

What it actually says is patently untrue. Nothing prevents an ordinary user from using invoking a new shell, and choosing from any of the shells on the system.

The chsh program, which changes the default shell field of /etc/passwd, has been available for decades to allow ordinary users to change their default shell, so even changing the default shell does not require the user have superuser privileges.

For what it is worth, nothing requires the default shell for a userid to be a command line interpreter. If a system had some users who insisted they only wanted to use the system for editing, and never wanted to figure out how use any of the system's other confusing programs, their default shell could be changed to an editing program. Geo Swan (talk) 16:55, 14 October 2011 (UTC)

Configuration files for csh

The section Configuration files for shells says /etc/csh.cshrc and /etc/csh.login are used by csh. This seems not to be true for csh of SunOS 4.1.4. I have tested it, and the man page for csh says:

FILES
     ~/.cshrc            Read at beginning of execution  by  each
                         shell.
     ~/.login            Read by login  shells  after  .cshrc  at
                         login.
     ~/.logout           Read by login shells at logout.
     ~/.history          Saved history for use at next login.
     /tmp/sh*            Temporary file for `<<'.
     /etc/passwd         Source of home directories for `~name'.

Startup process

The article says:

On Unix systems, the shell is still the implementation language of system startup scripts, including the program that starts the windowing system, the programs that facilitate access to the Internet, and many other essential functions.

I believe that is not completely true. The systemd folk are trying pretty hard to eliminate the shell's role in starting up a system.

— Preceding unsigned comment added by Theowoll (talk • contribs) 18:04, 16 March 2013 (UTC)