Talk:Hamilton C shell

COI Declaration

As the creator of this article, I am declaring an unspecified but significant conflict of interest that may cause me to be favorably biased. I promise to do my best to write in a strict neutral point of view, properly sourcing everything. But the thing about bias is that we may not realize when we're exhibiting it or we wouldn't do it. So I would appreciate the help (and healthy skepticism) of other editors to check my work.

Though I am declaring a COI on this page, I ask that you respect my wish to remain otherwise anonymous. Msnicki (talk) 18:29, 21 April 2011 (UTC)

I'm glad the G11 issue was resolved in a sensible manner. Tijfo098 (talk) 12:34, 22 May 2011 (UTC)

Discussion requested

I disagree with Qwertyus's edit here removing a fair amount of content, arguing that the WP:SPS sourcing, e.g., of what the author was thinking, was inappropriate but I concede Qwertyus is correct in arguing that I have a WP:COI, declared above. I think it is fair for me to ask for more discussion but beyond that, I need to step back and accept whatever consensus is reached. Consequently, I've posted invitations for comment on the Talk:C shell [1] and Talk:Bash (Unix shell)[2] pages. This is the last of what I will have to say on the question. I am committed to and respect our process and the outcomes of consensus. Msnicki (talk) 20:16, 17 November 2015 (UTC)

I am not sure about the main cause for the disagreement, but claims like "development was completely independent from..." is hard to prove for a closed source project.

See e.g. the "GNU emacs" that was derived from the Gosling Emacs and currently GNU emacs people claim that the code was completely rewritten. The screen update output from the GNU emacs however still shows the same kind of inefficiency as the original Gosling emacs that results from the fact that the Gosling code was initially written for an ASCII art editor. Schily (talk) 22:33, 17 November 2015 (UTC)

For that specific claim, we have "The company claims that all 42,000 lines of code in the product were written specifically for OS/2" (Byte, 1989), so it could be reinserted with a hedge (although the word "clone" gets the idea across enough, IMHO). A more important problem was that the rest of the article dwelt on implementation details with references to Usenet postings by the authors (forbidden by WP:PRIMARY, which requires "reputably published" primary sources and only for "facts that can be verified by any educated person with access to the primary source but without further, specialized knowledge"). QVVERTYVS (hm?) 22:46, 17 November 2015 (UTC)

I think I can comment on the guidelines. The requirement in WP:PRIMARY is that anyone should be able to read the primary source and easily determine that it says what is claimed in the article. There's no interpretation, only "straightforward, descriptive statements of facts" that anyone who reads the article would easily agree is what it says. The "source" referred to in WP:PRIMARY is the source being cited, not the C language source for the product being described in that cited primary source. Msnicki (talk) 00:26, 18 November 2015 (UTC)

You're putting the policy on its head. It speaks of verifying facts, not verifying that the source is correctly cited. QVVERTYVS (hm?) 09:15, 18 November 2015 (UTC)

If a source states a claim as a straightforward, descriptive statement of fact, that does verify it. As examples of how we commonly use primary and self-published sources to support non-controversial claims in exactly the way it was done in this article once notability has been established, consider the numerous WP:SPS sources offered to support similar detailed claims in Go (programming language), Bash (Unix shell), GNU Compiler Collection or even Microsoft Windows. "Reputably published" isn't defined but clearly, we accept that when authors or publishers talk about their own work, we expect that they know what they're talking about so long as they confine themselves to these straightforward descriptions of fact. If someone is known to be the author of a work, we accept that they have the requisite reputation to make reliable statements about how it works, even if self-published. That's true whether it's Microsoft talking about their Windows product, GNU talking about their compilers or golang.org talking about their Go language. It should be true here as well. An WP:SPS source only fails to be reputably published for this purpose if the authenticity is uncertain (e.g., we can't be sure who wrote it) or if the source is someone other than the author talking about their own work, someone whose knowledge may be less certain. Msnicki (talk) 10:41, 18 November 2015 (UTC)

WP:OTHERCRAP is not a reason to violate policy; I'm aware that Go (programming language) has major sourcing problems and I've seen similar problems on many other software pages. QVVERTYVS (hm?) 11:09, 18 November 2015 (UTC)

If you look at Wikipedia, there are major problems caused by non-equal handling depending of whether a topic fits the religion of a sufficiently large group of people. If such a group exists, it seems to be impossible to have non-biased articles for the related topics.

Regarding primary or secondary sources: The main problem is credibility and verifiability, not whether there is a primary or secondary source.

• The claim "the Bourne Shell implements test as a builtin" is verifiable regardless whether it is from a primary or secondary source, as you just need to call the Bourne Shell and then type "type test".

• The claim "wodim works for an unprivileged user" is verifiable wrong even though you see it from primary and secondary sources - it is just not simple to prove this claim to be wrong, but it is possible to verify.

• The claim "bash is POSIX compliant" is non-verifiable (even though it is published by some sites) except when you have the POSIX test suite. So I cannot verify this in contrary to the two other examples.

I am happy to add whatever claim to WP if it is possible for me to verify this claim. Schily (talk) 11:29, 18 November 2015 (UTC)

Citing WP:V: "verifiability means that anyone using the encyclopedia can check that the information comes from a reliable source". It does not mean that information is true. QVVERTYVS (hm?) 12:33, 18 November 2015 (UTC)

How should a WP reader be able to check whether information comes from a reliable source? Note that while BMW may be a reliable source for some information, it is definitely not a reliable source when BMW makes claims about VW or Mercedes. Schily (talk) 13:11, 18 November 2015 (UTC)

Are you pulling my leg? QVVERTYVS (hm?) 13:24, 18 November 2015 (UTC)

I am trying to explain that verifiability is a highly complex issue. Schily (talk) 13:42, 18 November 2015 (UTC)

I think that is a very reasonable position, Schily. Here were the claims made and the sources offered. I believe that all except perhaps one of these is a non-controversial statement of fact that is reasonably easy to verify. Some of the claims, e.g., the complaints about the original C shell, that to be performant, fork() requires hardware support, or how Cygwin deals with the lack of fork, simply repeat what we report elsewhere, citing the same WP:SPS sources. Other claims, e.g., explaining how pipes work or how a fork works seem so clearly non-controversial that sourcing seems unnecessary but certainly could be provided if that's the concern. Many of the claims specifically regarding this product, e.g., that it's multithreaded or that it uses a modern compiler architecture rather than an ad hoc appear in multiple sources, including BYTE and other clearly WP:RS. In addition, anyone can download the free demo version and easily test that these claims appear to be true. The only claim dependent solely on a Usenet post is the claim that Windows doesn't support fork() because Microsoft didn't know how to fork a graphical app; I would have no objection to revising that portion of the sentence reading, "in part because Windows was conceived as graphical OS and it was unclear what it would mean to fork a graphical application with message queues." to indicate this was merely the author's understanding or to eliminate it entirely if that claim seems controversial.

Hamilton C shell differs from the Unix C shell in several respects, its compiler architecture, its use of threads, and the decision to follow Windows rather than Unix conventions.

The original C shell used an ad hoc parser and that led to complaints about its limitations. It worked well enough for the kinds of things users typed interactively but not very well on the more complex commands a user might take time to write in a script. Attempting to pipe the output of a foreach statement into grep simply didn't work. There was a limit to how complex a command it could handle.

By contrast, Hamilton uses a top-down recursive descent parser that allows it to compile commands and procedures to an internal form before running them. As a result, statements can be nested arbitrarily. The Unix C shell supports subshells and concurrency. A subshell is a separate child copy of the shell that inherits the current state but can then make changes, e.g., to the current directory, without affecting the parent. When the Unix C shell runs a script, it runs it in a subshell. A subshell can also be specified by putting parentheses around a group of statements. Concurrency occurs in pipelines, where all the stages are intended to run concurrently, or when a command is run in the background.

The Unix C shell's implementation of both these features depends on being able to make copies of its entire process state very inexpensively, which in turn depends on the Unix fork system call, which has access to the hardware. The semantics of fork are that it creates a child process which is a duplicate of the caller, differing only in the return value from fork. The parent and child are otherwise identical with duplicate sets of open file descriptors, duplicate current directories and duplicate memory images. The memory image, which can be quite large, is duplicated using the hardware page table and a technique called "copy-on-write": Initially, parent and child share the same physical pages in memory but all the pages are marked read-only. When one or the other tries to write to a page, a hardware exception is raised and the Unix kernel makes a copy of the page, gives the original to one process and the copy to the other and marks them both writable.

But Windows doesn't support a fork primitive under its native Win32 API (even though it is supported in the kernel for the POSIX subsystem), in part because Windows was conceived as graphical OS and it was unclear what it would mean to fork a graphical application with message queues. It's possible to simulate the functionality of fork on Windows at the application layer, but without access to the hardware page tables, it's awkward and not nearly as performant.

Lacking fork or a performant way to recreate that functionality, Hamilton uses the Windows threads facilities instead. When a new thread is created, it runs within the same process space and it shares all of the process state. If one thread changes the current directory or the contents of memory, it's changed for all the threads. It's much cheaper to create a thread than a process but there's no isolation between them. To recreate the missing isolation of separate processes, the threads cooperate to share resources using locks.

Finally, Hamilton differs from other Unix shells in that it follows Windows conventions instead of Unix conventions for filename slashes, escape characters, etc.

References

Qwertyus argues WP:OTHERCRAPEXISTS. But I don't think there's evidence that other editors believe all those similarly-sourced claims citing WP:PRIMARY and WP:SPS sources in all those other articles are crap and I don't think the claims here were crap, either. I think Qwertyus's main objection is that he doesn't want a long article, what he refers to as "excessive detail" [3] about something he doesn't like, perhaps only because he doesn't like that it's a commercial product rather than FOSS, not because of any valid complaint that the sourcing or the reliability and verifiability of the reporting wasn't up to the standards we normally ask. Msnicki (talk) 20:18, 18 November 2015 (UTC)

• Comment I think the Design section went into too much unnecessary detail before it was shortened, so I would agree with shortening it to a few sentences. Mentioning that Windows doesn't do forking and that threads are used instead should be sufficient. This is a common portability issue, and we all known what the difficulties are. More detail should probably go in the manual instead. Speculation on why Windows doesn't support forking seems more appropriate in Fork (system call) than here. —Ruud 22:05, 18 November 2015 (UTC)

Isn't that WP:NOTMANUAL complaint pretty hollow? It seems unlikely you haven't noticed how much how-to information we have in Bash (Unix shell) or C shell or pretty nearly every other Unix shell or programming language article. But I've never seen you complain there. Why here? More to the point, it would be helpful if you could pick out even one sentence you believe explains how to do absolutely anything with this product. I don't think you can. There's not a single example command shown nor does it list any of the keywords nor any of the operators. All it did do was explain the design problem in the abstract and the solution this author created. When you claim threads is a common portability issue that we all understand, that makes me wonder if you do. If it was so easy to "port" to threads, why is this still the only Unix shell that uses them? Pthreads have been available for 20 years. Why doesn't Bash or C shell use them? It's easy to demonstrate the potential gains, so why not? The answer is, threads are not a "portability" issue, they are an architectural issue. No one just "ports" anything to threads. You have to design for it. The deleted text explained that design problem and gave a brief explanation of how this design addressed it. There was absolutely nothing in there that could possibly be described as how-to. Msnicki (talk)

• I would need more time to reply to the long text, but a quick check creates the impression that the proposed text is a mixture of Hamilton documentation, notes about fork that do not look 100% correct and encyclopedic information. Maybe this can be sorted a bit. Schily (talk) 22:43, 18 November 2015 (UTC)

I'm pretty confident the description of fork actually is 100% correct (or pretty darn close!) and that you'll quickly verify that for yourself. I hope that may help persuade you that there's something encyclopedic to be learned here about an interesting design problem, not just a lot of promotional blather and unnecessary detail. Implementing a shell language designed around a fork semantic that copies an entire process state, including the entire memory image, on a system that doesn't provide fork is not just a "common portability issue" as Ruud argues. It's a lot harder because the semantics of fork bubble right up through the semantics of the language in the way pipes, scripts, subshells and background processes are defined to behave as starting with a snapshot of the entire parent state. That's hugely expensive to recreate between processes without hardware support, exactly as Cygwin reports in the 3 Cygwin sources 1, 2, 3 Qwertyus deleted and replaced with his bogus tags.

Moreover, there was certainly nothing common about threads in anything shipping in 1988, when this product first shipped, six months ahead of the (still today) single-threaded Bash. The author states on her faculty webpage [4] In December 1988, my C shell became the first multi-threaded third-party application to ship on a PC. I can't find anything earlier, can you? Her solution to the multiple readers/single writer problem, kept as trade secret until revealed in 1995 [5] and cited in the deleted text to explain how the sharing was done, also appears to be one of the earliest (possibly first) C language solutions published anywhere. Anyone is free to look for something earlier; I would love to know if you find something.

I also don't know what was helpful about removing the screenshots, File:Hamilton C shell and Cygwin bash recursion.png and File:Hamilton C shell and Cygwin bash date loops.png unless you don't like what they show, namely, that it blows away bash with better syntax and far better performance. We have a lot of comparison code fragments in C shell and a screenshot comparing it to sh alongside. No one's complained them except just to ask that the Apple UI elements be cropped off the top and bottom, so what's the problem here?

I think this bias and non-WP:NPOV agenda can be seen in the one sentence and source that was added: Frisch, writing in 1998, reported that the Hamilton C Shell correctly interpreted most C shell scripts. This makes it sound like maybe Frisch wasn't that happy with the product and that while it sometimes worked, it sometimed didn't and that there were some quality problems. Here's what the source actually says: The GNU utilities collection includes the bash shell. Users who prefer the C shell may be interested in the excellent Hamilton C shell package (Hamilton Laboratories). It includes a C shell supporting all the normal features and will correctly execute most existing C shell scripts. The package also includes a variety of UNIX-style utilities that may be run from within the C shell or from the Windows NT command line. Among them are the following utilities, which are missing from the GNU set ... In context, it's clear he liked the quality and was remarking that he liked the compatibility as well.

Finally, consider this [6] last edit, where he's listed "competing, or at least similar, products". The only one of those other articles with a similar see also list is the marginally notable DJGPP but Qwertyus hasn't even attempted to add this product to that list. He's only does it here. I think Qwertyus is working an agenda that has nothing to do with encyclopedic content and everything to do with an WP:IDONTLIKEIT attitude toward commercial software. Msnicki (talk) 03:22, 19 November 2015 (UTC)

Msnicki, you're obviously taking this personally, and I request that you drop the character attacks. The quote I added establishes that the product actually performs its task, but you seem bent on interpreting my every action negatively.

The Cygwin sources don't comment on the product that is the topic of this page, so adding them to make a point takes us to WP:UNDUE/WP:SYN land. However, I see that MIPS Magazine comments on the use of threads and I shouldn't have removed that; it can replace the Usenet sources if we want to stick to our usual guidelines.

I had removed the two additional screenshots because I thought they were too similar to show anything interesting; the remaining one shows example shell scripts and an interactive session. I didn't realize that they were supposed to show off the product by showing a benchmark. QVVERTYVS (hm?) 15:37, 22 November 2015 (UTC)

Fork and parsing

Hi, I am coming back to my previous concerns - sorry for the delay.

• The fork() claims are not what I like to see because they create a wrong impression. "fork() needs hardware support" is not a good wording as it creates the impression that you need special hardware to support fork(). What you however need is something similar to a Memory management unit. If we only look at the Intel hardware that was not seen as professional hardware in the 1980s when we used Sun computers, then a complete MMU first appeared in the '386 in 1986, but even the '286 had segment registers that allowed to have more than one process that uses the same virtual addresses. Note that you do not need a virtual memory management in the OS for fork() - just the same addresses fort parent and child. The hamilton C shell first appeared in 1988 (according to WP) and for this reason, talking about fork() as a hardware problem seems to be misplaced. The concept from the Bourne Shell to use parenthesis to enforce a sub-shell with an own name space for variables is however a nice and often used feature.

• The term "ad hoc parser" also seems to be a problem as I cannot find a common agreement on about what this term defines. I believe that most people basically distinct between two types of parsers:

• Parsers using a compiler compiler such as yacc. The "C-compiler known under the name "pcc" was the first compiler that used such a parser.
• Parsers that use handwritten code that tries to implement a set of functions that traverse the input in a way that takes care of syntax precedence. The first C-compiler "cc", the "Bourne Shell" and find(1) use such a parser and I would call this type of parser "ad hoc parser".

Neither of these parser types are causing a problem for a shell. The real problem for the C-shell was that "if-then-else" and similar are not part of the syntax of the shell but rather built in functions. Most oddities in csh are a result if this "concept".

A WP article for a shell should be written in a way that allows to stand scientific and encyclopedic expectations. For this reason, a WP article should not be based on fork() bashing and unspecific statements on the parser but rather explain what's common to csh and what's different.

Let me explain myself: I am author/maintainer of two shells: 1) "bsh" (known as "Berthold" shell) that introduced the first shell with fully integrated history editor in 1984 and 2) the Bourne Shell source, that I took from OpenSolaris in 2006, added my history editor from 1984 and that is since then maintained and enhanced by me, see: [7]. BTW: it is a bit surprising that even though this is the only maintained Bourne Shell project and mentioned by the shell website from Sven Maschek, it does not get mentioned in WP. Schily (talk) 16:20, 22 November 2015 (UTC)

The "special hardware" is indeed the memory management unit (MMU). If you would like to create a fork() primitive that can efficiently copy an entire process image to a child process, you need access to the MMU so you can do copy-on-write, which lets you copy a page by simply copying the page table entry, not the actual page. For obvious reasons, applications are never given direct access to the MMU. Only the OS kernel can do that. What that means is that if you are on an OS like Windows that does not support fork() as a system function, you cannot use copy-on-write to create it, you have to actually copy the pages. This is not fork-bashing, it's merely explaining how it works: If the OS doesn't provide fork, it's far more expensive to recreate it at the application layer and, as Cygwin reports[8], other issues like address space layout randomization make it hard to promise it'll even work consistently.

This is important because the language definition of all the Unix shells is that anytime you create a child, whether it's by running a script, putting something in the background, creating a subshell or a pipeline, the child should inherit the entire state of the parent as its initial state but then be allowed to make changes to its private copy. This was easy to do on Unix because they had a fork and all the Unix shells except this one were written to depend on that. It is not easy to do on Windows because there is no fork, so you either need to recreate the fork functionality or find another way.

This shell uses another way. What this shell does is create a new thread rather than a new process for each child so there's no need to copy any state or any memory image. It's already shared instantly. But that's also the problem, because if one thread now wants to make a change, it has to cooperate. For example, if you use fork to create a child process and the child wants to change its current directory, no problem, it just does it and the action has no effect on the parent. But all the threads share a common process-wide current directory, so if a thread needs to do something that requires the process current directory set a certain way, e.g., because it does want to create a child process to run an external command, it has to lock that resource only just long enough to do what it needs. This has to be done with locks, a lot of them as multiple reader/single writer locks. Once a thread takes the process resource it has to decide quickly how it differs from what it needs. It can't just brute force set every current directory on every drive, for example. The author explains these issues in BYTE (1990), It would hardly have been acceptable if a script running quietly in the background could suddenly, without warning, change the foreground current directory. Building a high-performance mechanism to re-create a current directory notion for each thread turned out to be a challenging project.

Ad hoc parsing[9] generally means that the language doesn't have a recursive (usually BNF) grammar and that the implementation is neither bottom-up nor top-down. BU parsers are usually machine-generated with a tool like yacc or bison. TD parsers (like this one) are usually written by hand but that is not the same as ad hoc. In an ad hoc parser, there's nothing that anyone could recognize as a known, formal strategy for parsing a language. Everything is written as you go, usually as features are added, one-by-one. And this was the problem in the Unix C shell and the reason, e.g., that you can't pipe a foreach. Each command did its own thing. if-then-else actually is part of the Unix C shell language but poorly implemented. Instead of parsing these constructs as whole structures, the individual keywords were implemented as commands that caused the Unix C shell to skip ahead in the input stream. Loops are even worse: They were were implemented by skipping back and re-reading the input. The whole thing runs out of gas because it's just not a recursive language. This one is. The grammar is recursive and everything gets compiled to an internal form using a top-down parser before being run. This is why it can not only pipe a foreach, it can do procedures, local variables and everything else it does.

Hope this was helpful. Msnicki (talk) 17:59, 22 November 2015 (UTC)

The problem with the current working directory with threads is a reason for not using threads but fork() - at least not before this problem has been solved in 2001 on Solaris and was later standardized in POSIX. The solution is the "openat()" family of syscall interfaces. Before, threads just have been in their development phase.

In my last reply I did not answer your previous claim: "Windows doesn't support fork() because Microsoft didn't know how to fork a graphical app". This is an unsourced claim. Please note that Win-DOS was not designed as a graphical system but is rather a port of an existing OS with text interface: "VMS". Even the the name (WNT) is just VMS++. Old versions of "Win-DOS" had the GUI as a separate user space implementation. Looking at VMS identifies that there is something very similar to vfork() and it is even called vfork(). It is just implemented via longjmp(). VMS was written for the VAX - a computer with MMU and after Dave Cutler moved from DEC to Microsoft, the new target platform of course always had a MMU and there was no problem to implement fork().

And again, the problem with the csh behavior is easy be understood when you know that loops , if-then-else and similar are implemented as builtin commands that call a specific parser store the commands and occasionally fed this into the normal parser. Schily (talk) 19:37, 22 November 2015 (UTC)

Well, yes, of course the current directory problem is a reason for using fork(), not threads. This why all the other Unix shells DO use fork, not threads, even though threads are available on Linux. It's the obvious easy way to do it. But what do you do on Windows, which DOESN'T offer fork (and also doesn't offer openat())? And remember, we're not just talking about the current directory, but also about all the rest of process state including the entire memory image, any open file handles, variables and everything else. You either recreate it at the application layer the way Cygwin does or you figure out how to use threads and share these things. Those are the choices. Cygwin chose to recreate fork, even though it meant doing it without support from the MMU hardware. This product did it with threads. Though the article doesn't make the claim, the screenshots, which anyone can duplicate on their own, suggest it was a good choice.

vfork() isn't a real fork, but simply an optimization for a common idiom in Unix that to start a program as a child process, a process normally forks a copy of itself, then immediately does an exec() to overlay itself with that new program image. If the child tries to modify its state or do much of anything except an exec(), the behavior is undefined. Unix shells can use vfork if all they're doing is starting an external command. But vfork is not sufficient for all the other uses, where the shell is trying to pass a copy of itself to a child.

The source for the remark about Microsoft's concern over the semantics of forking a graphical app is sourced to a Usenet post by the author [10], where she reports her conversations with Mark Lucovsky, one of the architects of Win32. I think that makes this source reliable for the purpose but as I remarked earlier on the page, if the claim seems too controversial, I have no objection to deleting just that portion of the sentence.

Re: the Unix C shell, I think we may be talking past each other. We agree on what it does and how it does it. The way it parses, not using any one of the usual solutions you might be taught in any compiler course -- which basically, is just two of them, bottom-up or top-down -- is called ad hoc and it has the problems you see, which is why no one does that anymore. We have standard solutions. The Unix C shell didn't use a standard solution. This one does. Msnicki (talk) 20:13, 22 November 2015 (UTC)

On the topic of forking, I have removed the two paragraph background that was not actually about Hamilton C shell. I think the article needs to concentrate on Hamilton C shell. It can talk about design decisions, but only if they are sourced from somewhere! Graeme Bartlett (talk) 21:37, 22 November 2015 (UTC)

Now that you've deleted it, do you still need the excessive detail tag? Msnicki (talk) 21:47, 22 November 2015 (UTC)

Threads have been developed between 1986 and 2000 - before ~ 2000, threads have not been usable except when you focussed on a single target platform. It seems that the Hamilton C shell is non-portable. This looks to me as if background information like fork(), threads and similar need to be mentioned different in the Hamilton C shell article, as they are not in the set of implemented features for the target platform. These constraints need to be mentioned, but just in a way that explains that a shell implemented under the constraints from a MS-Win target is forced to behave different from traditional shells on UNIX where a broader set of features is available. If someone likes to implement a new shell for UNIX, things would be different. Here it would make sense to explain why someone did decide not to go the usual way. Schily (talk) 22:02, 22 November 2015 (UTC)

Yes, I think you have it exactly right, Schily. Windows presents a really important design constraint if your objective is to recreate the semantics everyone expects of a Unix shell. Perhaps these sources will be helpful in explaining the problem. Re: portability, no, threads in Win32 are not much different than pthreads, so that's not nearly so much a problem as all the rest of the endless little differences between the Win32 API and the Linux system calls. Msnicki (talk) 22:13, 22 November 2015 (UTC)

References

Given that you seem to confirm the non-portability, it seems to be simple to have an encyclopedic article. If the content gives focus on the properties if the Hamilton C shell, only mentions things like fork marginally and explains the differences to the C-shell parser in a more distant way that does not look biased, it is what WP articles usually do. This article does not need to justify decisions from MS-Win, it just needs to mention the deviations and implications from these deviations from the POSIX standard. The article now really looks friendly and unbiased. Schily (talk) 10:54, 23 November 2015 (UTC)

I agree the article is fair as far as it goes. What it doesn't do is explain why fork vs. threads matters. It makes it sound like it's merely a choice of door #1 or door #2. I've given you two sources (Anderson & Anderson and Ritchie) explaining that one of the key language features of the Unix C shell and indeed of any Unix shell is that they provide this one-way inheritance of the entire state of the parent to a child in pipelines and subshells, etc., and that they do it by exposing fork. Most users take that shell behavior so much for granted that they probably don't think about how it's done and probably don't realize what Ritchie is saying, which is that all the shell is doing is exposing what the Unix fork call does. Without fork, doing this is a much harder problem. So it really matters that Windows does not support fork. I've also given you three Cygwin sources explaining the difficulties they had recreating fork. And I've given you a primary source from Byte explaining, e.g., the problem of sharing the process current directory between threads the author faced. I think these 6 sources should go in along with some sensible explanation of the problem.

I also think, compared to our coverage of similar products, that it's strangely deficient of detail of about any features. In the language section, all it says is that "statements can be nested arbitrarily." It seems to me it could at least mention that it also provides builtin and user-defined procedures (including printf and the usual suspect string and math functions[11]), block-structured local variables[12] and floating point, command line editing and filename completion, the free expression grammar (spaces neither required nor disallowed around operators and dollar signs allowed but not required anywhere an expression is expected[13]) and other improvements, e.g., to wildcarding (the "..." indefinite directory construct[14]) and command substitution (the ``...`` line-at-a-time construct[15]). Perhaps that's just me :) but I think this would definitely go in anywhere else once notability was established. Msnicki (talk) 20:05, 24 November 2015 (UTC)

• Comment I concur with Graeme's slightly trimmed edition of the detailed content. I think it's no longer "too intricate" and the template to that effect can be removed. I maintain my position that Msnicki's COI has been properly declared and scrutinized, and would further argue that any further unsubstantiated attempts to slap COI templates onto the article attempts should be considered as personal attacks and reverted. Deryck C. 23:08, 22 November 2015 (UTC)

• Comment The shortened version by Graeme is also acceptable. The two images in the Design section still need to go however, because 1) they are redundant fair-use images and 2) I didn't notice this before, but they are not there to demonstrate the interface, but used to make performance claims against other software. While these claims may well be true, they should be supported by independent benchmarks, not an ad hoc screenshot. —Ruud 11:57, 23 November 2015 (UTC)

They don't claim anything, they simply illustrate the differences in the languages and behaviors between this shell and bash in ways anyone can replicate free. There is no "may well be true" to this. It just is and there are the screenshots to prove it. Where in the guidelines is there anything that says that has to go? Msnicki (talk) 16:06, 23 November 2015 (UTC)

The date example (the third image) should be removed as it tries to create the impression of a fast process creation loop while it just demonstrates the performance of an otherwise empty echo loop. ksh93 is faster with this kind of task. Schily (talk) 16:44, 23 November 2015 (UTC)

How can you say it tries to create an impression of fast process creation? No one can read the thumbnail, so you have to click to the page, where it describes the fast loop as "cheating" (that's not plain enough?), characterizes the resulting numbers as "silly" and explains that process creation is still only happening at the same rate as in the other window (which still clobbers bash). What it does demonstrate is the multithreading and the sharing of variables between threads. (Each thread is locking and unlocking that shared variable on each access.)

I created the screenshots with Cygwin bash because that's by far the most popular on Windows and it's not commercial. It wouldn't have seemed fair to compare against any actual commercial competitor (e.g., MKS) or anything someone might think was chosen because it was already a weak player. I would be delighted to see a comparison to ksh93 on Windows. It should beat that one, too. Msnicki (talk) 17:20, 23 November 2015 (UTC)

I cannot find the term "cheat" in that image nor in it's description. BTW: ksh93 is part of UWIN and David Korn once gave me a demo on his laptop that verified that ksh93 is much faster on MS-Win using UWIN than bash inside Cygwin. BTW: bash is about the slowest thing you can get for Cygwin. It is huge and it has more fork calls than ksh93 and even more fork calls than the Bourne Shell. Schily (talk) 17:30, 23 November 2015 (UTC)

I had it in the purpose section. On reflection, I realize you're probably right, I probably misused the template. It should have gone in the description section. I've fixed that here[16] and fixed the other one as well. Quoting, with emphasis added, The multithreaded C shell "Really fast date loop" example "cheats" by separating the activities into two threads. One thread runs date as fast as possible (presumably, the same 88 times per second), updating a shared variable. The other thread simply reports the latest value as fast as possible. Msnicki (talk) 17:57, 23 November 2015 (UTC)

If your objection to the screenshots is that they compare this product to bash but you'd be okay if only they compared to a more worthy alternative, namely, ksh93, that's entirely fixable. My intent was never to pick a weak opponent. If you can point me to the version of ksh93 for Windows you'd like me to use (hopefully free), I would be happy to recreate the images with that shell instead. I have never tried ksh93 but I'm as interested as you are to see what happens. I think this shell should easily beat that one, too, but let's find out. Msnicki (talk) 18:16, 23 November 2015 (UTC)

The tools from David Korn and Glenn Fowler are apparently still at the AT&T site even though they both have been layed off 2 years ago (I guess after Glenn Fowler went 65). Since they work for Google, they seem to have less time to update websites or to create a new own website. I would start here: http://www.research.att.com/software_tools, but the link hangs. Other keywords to search are: "ast" (advanced software tools - this is where ksh93 sources are). It seems that there is a real problem as the download area requires to enter username/passwd given on a website at the bottom of the license text. This causes the relevant files to be unavailable at archive.org. I'll write a mail to David. Schily (talk) 11:08, 24 November 2015 (UTC)

you only need to write that shily schell is the best c shell. — Preceding unsigned comment added by 93.204.98.211 (talk) 19:47, 23 November 2015 (UTC)

Notable?

Can someone explain how this article passes Wikipedia:Notability (software) requirement? --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 06:30, 11 December 2015 (UTC)

I think it meets "discussed in reliable sources as significant in its particular field". Deryck C. 13:22, 11 December 2015 (UTC)

WP:GNG requires that the subject be discussed in detail in multiple reliable independent secondary sources. Those sources exist. Sources offered include Middlesex News, PC Week, Dr. Dobb's Journal, MIPS Magazine, BYTE and Windows IT Pro. A previous WP:G11 speedy deletion was overturned at a Wikipedia:Deletion review/Log/2011 May 8#Hamilton C shell in 2011. You may nominate it for deletion, but it seems pretty unlikely your nomination would succeed. Msnicki (talk) 16:38, 11 December 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on Hamilton C shell. Please take a moment to review my edit. You may add {{cbignore}} after the link to keep me from modifying it, if I keep adding bad data, but formatting bugs should be reported instead. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether, but should be used as a last resort. I made the following changes:

• Attempted to fix sourcing for http://tejasconsulting.com/sqamag/shell.html

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 10:37, 28 March 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Hamilton C shell. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20170201092050/http://hamiltonlabs.com/archives/Hamilton-C-Shell-Announcement-Douglas-A-Hamilton-IBM-Personal-Systems-Developer-Summer-1989.pdf to https://hamiltonlabs.com/archives/Hamilton-C-Shell-Announcement-Douglas-A-Hamilton-IBM-Personal-Systems-Developer-Summer-1989.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 16:13, 28 October 2017 (UTC)

Last screenshot is misleading

I've already noted this on the image talk page, quick summary:

Csh syntax requires parentheses around while conditions. In bash this will spawn the enclosed command in a sub shell. The comparison is either intentionaly or ignorantly unfair. The difference doesn't eat Hamilton improvements entirely, but it about halves them.

-- 79.202.98.49 (talk) 00:07, 18 November 2018 (UTC)

Fair point. Thanks for pointing this out. It wasn't my intention to create an unfair comparison. My recollection is that I copied the bash loop as you see it in that screenshot uncritically from a Cygwin mailing list message, then wrote what I thought was a comparable C shell loop. I can confirm that in my tests, eliminating the extra parens sped up the bash date loop by about 60%. On the other hand, what this also highlights is that a bash subshell is rather slow. Adding extra parens around the date command in the C shell loop also creates a subshell, but the loop without the subshell is only about 25% faster. Msnicki (talk) 02:03, 9 June 2019 (UTC)