Talk:Hamilton C shell

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 and Talk:Bash (Unix shell) 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.^[1][2]

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.^[3] 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.^[4][1] As a result, statements can be nested arbitrarily.^[5] The Unix C shell supports subshells and concurrency.^[5] 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.^[6] 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.^{[7][8][9][10]}

Lacking fork or a performant way to recreate that functionality, Hamilton uses the Windows threads facilities instead.^[5][1] 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.^[11]

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

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" 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 ^{[better source needed]} 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 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 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 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)

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)

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)

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)

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)