Talk: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)Reply

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)Reply

I think it's the user interface you get, including the basic facilities, wildcarding, pipes, here docs, etc., not what it runs on. It's not about whether the underlying OS is Unix-like, it's about whether the user interface the application creates is Unix-like. If it's a Unix shell, it's a Unix shell whether you run it on Unix or Windows. I've decided to WP:BEBOLD and have made this edit[1]. Please note that I have a possible WP:COI declared here. Msnicki (talk) 17:33, 23 November 2015 (UTC)Reply

I don't like the fact that we're now making up our own definition. I'd much prefer a lede that gives the minimal, prosaic definition first:

• on Unix, the shell is the program that provides a CLI and programmability.
• Then list the important ones (Thompson/Bourne/C shell).
• Finally, a bit about how Unix-style shells are available on other systems.

This historical route should allow us to stay clear of semantic issues, in particular the eternal discussion about what is and what is not Unix-like. QVVERTYVS (hm?) 21:53, 23 November 2015 (UTC)Reply

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)Reply

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 [2], 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 [3] . 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)Reply

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

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

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)Reply

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)Reply

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)Reply

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)Reply

• "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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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'.

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 89.67.52.124 (talk) 15:22, 21 July 2013 (UTC)Reply

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

The fact that the template main exists, does not mean it should be used in every situation. The usage here is against what even the template documentation states. It should not be used in avoidance of inline links. People do this all the time unfortunately without examining the merits. These main links are disruptive to section and article flow. The emphasis becomes navigation rather than content. Having a section title, then a main link, and another mention of the same title in the first sentence of the section, often the very first words, makes for poor style. A simple inline link is completely sufficient. Kbrose (talk) 18:23, 3 April 2014 (UTC)Reply

To me, {{Main}} links are highly usable when reading articles, as they clearly point out that a section is only a summary of a much broader article. They might be awkward and look goofy, I agree, but to me they're especially usable when skimming through an article; in many cases I skip immediately to the referred article instead of spending time searching for its link within the summary.

By the way, this is about including {{Main}} links in Unix shell § Bourne shell and Unix shell § C shell sections. — Dsimic (talk | contribs) 18:49, 4 April 2014 (UTC)Reply

RJaguar3 has questioned the fair use of the desktop image, File:TcshAndShScreenCapture.png, that appears at the top of this article arguing, "A free image could be taken of a command shell in Linux without all the non-free elements (such as the taskbar at the bottom of the image)." I created the screenshot about 5 years ago and I've offered my thoughts, explaining why I think it's acceptable. But I assume anyone is free to weigh in on the issue with their own thoughts. Msnicki (talk) 21:52, 7 March 2015 (UTC)Reply

Hello! Hm, I'm not sure whether that objection is reasonable if an image isn't uploaded to Wikimedia Commons. To me, having an OS X desktop screenshot shouldn't hurt, and OS X is formally even closer to representing "true Unix" than Linux. :) However, please keep in mind that I'm by no means an expert when it comes to various licensing-related issues. — Dsimic (talk | contribs) 14:52, 13 March 2015 (UTC)Reply

Thank you, Dsimic. It's unlikely any admin who reviews the objection will read any comments here so if you would like your opinion considered, it'd probably be helpful to add it to the file page itself. Msnicki (talk) 14:59, 13 March 2015 (UTC)Reply

You're welcome. :) Actually, I wanted to do that, but saw no discussions on File talk:TcshAndShScreenCapture.png. Could you, please, specify the actual page? — Dsimic (talk | contribs) 15:13, 13 March 2015 (UTC)Reply

This is the first time I've encountered a fair use objection, so I'm just guessing how to respond. But I think you have to add a {{di-replaceable fair use disputed|Your reason that a free replacement can not be found or created}} tag. It looks like anyone who wants to comment has to do that. Msnicki (talk) 15:21, 13 March 2015 (UTC)Reply

I'd say that tagging the file with {{Di-replaceable fair use disputed}} wouldn't be the right thing to do, as technically there is a possibility for creating a completely free replacement. I'd say that the best we can do is to note there's a related discussion. — Dsimic (talk | contribs) 16:02, 13 March 2015 (UTC)Reply

Really, Ken Thompson wrote the original UNIX shell, not Steve Bourne.

Serious use of the shell as scripting language happened in 1975 with [PWB shell], and it describes the history.

Using a Command Language as a High-Level Programming Language was paper at 1976 IEEE COMPSAC Conference. Read that to see which features got added to Thompson shell. At that time, that site was the largest general-use UNIX complex at Bell Labs, so there were a lot of users.

Note that it was not so much that Bourne sh "won out" over competitors, but that I'd already extended PWB SH about as far as made sense to stay upward compatible, and spent a *lot* of time in discussions with Steve about SH features, and with him and Dennis on relevant OS features, like environment variables, which only solidified in early 1978. Many others were involved in "shell task force" meetings. People were happy to go to something written from scratch (although ALgol 68 wasn't that popular), but didn't want to lose functionality found to be helpful over years of usage. Steve spent a lot of time performance-tuning, and adding features in order to get buyin from the large PWB SH user community.

So, real history: 1969- Thompson shell, mostly for terminal use and simple scripts

1975- PWB shell, including variables, more control structures, path search, etc ... stuff needed for widespread use

1977-1978 lots of discussions, I still have some of the memos. The Environment Variable feature didn't settle until early 1978, and UNIX V7 was later.

1978- - C-shell, especially important for interactive features JohnMashey (talk) 23:34, 25 September 2015 (UTC)Reply

1979- UNIX V7, with Bourne shell released externally, as best as I can recallJohnMashey (talk) 02:42, 30 September 2015 (UTC)Reply

Many thanks to JohnMashey for his helpful suggestions. I've done a pass trying to reorganize the material accordingly. I invite additional suggestions. Msnicki (talk) 19:03, 24 October 2015 (UTC)Reply

@JohnMashey: In a recent keynote talk at a BSD conference, Stephen Bourne mentioned that the Bourne Shell development started in 1976. talk video slides, see page 13 ff. Could you confirm this? BTW: I am asking this because I like to have a correct authors section in the man page of the Bourne Shell I maintain (see recent Bourne Shell man page) Schily (talk) 10:32, 27 October 2015 (UTC)Reply

@Schily:Yes, 1976 is correct. As noted, much discussion 1977 (when I'd moved to Murray Hill, in UNIX Support Dept, and Bell was trying to consolidate the numerous UNIX variants, hopefully get a few key things into V7, and then add features beyond that for the different target usages.)JohnMashey (talk) 19:53, 27 June 2017 (UTC)Reply

@Schily:Sorry, I just double-check myself and found I was off by 3 years. Aige02 at gmail (talk) 20:12, 11 February 2021 (UTC)Reply

Is this table really helpful? I'm inclined to toss the whole thing and reduce the whole section to a couple sentences to explain that the behavior of a Unix shell can typically be customized with configuration scripts executed at startup and exit. Before I delete a whole table, possibly making people unhappy, can I hear some comments, please? Msnicki (talk) 19:03, 24 October 2015 (UTC)Reply

It of course is helpful. Schily (talk) 10:47, 27 October 2015 (UTC)Reply

I added this section a long time ago as a result of not finding it anywhere. Taxi1729 (talk) 09:07, 13 October 2016 (UTC)Reply

I found it helpful too; I occasionally need to hunt down this information as I use ksh and most everyone else on my project uses bash. MeekMark (talk) 14:34, 17 June 2021 (UTC)Reply

In https://en.wikipedia.org/wiki/Unix_shell#Early_shells there is a sentence:

As shell programming became widespread, these external commands were incorporated into the shell itself for performance.

Given the context of that section, the phrase "these external commands" doesn't make sense – I don't think the section mentions external commands anywhere else but this phrase. I know there are some external commands, such as echo, that are external commands, and also built-in shell commands.

MeekMark (talk) 14:45, 17 June 2021 (UTC)Reply

The article says: "A shell hides the details of the underlying operating system..."

This is intuitive, appealing and incorrect as an explanation of the term's origin. Louis Pouzin's 1965 memo[4] was explicit that it was not the operating system (supervisor) "inside" the shell, but rather the procedures that it ran (p. R-3). The purpose of his shell was to create and then communicate with active procedures. That is what Unix shells also do, replacing "active procedure" with "process." — Preceding unsigned comment added by 170.41.209.67 (talk) 15:54, 26 August 2022 (UTC)Reply

For some context, the model in Multics was that commands were subroutines ("procedures", in PL/I terminology), and invoking a command involved making a subroutine call to the subroutine for the command. Given that Multics made it relatively straightforward to find, at runtime, the executable code file containing a subroutine, and call the procedure in there, this meant that commands didn't have to be compiled into the command interpreter. (The shell itself was also a subroutine.)

At least on UN*Xes and Windows, and OSes inspired by them, commands are executable images to be run in a process rather than subroutines to be called within a process, so invoking a command involves the shell creating a new process running the executable image for the command. (The shell itself is an executable image.)

So the shell is hiding some details, namely those of calling a procedure given a string name (the command name) for the procedure, and passing arguments to it, on Multics, or those of creating creating a new process running an executable image given a string name (the command name) for the image, and passing arguments to it. However, those are the only details hidden; it's not hiding all "the details of the operating system" (whatever that vague and broad phrase might be intended to refer to). Guy Harris (talk) 20:10, 26 August 2022 (UTC)Reply