Talk:Bourne shell
This is the talk page for discussing improvements to the Bourne shell article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||||||||||
|
Previously untitled section
[edit]Hi, I can see the same errors on that page as on the one about "Unix shell".
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.
So it's no longer a popular default shell either, nor is it the default login shell for root on many operating systems. sh is though.
And it's wrong to say it's standard on all commercial Unices.
See my comments on the Unix shell page for details.
Another error:
"for loops, in particular the use of $* to loop over arguments". That's incorrect. $* is the concatenation of the positional parameters. It's $@ when double quoted that allows to loop over the positional parameters, not $*. And "for" loops over the positional parameters by default, so there's no need to specify "$@":
for i do whatever "$i" done
(it's not for do od, but for do done in the Bourne shell)
I don't know if one can say that the Korn shell was written "much later" than csh. I believe it was started in the early eighties (read 1982 somewhere) so only 3 years after csh (I might be wrong on that one).
- re: Bourne shell usage.
- Dates and version numbers may be hard to find. I suspect there was a also divergence as various vendors quickly patched and enhanced the original shell, without sharing these source changes(?) (sh was an "open system", but not "open source"). I know of one DB vendor actually included their standard shell in their DB distribution so as to avoid any unexpected enhancements from the OS vendors. c.f. Talk:Unix shell#Shells listed by compatibility. Would a Timeline of Bourne shell enhancements & clones be an overkill?
- Re:
while ~ do ~ od
- Your comment is clearly correct. As
/bin/od
would have predated the Bourne shell syntax, andwhile ~ do ~ done
is correct. I can fix this right away. Are there any historical citations on whydone
as used? The Bourne's originalmac.h
file uses both, eg.
FOR ~ DO ~ OD # for loop # WHILE cond DO ~ OD # early termination loop # REP ~ PER cond DONE # late termination loop # LOOP ~ POOL # infinite loop #
- Re:
$*
vs"$@"
- Makes me wonder if Bourne built in
$@
originally, or it was added as an enhancement. I see a lot of $* in code even today that should be "$@". Was "$@" apart of the original design, or an enhancement? Need to check the original source tree somehow... I wonder if is still compiles... :-) (BTW IIRC csh used $*:q for "$@") --NevilleDNZ 12:48, 10 September 2006 (UTC)
- $@ has been introduced in 1986 with SVr3 (see main article). --Schily (talk) 10:28, 28 June 2012 (UTC)
- I wouldn't say it was over-kill, but it sounds like it would be difficult to research and cite, since most of those changes are by definition closed and binary. -- Gwern (contribs) 22:47, 10 September 2006 (UTC)
- The "do" "od" dialect probably came from Algol 68, for what it's worth. Algol 68 also used while elihw, if fi, and case esac. --Tony Sidaway 13:38, 18 January 2008 (UTC)
Descendants
[edit]I removed the paragraph under Descendants which talks about the C shell, because it's not a descendant of the Bourne shell (it ran The C shell (csh), derived not from the Bourne shell but the Thompson shell,&hellip). I incorporated the relevant (and only the relevant) context into the Korn shell's description; also improving the style somewhat. I hope it works for you. --Rfsmit (talk) 21:14, 21 July 2008 (UTC)
Not really about the Bourne shell?
[edit]Should this page be retitled: Bourne shell; a history or Bourne shell; background?? and a link added to a page that actually talks about what the Bourne shell is/does? DGerman (talk) 14:29, 29 January 2009 (UTC)
- What do you think should be in this article that isn't? Bear in mind that this is an encyclopedic article about the Bourne shell and not a Bourne shell tutorial or technical reference as per WP:NOTHOWTO. This article is certainly not perfect but it puts the shell in historical context and describes new features and language constructs with this shell. I don't think a comprehensive listing of all language cosntructs is particularly merited here: that is better off in a Bourne shell reference guide or tutorial. CrispMuncher (talk) 19:41, 29 January 2009 (UTC)
question...
[edit]Bourne called them "shell procedures" not "shell scripts". Should this article follow his terminology? Geo Swan (talk) 04:29, 1 February 2009 (UTC)
Screenshot of another shell?
[edit]This article about sh starts with a screenshot of another shell, bash. Although the article claims that bash is a clone of sh (I do not agree), would it not be more enlightening to have instead a screenshot of the same program as is discussed in the article? For instance, the standard prompt in sh is "$", while in bash it is "user-name@host-name:/the/current/dir$". Also, colorisation by default is very uncommon for sh in my experience. To me, this is much like having a picture of a SAAB car in an Opel article, although you could claim that modern SAABs are simply Opel-clones (since many parts are compatible). 83.209.89.69 (talk) 20:08, 27 June 2010 (UTC)
- agree - the example is off-topic. Not everything needs a picture, anyway. Tedickey (talk) 20:19, 27 June 2010 (UTC)
- Okay, I'm the culprit who did this, so perhaps I should explain both why I did it and why I've now undone it. This screenshot appeared on the Unix shells page. I thought it was pretty unattractive and not very helpful because it didn't show how shell windows appear on a typical desktop. I replaced it there with a screenshot of sh and tcsh windows running under Mac OS X. So what to do with the ugly screenshot? I first thought about moving it lower on that page but then thought, better still, why not just move it to the sh page. Okay, I hear you. Bad idea. My apologies. That said, I do think a good screenshot would be helpful and if someone has something better, I hope they'll post it. Msnicki (talk) 20:41, 27 June 2010 (UTC)
- I have to agree with tedickey - I don't think a picture is called for. Shells are fundamentally textual rather than graphical and any screen shot is going to be of a termianl emulator rather than the shell itself. Crispmuncher (talk) 14:29, 28 June 2010 (UTC)
- Okay, but imagine someone asking what sh is or does if you have a machine handy that runs sh. Wouldn't you do something to demonstrate it? Maybe you'd ls the desktop directory to show you get at the same stuff through the shell. Maybe you'd demo something iterating over a set of wildcard matches. You would do something very simple, very clear to show what it looks like and what it does. Can we grab that image? What I never liked about the bash screenshot was that it was just so random! It was a random snapshot of a random bash session, looking over the shoulder of someone who liked really ugly colors doing who-knows-what. A good picture can teach something, it can make things tangible. I think if you have one that's well thought-out, it helps. But I'm way more a csh person than an sh person (which is part of why I backed off so quick,) so again, I apologize for the misstep. Do what you think is right. Regards. Msnicki (talk) 16:40, 28 June 2010 (UTC)
Scripts invoked by filenames
[edit]The list of features currently includes "Scripts can be invoked as commands by using their filename". Was this a feature of the Bourne shell, or of the Unix kernel? In modern Unices it's certainly a kernel feature. Qwertyus (talk) 22:04, 2 February 2011 (UTC)
- Both is wrong.... Scripts that start with #!/path/to/interpreter are handled by most kernels, other scripts are handled by the shell. --Schily (talk) 23:35, 2 February 2011 (UTC)
License
[edit]Solaris distributes a version of the Bourne shell using CDDL. However, the license as cited in this topic probably should reflect that of whoever is the owner of the legacy AT&T code. That's probably not Oracle/Sun. TEDickey (talk) 10:49, 28 March 2011 (UTC)
- I believe we should explain AT&T Bourne shell here. Anything else is either a fork, or reverse engineering. Zsh is not a version of bash. ReactOS is not a version of Windows. We could of course add a section about the forks. Luhanopi (talk) 16:53, 18 August 2024 (UTC)
well freeBsd has version the bourne shell under bsd lisence --82.44.40.210 (talk) 14:37, 28 May 2011 (UTC)
- There are several (re)implementations, with differences... TEDickey (talk) 14:41, 28 May 2011 (UTC)
- I doubt Solaris distributes a version of the Bourne shell. I removed the license until a reference is provided. --Chealer (talk) 05:59, 21 March 2012 (UTC)
- Doubt is not a useful method for an encyclopedia. The right method is to write provable facts. The only way to prove in case of sh is to look into the sourcecode. SunOS-2.0 came with a Bourne Shell that did not yet support functions. SunOS-3.0 came with an updated Bourne Shell with function support and without the Pascal style code. SunOS-5.x comes with a renewed version that includes NLS / i18n support. Given the fact that the caldera historic UNIX license does not cover the Bourne Shell with function support, the only publically and legally available version is the version published by Sun under the CDDL. I urge you to currect your incorrect edit. --Schily (talk) 11:23, 21 March 2012 (UTC)
- Hi Schily, I did not write anything in the article, I only removed the unsourced part claiming the Bourne shell was licensed under the CDDL. "Looking into the sourcecode" is not the way Wikipedia works, see Wikipedia:No original research. --Chealer (talk) 19:27, 21 March 2012 (UTC
- No, you removed a proven statement. It seems that you missinterpret the way WP works. WP of course does not require to give on-line provable facts, a named book or a named closed source is sufficient. In case of the Bourne Shell, we fortunately have something to prove on-line: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/sh/stak.c verifies that the CDDL applies and if you are unable to recognise that this is the Bourne Shell, you are just not the right person to judge. You claimed that the Bourne Shell is not available under the CDDL and this has been disproven. I urge you to fix your edit mistake. --Schily (talk) 22:01, 21 March 2012 (UTC)
- No - you're stating something is not supported by WP:RS. The only likely source in OpenSolaris for "Bourne Shell" looks to be the CPL-licensed code. You should be more familiar with the code base than that. By the way, attacking other editors is uncivil. TEDickey (talk) 22:56, 21 March 2012 (UTC)
- So you are obviously missing the needed skills to discuss this topic. Have a nice day. --Schily (talk) 23:13, 21 March 2012 (UTC)
- "Looking into the sourcecode" would not be of help here, since no part of Schily's comments can be supported by looking there. Perhaps there is a WP:RS relating to the issue, but none has been offered for consideration in more than a year. TEDickey (talk) 20:32, 21 March 2012 (UTC)
- There is more than one shell in Solaris. A quick check (on opensolaris.org) shows a "sh" marked CDDL. However, its relationship to Bourne Shell is unclear (dubious). There is a different "sh" with Bourne's name in the comment headers, which is marked CPL. In either case, OpenSolaris' source history doesn't go back nearly far enough to make statements of this sort more than guessing TEDickey (talk) 08:59, 21 March 2012 (UTC)
- As noted, there are several implementations. The version on OpenSolaris derived from Bourne's source (see above) is from AT&T, using CPL. The licensing of other vendor's implementations (whether derived or not) varies. WP:RS is the place to start, rather than random unsourced personal opinions TEDickey (talk) 10:47, 22 March 2012 (UTC)
- As noted already, your recent statements verify that you either write intentional nonsense or that you have a very poor level of programming knowledge. The fact that you claim to see the "Bourne Shell" in sources that have "ksh" in the files path names and that contain the tags "Korn Shell" and "David Korn" disqualifies you as a credible discussion partner. And BTW: I don't like your unfriendly tone. --Schily (talk) 12:31, 22 March 2012 (UTC)
- There is no "ksh in "http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libshell/common/sh/main.c", and the comment header states clearly
/*
- There is no "ksh in "http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libshell/common/sh/main.c", and the comment header states clearly
22 * UNIX shell 23 * 24 * S. R. Bourne 25 * Rewritten By David Korn 26 * AT&T Labs 27 * 28 */
- Likewise, the link that you added does not provide similar information, and as others will note, I've pointed out that there are different implementations, none of which has been cited using a reliable source to be the Bourne shell discussed in this topic. Your repeated personal attacks are the only notable thing about your comments TEDickey (talk) 22:37, 22 March 2012 (UTC)
I've given a reliable Source. Any person with some minimal basic knowlege in UNIX history or with minimal programmings skills will be able to understand that in contrary to you, I pointed to the Bourne Shell source. But even if both skills are missing, people who run a halfway POSIX compliant OS could compile the sources and check the behavior. And everybody who is able to compile, could run the Bourne Shell and compatible test script from http://www.in-ulm.de/~mascheck/various/whatshell/whatshell.sh to discover what shell he is using.
The Korn Shell is an halfway incompatible fork on the Bourne Shell source that started in 1982. I know of no serious person that would call the Korn Shell "a minor variant" of the Bourne Shell. Besides the Korn history editor, the main difference between Bourne Shell and Korn Shell is pipeline execution order. Korn Shell prints "test" with:
echo test | read var echo $var
while Bourne Shell prints an empty line. Sources published by AT&T after aprox. 1984 do not include the "S. R. Bourne" tag in either Bourne or Korn Shell. Korn Shell sources that directly come from David Korn still have that tag but nobody would see this as an indication for seeing the Bourne Shell itself.
Regarding Licensing: Modern (function supporting) versions of the Bourne Shell have been closed source until Sun published a recent Bourne Shell under CDDL in June 2005. No other OSS license applies to such a Burne Shell variant. AT&T gave the OK for putting ksh93 under CPL in 2001. Before, the Korn Shell (but not the Bourne Shell) was availabe under a non-OSI compliant license for a few years (IIRC since 1997).
The advanced and portable version of the Bourne Shell that I publish since 2006 has been derived from the only legal OSS source at: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/sh It adds the interactive shell history editor, I wrote in 1982-1984 for my private shell independently from David Korn.
The problem I see frequently with you is that you are missing the needed skills to be able to discuss a topic but still act as if you were the only person on the planet that knows things right. Together with your agressive discussion style, this creates a bad taste. I encourage you to behave more cooperative to avoid unneeded disputes. --Schily (talk) 15:06, 23 March 2012 (UTC)
- As usual, you make several statements, providing no source aside from your assertions (the link is irrelevant, since what you say about it requires some WP:RS which is absent from the discussion as yet). TEDickey (talk) 00:36, 24 March 2012 (UTC)
- You unfortunately still ignore proven facts and you still personally attack people. It is a proven fact, that a recent source version of the Bourne Shell (with functions (introduced with SVr2), job control (introduced with SVr4) and internationalization+wide char support (introduced with Svr4)) is available under the CDDL. If you believe that there other legal ways to get a recent Bourne Shell source, you are free to present us your information for verification. --Schily (talk) 14:13, 3 April 2012 (UTC)
- The apparent motivation for Schily's edits is this activity TEDickey (talk) 20:34, 20 April 2012 (UTC)
Meaning no slight to Schily, I wish to point out that his historical account errs in suggesting that Caldera International's 2002 release of many releases of historical Unix through 1979's v7 and 32V doesn't include Bourne shell. It doubtless was ridiculously antique, poorly portable, and in K&R rather than ANSI C, but I'd be extremely surprised if it weren't the real Stephen Bourne codebase in all its 1970s (obsolete) glory -- and under Caldera's BSD-ish licensing terms. This history can be traced through the Heirloom Bourne Shell repository. ~~ unixguy — Preceding unsigned comment added by 198.144.195.190 (talk) 08:48, 9 August 2016 (UTC)
- Who claimed that the Bourne Shell sources are not in v7?
- The Bourne Shell development started in 1976 but did not end. There have been many enhancements that are not yet in the code that is available under the caldera license:
- Built-in test command – System III shell (1981)
- # as comment character – System III shell (1981)
- Colon in parameter substitutions "${parameter:=word}" – System III shell (1981)
- continue with argument – System III shell (1981)
- cat <<-EOF for indented here documents – System III shell (1981)
- Functions and the return builtin – SVR2 shell (1984)
- Built-ins unset, echo, type – SVR2 shell (1984)
- Source code de-ALGOL68-ized – SVR2 shell (1984)
- Modern "$@" – SVR3 shell (1986)
- Built-in getopts – SVR3 shell (1986)
- Cleaned up parameter handling allows recursively callable functions – SVR3 shell (1986)
- 8-bit clean – SVR3 shell (1986)
- Job control – SVR4 shell (1989)
- Multi-byte support – SVR4 shell (1989)
- Added UTF-8 support - Solaris shell (1993)
- Added support for --long options with getopts - Solaris shell (1999)
- History editor added - Schily Bourne Shell (2006)
- Made fully portable by using malloc() instead of sbrk() - Schily Bourne Shell (2012)
- Added support for aliases, persistent aliases and parameterizable aliases - Schily Bourne Shell (2012)
- Added pushd/popd/dirs - Schily Bourne Shell (2012)
- Support for set -o longopt - Schily Bourne Shell (2012)
- Support for read -r was added - Schily Bourne Shell (2012)
- New builtins find, pgrp, killpg, repeat, errstr - Schily Bourne Shell (2015)
- New parser for optimized pipes and vfork() support - Schily Bourne Shell (2015)
- Added support for pipes on alternate file descriptors - Schily Bourne Shell (2015)
- Added support for set -o noclobber and set -o bgnice - Schily Bourne Shell (2015)
- Added support for the reserved words ! and time - Schily Bourne Shell (2015)
- Added support for all 32 bits from the exit(code) on POSIX compliant platforms - Schily Bourne Shell (2015)
- Added support for simplified raw editing of aliases that need quoting using hashcommands - Schily Bourne Shell (2015)
- Added support for long options that are not an alias of a short option and -long options to getopts - Schily Bourne Shell (2015)
- Added support for the select keyword - Schily Bourne Shell (2016)
- Added support for function local variables - Schily Bourne Shell (2016)
- Added a POSIX compliant printf builtin - Schily Bourne Shell (2016)
- Added support for $(cmd) and $((arith)) - Schily Bourne Shell (2016)
- Made fully POSIX compliant - Schily Bourne Shell (2016)
- Works as Gentoo system shell (/bin/sh) - Schily Bourne Shell (2016)
If you like features from above, there is only one license that gives you access, the CDDL.
BTW: The history cannot be traced in the so called heirloom shell as this shell just started with the OpenSolaris sources with no history inside and stopped all activities after approx. 6 months, before becoming fully portable. Because it is full of bugs, you do not really like to use the heirloom shell. Schily (talk) 11:50, 9 August 2016 (UTC)
I believe the matter under discussion is what the licence of the legacy AT&T Bourne shell code is/was. This Wikipedia article overwhelmingly concerns the historic shell as it existed in primordial Unix times up through, say, SysV release 4.x, which, with all due respect to noble attempts to update the code such as Schily and his CDDL posse, is IMO the last time (nearly) anyone actually cared about the Bourne shell except as the inspiration for ksh, bash, ash/dash, and the POSIX shell spec. Thus the article's use of the past tense through essentially all of the article's main text. Thus, I submit that the correct licence to cite for this article is what Schily calls the 'Caldera license', which close inspection reveals to be a verbatim application of the 4-clause BSD license. ~~unixguy — Preceding unsigned comment added by 198.144.195.190 (talk) 09:05, 12 August 2016 (UTC)
- So you like to reduce the bash (Unix shell) article to only mention what has been available in 1989? This is nonsense and it seems that you are intending to create a farce. The Bourne Shell article describes the Bourne Shell in it's whole life cycle and nobody is interested whether the initial sources can be retrieved under a OSS license as the initial sources will not compile on any recent OS. People who are interested in the source code of course are interested in code that compiles on recent UNIX and this requires the CDDL. This is of course of interest in special as e.g. ash and dash are less close to POSIX than the recent Bourne Shell. Also note that even though dash is claimed to be fast, it is slower than the recent Bourne shell on Solaris. And as you don't seem to know it, ksh is based on the Bourne Shell sources. Schily (talk) 14:42, 12 August 2016 (UTC)
Claiming that my logic means the bash article should 'mention only what has been available in 1989' is making a blatantly non-sequitur appeal, as (obviously) said article does not concern the historic initial state of Mr. Brian Fox's contribution to the GNU Project -- as witness the fact that its Wikipedia page, by contrast, is phrased in the present tense. Essentially, by ignoring the substance of what I said and raising irrelevancies such as the gratuitous assertion about ksh, you are conceding the point (but continuing to argue anyway). Ah well. So, volunteers of the Wikipedia Project: There is your answer, and I'd recommend you cease wasting time arguing with Schily and (enfin) change the Article text from 'Under discussion' to '4-clause BSD'. That should then free up energies for more fruitful matters. ~~unixguy — Preceding unsigned comment added by 198.144.195.190 (talk) 17:21, 13 August 2016 (UTC)
Date
[edit]The article mentions that "It was released in 1977 in the Version 7 Unix release", however the Version_7_Unix article states that Version 7 Unix was released in 1979. Not both are right, or there is a trick. DelTree (talk) 12:50, 30 January 2012 (UTC)
- 1977 may be wrong, the oldest date that can be found in a sh source is 1978. --Schily (talk) 10:22, 7 May 2012 (UTC)
- Stephen Bourne claims that the Bourne Shell development started in 1976 and resulted in a first usable version at that time Schily (talk) 14:42, 7 June 2016 (UTC)
- Schily, usable version means nothing when it comes to release time. Uziel302 (talk) 11:00, 4 December 2019 (UTC)
Criticism section
[edit]It does not sem to be serious to have a "Criticism" section that looks as it if has been written in early 1981 and assumes for correctness that we still are in 1981.
Today in 2012, the test utility is a built-in command since 31years.
Functions (that can act as aliases) are in the Bourhe Shell since 28 years.
Job Control is in the the Bourne Shell since 23 years.
A History and a command line history editor (which is more than csh had in 1981) is in since 5.5 years.
In other words, most of the features have been in the Bourne Shell before bash exists. Also the csh syntax not really a C-derived syntax either. Csh did offer a few features that help in interacetive use while the Bourne Shell has been written to be usable for interactive use and for scripts. --Schily (talk) 13:02, 12 May 2012 (UTC)
- I had some concerns about the criticism section, so I added a POV-section tag to it. Specific issues include the phrasing "Even simple arithmetic" [emphasis mine] which suggests a judgment. Also, I believe the criticism about ALGOL-like structure refers to the source code that Mr. Bourne wrote the shell program in, not to anything that a user of the shell would see.
- To frame the conversation positively rather than focusing on problems, I would say I have doubts about this section's encyclopedic value. It seems to me that that some editing to make it more focused on the facts would also address the POV concerns. Certainly some of this info is valuable in terms of comparing Bourne shell to more modern shells. Leoger (talk) 04:57, 17 February 2014 (UTC)
Successor of which shell?
[edit]The introduction says that the Bourne shell "was a replacement for the Thompson shell", and the Origins sections says that "The shell was designed as a replacement for the Mashey shell." So which is it? Teemu Leisti (talk) 08:18, 4 January 2013 (UTC)
I came here to say the same thing, 8 years later -- andrewh — Preceding unsigned comment added by 167.179.152.63 (talk) 05:06, 14 December 2020 (UTC)
Learning Bourne shell
[edit]Should good places to learn the Bourne shell be a separate article?
A class given at UC Berkeley by Michael Paoli has a concise reference to learning the shell. http://www.rawbw.com/~mp/unix/sh/ From experience teaching scripting he recommends starting with the six page 1979 sh man page! http://plan9.bell-labs.com/7thEdMan/v7vol1.pdf
Another good answer for where beginners might productively start seems to be the "Advanced Bash-Scripting Guide" http://tldp.org/LDP/abs/html/ which despite the title doesn't start at the Advanced level. Advanced is where you will end up after reading it. — Preceding unsigned comment added by Grantbow (talk • contribs) 09:45, 31 March 2013 (UTC)
Shell compatibility and Unix compatibility in general
[edit]First of all, I was under the mistaken (understandable?) impression that the Bourne shell was the original. I knew however that some systems substitute dash for sh (compatible) I think for programs. And I knew that user shells are selectable. Now my question is, is there a minimum amount of shell functionality that has been supported (and still is supported) in the "first considered" Unix shell? I know about the previous Thompson and PWB shells (are they the only previous shells?). Are they not considered Unix (anymore)? lintsh (should it be mentioned in the page?) inticates they are not important (or the Android shell?).
My (challenged) view is that "the shell" is not part of "Unix" for interaction by the user. That is the first component of compatibility, then there is also the "program behavior" of compatibility that I also think is essential to Unix compatibility. comp.arch (talk) 16:04, 22 July 2014 (UTC)
- lintsh does not exist. The only approach you can do is to find a portable version of the oldest Shell you like to support and then test your script using this variant of the shell.
- The oldest shell supported via autoconf-2.13 is the Bourne shell from 1982 that does not yet include functions. But this is more than 30 years ago. What is the oldest System you expect to support?
- If you are OK with the Bourne Shell from SVr4 (OpenSolaris) that represents the feature development state from around 1990 + some bug fixes, you may like to check http://sourceforge.net/projects/schilytools/files/ and use the binary "osh" that is the unenhanced ported version of the SVr4 Bourne Shell. Schily (talk) 16:34, 22 July 2014 (UTC)
- @Schily:, thanks for answering, but "lintsh does not exist" - a misunderstanding? Note it's not a shell, see link. Is the bourne shell generally considered the "oldest Unix shell"? Not just supported currently. I mean, the older two (more?) are they considered a historical curiosity from Ancient Unix? comp.arch (talk) 11:49, 23 July 2014 (UTC)
- "Unix was originally written in assembly language.[6] Ken Thompson wrote B, mainly based on BCPL, based on his experience in the MULTICS project. B was replaced by C, and Unix, rewritten in C" - portability has been one of the major point of Unix (the OS itself, and at least some subset of (conformiing) programs). Obviously this doesn't apply to apply to the assembly version (for 18-bit PDP-7!). Can you write a portable script all the way back to the very first Unix (or even Multics?)? [The actual C-programs wouldn't work (as Unix older than C)?!] What would that subset of shell functionally to be (Turing complete?)? I'm also considering actual shell interaction. If what is only portable in incoking program, that is not meaningfully differenct from say DOS.
Pipes are as old as Unix(not in Thompson, nor scripting - that version not considered a first shell/Unix?) shell at least (and more powerful than in DOS, way back then?)? comp.arch (talk) 12:15, 23 July 2014 (UTC)
- "Unix was originally written in assembly language.[6] Ken Thompson wrote B, mainly based on BCPL, based on his experience in the MULTICS project. B was replaced by C, and Unix, rewritten in C" - portability has been one of the major point of Unix (the OS itself, and at least some subset of (conformiing) programs). Obviously this doesn't apply to apply to the assembly version (for 18-bit PDP-7!). Can you write a portable script all the way back to the very first Unix (or even Multics?)? [The actual C-programs wouldn't work (as Unix older than C)?!] What would that subset of shell functionally to be (Turing complete?)? I'm also considering actual shell interaction. If what is only portable in incoking program, that is not meaningfully differenct from say DOS.
- I'm not expecting to support anything, just considering portability, say now we take UTF-8 for granted, that is however not in the minimal Unix subset, but 7-bit ASCII is a part of it. I'm not even sure you would use that in portable Unix? One of the core principle of Unix to me are strings of bytes (files). As first use was 18-bit, was the byte 18/3=6 bit then? C(?)/POSIX now requires the byte to be at least 8-bit but C didn't at the time. comp.arch (talk) 12:34, 23 July 2014 (UTC)
- Pipes are not in UNIX since for ever, they have been invented in 1974. I was in a talk from Steve Bourne where he explained what happened when they invented the Pipes...
- Note that UTF-8 can definitely not be assumed, the most frequently seen coding on UNIX is still ISO-8859-1. UTF-8 is something "very new" (introduced past 1995).
- Today, nobody needs to be compatible to the Tompson shell or the Mashey shell.
- It seems that the portable Bourne Shell is a good test candidate. Note that "lintsh" is planned but does not exist, so the only option you have may be to test against the portable Bourne shell Schily (talk) 14:32, 23 July 2014 (UTC)
- Ok, thanks. Were these Thompson and Mashey the only pre-Bourne shells? And not really considered part of Unix(-like) according to Unix philosophy? Do you consider Unix-compatibility different from shell-compatibility. I'm not sure but shell-compatibility could be older, that is, a given C program can be made pretty portable for running on a pretty old Unix (up to almost newest one? - those having C compiler, first Unix is older than C, but was a C compiler made that old hardware it ran on?). If there is a Turing compatible subset of shell features in Bash (or older) that runs on previous shells, shell programs could run on Unix down to Mashey-shell?
- Or did Unix in a way kind of "start" with Bourne? Around V7? Everything else considered Ancient and not thought of for compatibility reasons? Are C program to Unix API the oldest compatible versions og Unix programs? Runnable individually but not from a shell. Could be..
- I assumed time sharing had also always been in Unix, but not so.. I guess pipes as in Unix (not DOS) depend on multitasking that's basically implied by time sharing.
- In a trivial sense I assume running a single (or series) program was available in the early shells from the keyboard. At least Thompson didn't have scripting. What they mean with no scripting could be not from a file or in general? (and #/bin/sh convention started with - I guess Bourne, and no other previous shells had similar?). PWB/Mashey: "The if and goto commands were made internal to the shell" (as in from the keyboard only not in files?). Seems enough for Turing complete.. and you could make scripts then in that shell that are forward compatible to Bourne? Or was it a different syntax? And confused about "made internal" - for scripts? I'm confused how that would work.. (know about /bin/true and /bin/false however). comp.arch (talk) 17:55, 23 July 2014 (UTC)
- I know with UTF-8 (can be relied on now, unless running really old software), but ISO-8859-1 is also "new". That is newer than 7-bit ASCII. Unix doesn't care too much about 8-bit codepage (multi-byte I assume later, and then UTF-8). But The byte has not always been 8-bit so ISO-8859-x wouldn't have worked.. But maybe not even 7-bit ASCII was my point? Maybe only six-bit character code was relied on? Not that I can find, C is/was portable to 6-bit, and OSes that use I guess, Unix might have started with 7-bit ASCII.. 18öbit word PDP-7 can be dived in 9-bit, maybe that was it for C's byte there.. Anyway this is not too important.. comp.arch (talk)
- "8-bit clean – SVR3 shell (1986)" means? To me it implies 7-bit ASCII was used (if that to begin with). I see now, much of what you take for granted (because the other shells died..) in shells/Unix (environment variables, comments). While the shell is 8-bit clean does if just support 8-bit charsets but also 7-bit systems/charsets? Or are non-8-bit byte systems now excluded? comp.arch (talk) 10:23, 25 July 2014 (UTC)
- 8-bit clean means that the shell no longer uses the top bit of a 8-bit character to code this character as a quoted char. In 1986, ISO-8859-1 did become popular and was desired by people outside the USA- Support for multi byte chars was added in 1990 with SVr4 changes. At that time there still was no UTF-8 but AT&Ts EUC. Schily (talk) 10:45, 25 July 2014 (UTC)
- Thanks, knew that, redirecting this specific question (not shell compatibility in general) to Talk:18-bit. Old-timers might know there. comp.arch (talk) 12:03, 25 July 2014 (UTC)
- 8-bit clean means that the shell no longer uses the top bit of a 8-bit character to code this character as a quoted char. In 1986, ISO-8859-1 did become popular and was desired by people outside the USA- Support for multi byte chars was added in 1990 with SVr4 changes. At that time there still was no UTF-8 but AT&Ts EUC. Schily (talk) 10:45, 25 July 2014 (UTC)
- "8-bit clean – SVR3 shell (1986)" means? To me it implies 7-bit ASCII was used (if that to begin with). I see now, much of what you take for granted (because the other shells died..) in shells/Unix (environment variables, comments). While the shell is 8-bit clean does if just support 8-bit charsets but also 7-bit systems/charsets? Or are non-8-bit byte systems now excluded? comp.arch (talk) 10:23, 25 July 2014 (UTC)
- I know with UTF-8 (can be relied on now, unless running really old software), but ISO-8859-1 is also "new". That is newer than 7-bit ASCII. Unix doesn't care too much about 8-bit codepage (multi-byte I assume later, and then UTF-8). But The byte has not always been 8-bit so ISO-8859-x wouldn't have worked.. But maybe not even 7-bit ASCII was my point? Maybe only six-bit character code was relied on? Not that I can find, C is/was portable to 6-bit, and OSes that use I guess, Unix might have started with 7-bit ASCII.. 18öbit word PDP-7 can be dived in 9-bit, maybe that was it for C's byte there.. Anyway this is not too important.. comp.arch (talk)
Contradictory Information?
[edit]After having a quick read through the page I seem to have found a small discrepancy seen below:
Developed by Stephen Bourne at Bell Labs, it was a replacement for the Thompson shell...
The shell was designed as a replacement for the Mashey shell.
We should probably research this and seen which once is actually correct. Else, if it was created to replace both the Thompson and Mashey shell that should be made more clear. Else, if is was designed to replace the Mashey shell, but in reality it actually replaced the Thompson shell, then that also should be more clearly stated. -bsimmons 216.249.42.52 (talk) 13:33, 29 September 2014 (UTC)
.sh file extension
[edit]The Wikipedia ".sh" article says
- For the .sh file extension type, see Bourne shell.
I don't see ".sh" anywhere in this Bourne shell article. Is there a gap in the coverage of this article -- should it say something about ".sh"? Or should the ".sh" article point to some other article that mentions ".sh", perhaps shell script? --DavidCary (talk) 12:38, 19 June 2015 (UTC)
- The extension .sh is usually used in source trees and a makefile copies file.sh to file as part of the build process. Schily (talk) 12:01, 22 June 2015 (UTC)
- Dear Schily and other readers,
- Do you know of any WP:SOURCE or even a weblink to a particular source tree or Makefile that works in that way?
- Not one of the last 5 Makefiles or source trees I looked at had even one file with the ".sh" extension. But I realize that the customs of my tribe and island are not the laws of nature, and so I look forward to learning more about other ways to set up a build processes. --DavidCary (talk) 03:08, 24 June 2015 (UTC)
- A related default rule is in UNIX make(1) since ages. See e.g. the SunPro make sources: [1] in the files Make/bin/make/common/default.mk.file, Make/bin/make/common/make.rules.file and Make/bin/make/common/svr4.make.rules.file. Schily (talk) 10:35, 24 June 2015 (UTC)
- We've examined this source before, and found that it lacks the details which you suppose it supplies. TEDickey (talk) 23:18, 24 June 2015 (UTC)
- Again: do not use majestatis pluralis and provide sources for your claims. Schily (talk) 08:32, 25 June 2015 (UTC)
- Your term does not appear to be used in that form often (https://de.wikipedia.org/wiki/Pluralis_Majestatis). The modification date for the cited file is 2006; there is no change history available, so any comments you make about the age of a given feature have no support from that source. Perhaps you can find a usable source, but that is not. In previous discussion of the source, you also made unsupportable claims, and failed to followup with any usable sources. So I conclude that you have none. TEDickey (talk) 23:58, 25 June 2015 (UTC)
- You still don't seem to understand how reliable sources work. Reliable sources do not need to be available on-line and for everyone. They just need to be provable. I have reliable sources to prove my claims and if you come here to meet me, I am of course able to show you my sources. I wish you had reliable sources for the various claims you place in Wikipedia. Schily (talk) 09:32, 26 June 2015 (UTC)
- There is a built-in rule for GNU make which is directly relevant to the comment. Quoting from its Catalogue of Built-In Rules:
For the benefit of SCCS, a file n is copied from n.sh and made executable (by everyone). This is for shell scripts that are checked into SCCS. Since RCS preserves the execution permission of a file, you do not need to use this feature with RCS.
- That can be a nuisance if distributing a file named install.sh, which is why you may find files named install-sh, e.g., this used in Lynx for the reason noted in the script's comments. TEDickey (talk) 08:54, 24 June 2015 (UTC)
- It seems that GNU make documentation was not updated since 29 years: SCCS preserves the executable bit since a long time... mmm it seems this is longer than GNU make exists ;-) Schily (talk) 10:06, 24 June 2015 (UTC)
- Again, you do not provide a source for discussion purposes, so you've said nothing of value TEDickey (talk) 23:18, 24 June 2015 (UTC)
Date?
[edit]The article Bourne shell states that the Bourne shell was released in 1977, but the article Thompson shell states that the Bourne shell was released in 1979. Can anyone provide a reliable source settling the matter? The editor who uses the pseudonym "JamesBWatson" (talk) 16:29, 27 November 2015 (UTC)
- Stephen Bourne claims he started with the shell in late 1975 and deployed the first version in early 1976. Then a period of time, the result was tested, discussed and modified. His feature list from 1977 looks pretty complete. Schily (talk) 17:04, 27 November 2015 (UTC)
- I suppose there could be room for different interpretations of what "released" means, since if it was gradually developed over the course of several years, it could have gradually spread to a wider audience, rather than there being one date when it was suddenly made public. However, a source giving clearer information as to when it became generally available would be welcome. The editor who uses the pseudonym "JamesBWatson" (talk) 09:05, 28 November 2015 (UTC)
- Then the "release time" for UNIX could be much later than what people believe today as e.g. Stephen Bourne claims that 1975 was the first year when UNIX was used outside USG. Schily (talk) 17:36, 23 February 2016 (UTC)
- I suppose there could be room for different interpretations of what "released" means, since if it was gradually developed over the course of several years, it could have gradually spread to a wider audience, rather than there being one date when it was suddenly made public. However, a source giving clearer information as to when it became generally available would be welcome. The editor who uses the pseudonym "JamesBWatson" (talk) 09:05, 28 November 2015 (UTC)
- C-Class Linux articles
- Mid-importance Linux articles
- WikiProject Linux articles
- C-Class software articles
- Low-importance software articles
- C-Class software articles of Low-importance
- C-Class Computing articles
- Unknown-importance Computing articles
- All Computing articles
- All Software articles
- Low-importance Computing articles
- Mid-importance software articles
- C-Class software articles of Mid-importance
- C-Class Early computers articles
- High-importance Early computers articles
- C-Class Early computers articles of High-importance
- C-Class Free and open-source software articles
- Mid-importance Free and open-source software articles
- C-Class Free and open-source software articles of Mid-importance
- All Free and open-source software articles