Jump to content

Talk:C shell

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

In the criticism's section of csh, though the example of the "if" condition does not work as intended in tcsh (file foo does not contain "bar"), it should be noted that when done with proper "if then endif", then it *does* work as intended. --58.111.178.87 (talk) 12:18, 18 September 2008 (UTC)[reply]


POV

[edit]

There are only negative links at the bottom of the page; this is not very NPOV. --Anon

This is Wikipedia, so you know what to do: be bold! --Atlant 17:13, 27 September 2005 (UTC)[reply]

I agree. It's not a useful article. It's pushing a POV, namely, "Don't use this awful thing. Nobody else does and you shouldn't either."

Yes, of course, there's a controversy and the article should tell you that, but this goes too far. There are other shells, and for some people those are better choices. But so what? I know for myself, whether I'm on Linux, OSX or Windows, I still want a C shell of some kind, not something else when I open up a new shell window. And I know I'm not alone. But so what to that also.

An encyclopedia article isn't supposed to be an opinion column. What it should give is basic reference information. And that's where I think the article really fails.

Compare this to the article on the C programming language. We're got a little bit of history of how it came into existence and some Powerpoint-ish bullets on its features. But we're missing the sort of meat you see in the C article of how it actually works. I think we need more reference information, perhaps basic statement format, the history mechanism, control structures and piping, wildcarding, quoting and command substitution, shell and environment variables, operators and editing. A screenshot and perhaps a toy sample script would also be helpful. Msnicki (talk) 07:13, 1 December 2009 (UTC)[reply]

Syntax similarities to C

[edit]

As someone reasonably familiar with the C programming language, this statement has always confused me. And by always, I mean since the day I knew what the C shell was. I was told it was a shell whose syntax somewhat resembles that of C. However, I don't see it. Could someone help me out here? What's so similar? Aloysius-Fibonacci (talk) 05:51, 4 November 2009 (UTC)[reply]

C shell when compared with other script languages of it's day tried to get a few things similar to C. It uses parathesis around test conditions instead of square brackets. And mathematically comparisons use standard syntax.
Compare:
#!/bin/bash
if [ $# -lt 2 ] ; then
  echo "usage: $0 minutes message" 
  exit 1
fi
 #!/bin/csh
 if ( $#argv < 2 ) then
  echo "usage: $0 minutes message" 
  exit 1
 endif
But an argument can be made it has just as many similarities with BASIC as C. -MarsRover (talk) 09:07, 4 November 2009 (UTC)[reply]

The other C shell

[edit]

In April 2006, I added these two sentences mentioning that there is a second, independently-developed C shell implementation. I also gave a link to the home page for the product.

  1. An independently-developed and modernized C shell, created by Nicole Hamilton, also survives on Windows in the form of Hamilton C shell.
  2. (These and other criticisms do not, however, apply to the more-modern Hamilton C shell variant of the csh language.)

Since then, there's been a history of back-and-forth as these contributions are deleted, then restored, then deleted again. According to their comments in the log, the individuals deleting this material feel that it's either advertising or insufficiently notable or both. I would appreciate some discussion, which I hope may lead to a consensus on the appropriate resolution. Here is the history:

  1. Deleted in November 2008 by Wiki Wikardo.
  2. Added back in December 2008 by me.
  3. The link and one of the sentences deleted in April 2009 by Jdstroy.
  4. Added back May 2009 by me.
  5. Link deleted in June 2009 by Rob.derosa.
  6. Link added back in July 2009 by me.
  7. Link removed again in July 2009 by Themfromspace.
  8. First sentence deleted in July 2009 by Thumperward.
  9. Second sentence deleted in November 2009 by Jdstroy.

At this point, there is no mention left anywhere in the article of this other C shell.

I fully accept that the deletions were in good faith but I disagree. What I suspect these individuals may not realize is that Hamilton C shell has been around for 20 years as a serious product. Its competitors are MKS Toolkit and Cygwin but, unlike those products, Hamilton C shell is the only one actually written from scratch for a PC, originally on OS/2, then on Windows NT. As a C shell, it is the only one on the planet not based on Bill Joy's original code.

It's also been the subject of a number of reviews and other mentions, which I think should satisfy concerns regarding notability. I suspect there have been more but with a quick search, I had no trouble finding several still available on the web:

  1. Hamilton has Berkeley C Shell for OS/2, Computer Business Review, December 1988.
  2. Examining the Hamilton C Shell, Dr. Dobb's, January 1991.
  3. The shell game, Software QA Magazine, August 1996.
  4. Csh Programming Considered Harmful, Tom Christiansen, October 1996. (Grudgingly acknowledged as a C shell that does not have the same shortcomings as the original.)
  5. Hamilton C shell, Windows IT Pro, April 1998.
  6. MKS Toolkit's centerpiece, in Government Computer News, January 1999. (Mentioned as an alternative to MKS that may be more suitable for some users.)
  7. Hamilton C Shell 2009 - The Missing Shell for Windows, Robert Oliver, September 2009.

(Those with sharp eyes will notice that the author of Hamilton C shell has changed her name since the original release for personal reasons which appear to be irrelevant to our discussion here.)

To me, it looks like the mention of this other C shell is appropriate, accurate, provides relevant information and meets the standards for notability. May I ask for comment, please?

Msnicki (talk) 17:51, 29 November 2009 (UTC)[reply]

It's a separate application with an independent history. If it's notable enough for inclusion here, it should have its own article. Chris Cunningham (not at work) - talk 18:57, 29 November 2009 (UTC)[reply]
I was asked to comment here because I removed a link back in July. I agree with thumperward above me: the other C shell is a different topic, and if it meets our notability guidelines it should be described in its own article. ThemFromSpace 02:23, 30 November 2009 (UTC)[reply]
Thank you both for your comments. I appreciate your taking time to respond.
I wouldn't object to a separate article in addition. If that's the consensus, it'd be simple enough to get it started with a short stub. But that's not quite the question I asked and, if it were, I still don't know what your answer would be, given that you've both qualified your remarks with "if it's notable enough." The question I tried to ask is whether the information I've given demonstrates sufficient notability for a mention and whether a mention within this article is appropriate.
Certainly, the hurdle for a mention is not the same as for a separate article. And it's undeniably common practice on Wikipedia to mention clones, alternatives and successors in an article about a software product. Consider, e.g., the mention of R in the article on S, the mention of vim and elvis in the article on vi, the discussion of all the various implementations of emacs, the discussion of Linux in the article on UNIX and the discussion of Excel in the article on VisiCalc, just for starters. Sometimes, the linkage gets really tenuous; for example, consider the mention of Python and Perl in the article on C.
In the case at hand, the documentation, including a detailed compatibility guide and even a demo version are all available free on-line, allowing us to verify that Hamilton C shell implements the same C shell language with all the same constructs as the original, but with additions (e.g., procedures and floating point), fixes to the complaints Christiansen famously enumerated and some adaptation to OS/2 and Windows. It's a different codebase by a different author but not a different language. So where does this leave us? Msnicki (talk) 04:19, 30 November 2009 (UTC)[reply]
I think you have to create the Hamilton C shell article and have it withstand a possible challenge to prove it is notable. And since google only reports 7000 hits you may have a struggle ahead of you. Also, if you work for Hamilton Laboratories, I would wait for someone else to start the article. --MarsRover (talk) 06:01, 30 November 2009 (UTC)[reply]
I appreciate your taking time to comment, MarsRover. The guidelines article you cited is quite helpful. But it appears to offer somewhat contrary guidance to your suggestion that a separate article be created, first. By my reading, it sounds like a mention here, not a separate article, is most appropriate.
Here's how I read it: Since the reviews I cited were not in general interest sources, the criteria for a separate article do not appear to be met, regardless of who creates it. But then it goes on to say, "Software that can be proved to have a consistent number of users (beside the creator(s) and their friends) but do not meet the above criteria may be merged into the article describing their main functionality (for example, an article about a random disk editor may be merged into a section of disk editor.)" Since almost no one releases their customer lists for independent verification, the standard of "proof" of a consistent number of users (and what should that number be?) is a bit unclear. But the product is still around after 20 years, has been the subject of a number of industry publication reviews spread over that time and does have thousands of hits on Google (which, curiously, go up to almost 10,000 hits if you quote the entire product name) so I suggest the requirement should be presumptively met. Do you agree? Msnicki (talk) 07:45, 30 November 2009 (UTC)[reply]
10,000 is not an impressive number of hits compared with 20 times that number for "tcsh". IMHO, the way the previous Hamilton C shell comments were integrated into the article were annoying. At best it deserves a single sentence that says its a "Windows" port. Not more sentences than "tcsh" and confusing the issue of whether problems still exist for the Unix version of C shell. --MarsRover (talk) 18:38, 30 November 2009 (UTC)[reply]
I agree, 10,000 hits isn't a particularly big number, though it probably understates the number of users. (Do we really think, for example, that there are only 169,000 copies of tcsh or only 44.8 million copies of Windows XP in use?) Also, I think we should try to stick to the rules as they're written as best we can. They don't say anything about an "impressive" number, just a "consistent" number beyond the creator(s) and their friends. I don't know anyone with 10,000 friends (fans, sure, friends, no) so I think the condition is met.
Also, Hamilton C shell is not a "port" in any technically accurate sense of the word insofar as it's claimed to have been developed from scratch, completely independently. And I'm not sure I understand your point about confusing the issue of problems in the original UNIX version. That version had a bunch of problems, this one doesn't. What's confusing about that? What I would say is annoying, echoing sentiments earlier on this page, is the overwhelmingly negative tone of the article. (But that's a whole different can of worms! :)
But perhaps we're closing in on a resolution. I had originally written just two sentences + a link, which may or may not be the best way to introduce a mention. What would you suggest? Msnicki (talk) 19:45, 30 November 2009 (UTC)[reply]
That version had a bunch of problems, this one doesn't. What's confusing about that? Well, the article is about that version so having material mixed in saying all problems are solved can be initially confusing. Hamilton may have really fixed the problems but it is commercial software for a completely different OS. A blurb about it is simply not very useful information. Anyway, I will let others suggest a good way to add the material, if there is one. --MarsRover (talk) 22:39, 30 November 2009 (UTC)[reply]
... having material mixed in saying all problems are solved can be initially confusing. It didn't say that. It said (in section on criticism), "(These and other criticisms do not, however, apply to the more-modern Hamilton C shell variant of the csh language.)" I'd like to be responsive and I certainly welcome suggestions for improvement, but you need to help me out to understand why that's confusing. Msnicki (talk) 23:16, 30 November 2009 (UTC)[reply]
Well, because it isn't "a more modern variant", it's a commercial fork which has been on a separate codebase for twenty years. Microsoft's TCP/IP stack is derived from BSD, but it would be very confusing to describe the two interchangeably in the same article. Chris Cunningham (not at work) - talk 17:57, 1 December 2009 (UTC)[reply]
Of course, they're not interchangeable. But I never said they were, certainly not in the 2 sentences I proposed. They both implement the same basic language and facilities but the one that came later has some improvements. Are you objecting to the phrase, "more modern," as insufficiently neutral? Okay, I'm open to suggestions, but compare that wording with the wording in the mention of R in the article on S, where R is described as a "modern implementation of S."
It seems to me there three separate questions to resolve: (1) Is a mention appropriate? (2) What information should the mention convey? (3) How should it be worded? I think the answer to the first, under the rules, is yes. And I think the answer to the second is that it should convey that there's another, independently-developed implementation on Windows where the author tried to correct the problems identified in the original. As for how it should be worded, I'm open to suggestions. But I think there's a risk of slipping into some tedious straw man arguments with all this talk about being confused by claims that "all problems are solved" or that the two are "interchangeable." I didn't say either of those things. You guys did. If you think your wording is confusing, maybe we should use mine. :) Msnicki (talk) 18:57, 1 December 2009 (UTC)[reply]
Having the sort of mind I (unfortunately) have, I had to look up hamiltonlabs.com/cshell.htm ... and yes, if Redmond WA counts as close enough, she sells C shells by the sea shore. Sizzle Flambé (/) 09:36, 30 November 2009 (UTC)[reply]
Thinking about the points that have been raised, would it make sense to do the same thing in this article as is done in so many others, namely, to have section specifically devoted to successors, clones and alternatives? Mentions of sh, tcsh, ksh, bash, the Hamilton product and anything else we think should go there could simply be listed in a set of bullets the way it's done elsewhere with maybe a sentence in each bullet to explain the relationship. No one seems to find that overly confusing anywhere else, so I propose that it should work here as well. Msnicki (talk) 22:45, 1 December 2009 (UTC)[reply]
That sounds like the best solution for now, yes. Chris Cunningham (not at work) - talk 09:33, 2 December 2009 (UTC)[reply]

Trying to improve the article

[edit]

I decided if I would like this to be a better article, and I do, maybe I should take the advice suggested earlier: Be bold.

I remember the C shell as a very influential piece of software in the 80s. We tend to take for granted today the features it introduced and the almost cult-like following it had at USENIX events. AT&T was pushing their new System V release, but until V.4, it didn't have csh and that was a pretty big deal if you were going to build a UNIX machine. I'd like to capture both what was so interesting about the ideas and enough specificity to explain what they built.

I've taken a stab at fixing what I regard as pointless confusion over csh versus tcsh. If I wanted source for csh that doesn't have all the tc.*.[ch] files in it, I don't know where it'd be found. If you use csh today, it's pretty darn certain you're using tcsh. So I don't really see much point of describing tcsh as a whole lot more than the current release of csh. That said, I think of all the discussion of what they added (all the command completion stuff, etc.) should remain in the tcsh article along with the rest of the story of that project and the people involved.

I've also taken a (big) stab at reworking the discussion of Christiansen's criticisms. The article should not be trying to advise people whether to use the thing or not. It should tell you what the issue is about, which is that the C shell embodied a lot of brilliant ideas, but implementation wasn't nearly as good.

I was happy to find that quote from Joy conceding that when he started, he wasn't a very good programmer. The C shell was one of the first things he wrote and it definitely had some odd coding, e.g., seeks in input to go to the top of a loop, setting the high bit on a character to mark it as quoted, etc. But Joy was so brilliant and he had such great ideas, he could make anything work, even when he did it all wrong.

Suggestions and feedback (and help!) welcome. Msnicki (talk) 06:53, 6 December 2009 (UTC)[reply]

The rewrite looks really good.
Regarding "confusion over csh versus tcsh" , I think you still can get the original csh for BSD [1]. It would be nice if the article clarified whether csh is really dead or not.
Regarding "criticisms", IMO the way quoting works (or doesn't work) is probably its weakest point. The way is the script syntax is more readable than sh is its best feature. Tom Christiansen's criticism is the canonical rant so maybe his name should be included.
Something that was taken out is that "C shell" descended from the 1st generation Thompson shell (ref: http://www.softpanorama.org/People/Shell_giants/csh_family.shtml). There quite a bit of information out there about the Bill Joy vs. Steve Bourne battle in writing the 2nd generation shell.[2][3]. I love this bit of opinion: "Bill Joy essentially wiped the floor with AT&T shell design team (and personally with Steve Bourne) introducing more elegant and more compatible with C scripting language which generated many ideas and tremendous following."
Also, according to Steve Bourne: "The C shell was done a little after I did the Bourne shell – I talked to Bill Joy about it at the time. He may have been thinking about it at the same time as I was writing sh but anyway it was done in a similar time frame. Bill was interested in some other things that at the time I had less interest in. For example, he wanted to put in the history feature and job control so he went ahead and wrote the C shell. Maybe in retrospect I should have included some things like history and job control in the Unix shell."
-MarsRover (talk) 09:13, 6 December 2009 (UTC)[reply]
Yes, I would really like to know if we could say definitively either/both (a) csh is dead, (b) work on tcsh continues.
Thanks for the suggestion re: discussion of shortcomings in quoting. Unless you get to it first, I'll try to put something in tomorrow.
Re: taking out the mention of csh descending from the Thompson shell, that was deliberate but only because I'd like a reference to clarify what that means. I expect that Joy must have seen and used the Thompson shell. But so what. Did he also read any of the code or actually copy any of it? His code was so horrible, I think that was all his! But I'd love a good reference to clarify the relationship.
Thank you for that link to the shell history page. Wow. He's certainly no fan of Steve Bourne! But I think he's right, the language definition for sh couldn't possibly have shown less creative spark. I do love that quote about Joy wiping the floor with the AT&T shell team. And it's interesting to read Bourne's comment in the A-Z article about not being interested in history or job control, not when you have a window system. Well, he had a window system apparently. But Joy was working from student housing 11 miles away over a 300 baud modem! He was little more motivated. Msnicki (talk) 10:00, 6 December 2009 (UTC)[reply]
For (b), I know that tcsh is actively fixing bugs. The Thompson reference is just to point out this was the 2nd generation shell (although nobody seems to say "2nd generation") so I would uses that so people get the timeline correct. Bourne shell is also 2nd generation. Then tcsh and bash are I think the 3rd or 4th generation. --MarsRover (talk) 16:45, 6 December 2009 (UTC)[reply]
Yes, looking at the Fixes file in the tcsh source, I see the latest version, V6.17.00, was released Jul 10, 2009 and included 20 bug fixes; V6.16.00 was Sep 30, 2008 with 32 bug fixes. So this clearly is still active. And I think you're right, that the way to state the relationship to the Thompson shell (or should it be the Mashey PWB shell?) is as a timeline and leave it at that. I don't think we can establish and thus shouldn't imply any deeper intellectual, much less a source code lineage without a reference that actually says there was one. Msnicki (talk) 18:19, 6 December 2009 (UTC)[reply]

I've added a screenshot from my Macbook showing side-by-side windows running sh and tcsh. In most articles, the screenshot is just the one window of that particular application running, but what I wanted to do here was show more context of what the C shell actually looks like running on a real machine and also, how its syntax differs from sh. But because I have chosen a different style of screenshot than is used in most articles, I would appreciate feedback on whether others feel that it's actually appropriate. Msnicki (talk) 06:14, 7 December 2009 (UTC)[reply]

I've "corrected" the bourne shell example of the while loop. What do I mean by corrected? In all the other examples do/then is in a new line for consistency. -- 13:16, 25 November 2015 (UTC+1) — Preceding unsigned comment added by 134.76.205.229 (talk)
Thanks, that was helpful. It now matches the screenshot. Welcome to Wikipedia. Msnicki (talk) 17:11, 25 November 2015 (UTC)[reply]

When did csh first appear?

[edit]

I'd like to get this right. According to a published email, 22 Apr 2009 by Kirk McKusick, csh was already in 1BSD in 1977. But I'm not convinced McKusick's recollection (30 years later!) is correct. Other articles, e.g., Berkeley Software Distribution claim 2BSD in 1978 but I can't find where they're getting their date. Does anyone have a better source? Msnicki (talk) 06:53, 6 December 2009 (UTC)[reply]

It seems to be 2BSD:
"The "C Shell", written by Bill Joy for 2BSD in the late 1970s. It featured several "advances" over the Bourne Shell, :including job control, history substitution, and aliases."
ref#1: http://www.bsdnewsletter.com/bsda-book/Demonstrate_familiarity_with_the_default_shell.html
1977 Bill Joy compiles and releases first version of Berkeley Unix (1BSD)
1978 Bill Joy releases the C-Shell (csh) [244]
ref#2: http://unix.harley.com/instructors/timeline.html
--MarsRover (talk) 07:46, 6 December 2009 (UTC)[reply]
Thanks, MarsRover. I wasn't able to cite the first one because it's a wiki as well, but the second one is an actual person, so that works. Msnicki (talk) 08:30, 6 December 2009 (UTC)[reply]
The claim from Kirk McKusick is not fully correct - I guess that he just no longer remembers things correctly and did not check sources. In 1BSD, there was just a project where Bill wrote a thing called ashell and this was really primitive. It however included an alias builtin and the man page started this way:
SH(VI)                       9/15/77                       SH(VI)
 
NAME
    sh - a shell (command interpreter)

SYNOPSIS
    sh [ -V ] [ -v ] [ -t ] [ -c ] [ -i ] [ name [ arg ...  ] ]

DESCRIPTION
    Sh is a command interpreter.   It  arranges  and  interprets
    command  lines  and  the contents of command files.  It is a
    modification of the standard shell sh (I), and  almost  com-
    pletely upward compatible therewith.  The intent, in working
    on a new shell, is to provide an environment which  is  more
    easily tailored to the wishes of each individual user.  Most
    new features of this shell, especially  the  alias  feature,
    are  toward  this  end.   Later  versions  of this shell may
    include improvements to the command language  of  the  shell
    and allow more easy repetition of commands.  The intent here
    is to make the command language more resemble  a  high-level
    language  - C being the natural choice for UNIX, and to pro-
    vide some  means  of  repeating  modified  commands  without
    retyping,  perhaps  akin to the INTERLISP redo feature.  The
    eventual goal is a C-shell,  csh  (or  ``seashell  if  you
    prefer.)
and ended this way:
AUTHOR
    William N. Joy

BUGS
    As  this  is  an  experimental  shell,  there  are  probably
    several.   Mostly,  the  design has a lot of rough edges and
    the new features don't always ``like each other.  Some  of
    them can't be successfully mixed.
Hope this helps Schily (talk) 12:54, 21 January 2015 (UTC)[reply]

Overview of the Language

[edit]

I've started a section in which I intended to give an overview of the basic capabilities and syntactical style. It's clearly not finished. But I42 has raised an objection, claiming that it does not belong here because he feels it's a "how to" section. I disagree, especially as I envision that the section, even when complete, will only be relatively broad-brush, light on any examples and certainly not offering advice on anything. If indeed the section ought to be deleted, I'm certainly not going to put more work into writing it before we do that! As in the past, I'd like to hear some discussion, please. Msnicki (talk) 01:44, 5 March 2010 (UTC)[reply]

Most of the programming articles don't seem to have much of this type of material (ex. C (programming language) has minimal syntax, capabilities and examples). I started a Wikibook on scripting with C Shell. The format for a wikibook is "freeform" so you can put anything you want there like as many examples as you want. I added a link to the book from www.tcsh.org so the content should get some visibility. Basically if you plan on adding material that it may appear to violate WP:NOTHOWTO I would avoid the headache and work on the book instead. --MarsRover (talk) 06:50, 5 March 2010 (UTC)[reply]
The section goes through the features of the language explaining the syntax and illustrating it with examples. It is well put together and is very useful, but it is not encyclopedic. The examples in the Design Objectives which compare against C, on the other hand, are encyclopedic because they examine the reason behind the design (although that section currently requires references). I42 (talk) 07:37, 5 March 2010 (UTC)[reply]
I42 are we talking about the same things? The code boxes in the Overview of the Language are not examples. That's not live code. They're intended to show the template style, though I concede that I've been thinking they should be reformatted more like the way Joy originally explained the constructs beginning on page 27 of his Introduction to the C shell paper. I think his typography would make it clearer that we're talking about the constructs in the abstract. Msnicki (talk) 19:58, 5 March 2010 (UTC)[reply]
You could be right, MarsRover, that your Wikibook is the better place. It's mostly a skeleton there so far, but I like what I see. Msnicki (talk) 19:58, 5 March 2010 (UTC)[reply]

I decided I still wasn't comfortable not having any basic discussion of how the csh language was constructed from a language designer's standpoint, so I've just done a fairly major rewrite of this section. Both through the typography (e.g., there's no longer anything that looks like a code sample box) and deliberate omission of detail, I hope I have satisfied any concern that this is too much a user manual. Consequently, I have removed the "how to" notice. As always, if anyone objects or has suggestions (or even, if you have some positive feedback!), I'm hoping you'll speak up. Thanks. Msnicki (talk) 19:04, 14 March 2010 (UTC)[reply]

Expressions.. not csh's strongest point anymore

[edit]

Thanks for clarifying the differences between C shell and C langauge expressions. I just noticed that BASH like the C language follows the much more intuitive left to right operator associativity that most languages use. (ex. echo $((5 - 3 + 2))) -MarsRover (talk) 20:08, 24 June 2010 (UTC)[reply]

No, thank you for bringing that up! And thank you for saying something. I was hoping we'd talk about it. I thought you'd brought up a pretty interesting point, more of the same suggesting that Joy really didn't understand compiler design when he began building the C shell. Right associativity is pretty unusual and counter-intuitive. I doubt it reflects any sort of conscious choice; I bet it just came out that way. After that, I got curious and verified that the Hamilton csh is left-associative like every other language. Msnicki (talk) 23:44, 24 June 2010 (UTC)[reply]

Formatting for mobile devices

[edit]

I've deliberately indented portions of the article using blockquote, where my intent was make it easy for the eye to scan a long list with descriptions (e.g., all the features for interactive use) and still see it as a single list. And on a laptop or desktop display, I think it works. But it doesn't work on a mobile device. I looked at it on my Droid and it's terrible; you get into the Overview of the language section and there's just too much white space wasted in most highly indented sections, e.g., the i/o redirection operators.

Is there a way to make a blockquote conditional on whether the user is on a mobile device? I'd like to turn off some but not all of them for mobile viewing. Msnicki (talk) 15:55, 6 July 2010 (UTC)[reply]

I couldn't find a better answer, so I've removed the blockquoting. Msnicki (talk) 18:18, 8 December 2010 (UTC)[reply]

Review

[edit]

I've been asked to take a look at this for the computing project, and this article looks rather good, but it needs more inline references. I'm rating it C class, but if it was sourced properly it'd almost certainly be a Good article and would be worth nominating for that. -- Eraserhead1 <talk> 20:28, 4 December 2010 (UTC)[reply]


IMO, the biggest problem with the article as it stands is that it mixes "csh" and "tcsh" too freely. I know that "tcsh" has taken over as the only living descendant. But it like mixing "bash" features in with the "sh" article. If someone wants to know which features Bill Joy created or which features they should use that will actually run on an old versions of csh, they are out of luck with this article.
My recommendations although not sure how easy they would be :-)
  • Infobox shouldn't include "sh" examples along with "tcsh". I don't think there is another example of including a rival in the infobox.
  • And for that matter "tcsh" should really be "csh". Compile the old source and include "csh --version" in the session example.
  • Infobox should include the latest "csh" version number/date along with the latest "tcsh". When the original "csh" died is an interesting fact.
  • Every feature listed that is only available in "tcsh" should have next to it: "(only tcsh)".
--MarsRover (talk) 18:46, 8 December 2010 (UTC)[reply]


I liked Eraserhead1's take, that the basic structure isn't bad but that each statement along way needs a clear citation or it should to be rewritten or trimmed to just what can be cited. I think he gave us good advice.
I also understand where you're coming from re: the integration of csh and tcsh into the story. But I think your analogy to mixing bash with sh goes a little too far. bash was independently developed. If you follow the link and download the source for tcsh, anyone can see by observation that Joy's original files are still there; sh.c starts with Bill Joy's October 1978 comment. But there are also a bunch of tc.* and tw.* files that have been added. If you wc all the *.[ch] files, it's about 57KLOC; the tc.* and tw.* files contribute only about 14.8KLOC. (Is it original research to point out any of that in the article or even here? I confess, I don't know.) You'll also see the same mixing of csh and tcsh in the way secondary sources treated it, c.f., DuBois's 1995 book, Using csh & tcsh (O'Reilly). The book is ostensibly about both versions, but on page 5, he tells you get tcsh and be done with it. From there, the one distinction he makes between csh and tcsh is a 20-page chapter 7 on the tcsh command line editor. Everywhere else, no distinction. That was 15 years ago when the tcsh additions were still sort of halfway new. There's even more confusion of csh and tcsh in the tcsh Significant features section; everything listed there as a feature of tcsh was in the original C shell. What's at times gone through my mind is to wonder whether it would make more sense to merge the C shell and tcsh articles into one to make a better historical story.
I think you have some good points re: the screen shot. But too many others appear to be just whatever random junk was on someone's screen at some random moment. They never tell you anything and they're ugly; I hope we can do better than that. I think good screenshots are hard to do. What's there is intended to let you see the first few examples in the article on an actual machine. Maybe we could move that current screenshot down to the More like C section where the examples appear and come up with a new one for the infobox. Does that work? MarsRover, do you want to try your hand at new screenshot for the infobox? Msnicki (talk) 20:21, 8 December 2010 (UTC)[reply]
I am don't have a ton of time right now. I just wanted to throw that out there as something I think should be changed if we want to go to "Good article" status. Unfortunately, tcsh was given another name than csh when developed. When PHP 2.0 switched developers and was dramatically rewritten changed to PHP 3.0 the name was the same so those products are seamlessly merged together in one article. I don't think merging in tcsh is a good ideal. One bit of proof is how O'reilly titled their book (Using csh & tcsh). They view them as separate programs.
The feature support still confuses me. I read that pattern matching (ex. "if ( abc =~ a* ) then" ) only works on BSD but it works fine in tcsh. And then multiple string modifiers is a tcsh specific feature (ex. $PATH:r:r:r). I normally use "csh" instead of "tcsh" since people are more familiar with that name but it probably means I am using "tcsh-isms" and in a similar fashion as people use "bash-isms" and put "#!/bin/sh" at the top of there script. I guess it doesn't really matter in my work situation but if it possible to know which feature work where it would be nice.
You're right. Most of the Unix shell screen shots are random stuff that was typing. It would be nice to know the default prompt and maybe something specific to that shell. I try to get something but if you can do it first, go ahead.
-MarsRover (talk) 18:29, 9 December 2010 (UTC)[reply]
The pattern matching and all the :-operators are all described in the 1986 Anderson & Anderson UNIX C Shell Field Guide (Prentice Hall), predating tcsh. (Btw, great book. Highly recommended.) So the features were at least there, even if not as bug-free then as later. By the time of the O'Reilly book, tcsh was available and there was confusion then as there is now about the difference. (I can't be the only one who wishes they'd just incremented the release number.) So of course the cover has to say it's for both. But inside, they make clear that tcsh just added new features. (Btw, I noticed later there's a second chapter 10 where he does distinguish between the completion features in csh and tcsh, but again, it's just more of the same command line editing stuff that got added; it didn't change the core csh code.)
What I would love to see us do is tell more of the release history. If we could document the very last release of csh code that did not include the tc.* files and when the tcsh distributions happened, I think that would be pretty cool.
Btw, I think everything currently listed in the article was in the original C shell. I had to check the recent addition of interactive filename completion but whoever did that was right: Anderson & Anderson don't mention it, but DuBois picks it out on page 111 as csh-specific behavior. (I should probably add the citation -- one of many!) Msnicki (talk) 19:54, 9 December 2010 (UTC)[reply]

Proposing to merge with tcsh

[edit]
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Time to close discussion. Clearly no consensus. -- P 1 9 9   21:04, 26 March 2014 (UTC)[reply]

It's almost impossible to find a source today that presents the original csh. As discussed above, this article is already assuming that csh = tcsh for most features and purposes, including the infobox. The original csh should be discussed in the (nonexistent right now) history section. This article also fails to say on which systems (if any) the original csh is still shipped today. I suspect the answer is "none". Tcsh vs. csh is not paradigm shift; it's more like ksh93 vs. ksh88. FuFoFuEd (talk) 13:03, 30 May 2011 (UTC)[reply]

  • Merge. I agree with the proposal to merge. The current tcsh article contains very little information that's actually about what tcsh added to csh; most of what's there (e.g., all the !-style history stuff) describes features that were in the original C shell. Msnicki (talk) 13:11, 30 May 2011 (UTC)[reply]
  • Oppose I admittedly don't know much about this shell, and I came here to learn more about it, but it seems to me that there is a decent "History" and "Deployment" section, the only problem you have with the article is it doesn't differentiate between which commands are and are not unique to tcsh. If someone did that it would be a great stand-alone article. -128.117.88.111 (talk) 17:59, 31 May 2012 (UTC)[reply]
There really aren't any differences in the language. Tcsh only adds command completion and command line editing. If you go look at the source, you'll find they just added a few new source files for that new functionality. What was there already didn't change. Further, with rare exceptions, if you type "csh" on most machines, what you get is tcsh. They really are the same thing, just differing, in effect, by the release level. Msnicki (talk) 20:27, 31 May 2012 (UTC)[reply]
  • I'll then change my vote to Neutral; I still think there's enough material for its own article, but a merge seems feasible, and I don't know enough about the shells to offer a solid opinion. -128.117.88.111 (talk) 16:47, 4 June 2012 (UTC)[reply]
  • Weak oppose I agree with anon above. I think merging basically sounds like giving up differentiating the two versions of the product. I find the history of the products interesting. Something like Bourne shell talks about the features available when it was developed. I would think this "csh" article should be like that and this full featured version could be in "tcsh". But if properly delineated you could have one article. (Thus the weak oppose). --MarsRover (talk) 17:43, 4 June 2012 (UTC)[reply]
I totally respect your opinion. I'm still !voting to merge but I definitely wouldn't suggest doing this without a clear consensus in support, including having you on-board, agreeing this is a good idea before we do anything. In addition to laziness, this is why I hadn't jumped in to start merging them. You need everyone feeling pretty good about this sort of thing. Msnicki (talk) 18:59, 4 June 2012 (UTC)[reply]
  • Oppose merge. My reasons are as follows. (1) Are you sure that Solaris and AIX also ship tcsh instead of their version of csh? This is unlikely, but I am not able to deny this (though I attempted to scan the opensolaris source code. (2) tcsh and csh are considered as two separate entities and are e.g. separately maintained. (3) Even if csh is now merely historical, you can add either a historical note or a pointer to the tcsh documentation without doing a merge. Thanks, Anand (talk page) 17:06, 6 May 2013 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Broken syntax highlighting

[edit]

Our code examples for both sh and csh are formatted using <syntaxhighlight lang="bash"> ... </syntaxhighlight>. This worked okay for both sh and csh examples until someone changed the formatting rules for bash to make the keywords bold. This has broken the formatting for the csh examples because only some of the keywords overlap with bash. I've chased this far enough to find that the <syntaxhighlight> tag invokes the GeSHi Generic Syntax Highlighters, as described at mw:Extension:SyntaxHighlight GeSHi and WP:Catalogue of CSS classes. Source for the GeSHi library is at Sourceforge.

Notice there are .php highlighters defined for nearly everything except csh/tcsh. It appears to me that the bash.php might quickly be recast as a csh.php formatter with an appropriate set of keywords if there is anyone willing to give it a try. Msnicki (talk) 19:26, 31 August 2014 (UTC)[reply]

Oh, goodie! There's now lang="csh" colorizer. Many thanks to Ori Livneh for fixing this in this diff. Msnicki (talk) 21:50, 25 June 2015 (UTC)[reply]

Fair use of the desktop image questioned

[edit]

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

[edit]

Qwertyus has edited [4] the Hamilton C shell article, removing a fair amount of content, arguing that the WP:SPS sourcing, e.g., of what the author was thinking, was inappropriate. The article survived a WP:DRV at Wikipedia:Deletion review/Log/2011 May 8#Hamilton C shell in substantially the previous form, drawing a consensus that it was not obviously promotional. No one at the time voiced criticism of the content. On that basis, I think the content was fine. But Qwertyus is correct that I have a WP:COI, declared at that deletion review and also on the article talk page, so I do need to ask for others' opinions and I must respect your consensus. I am too close to this. Msnicki (talk) 20:00, 17 November 2015 (UTC)[reply]

User Qwertyus is most likely a twelve-year-old jerk, like so many of the ignorant junior-high-schoolers currently editing wikipedia. As someone who used the Hamilton C Shell on OS/2 for many years, it's pretty apparent to me that this person has not a clue. Ignore him/her/it :) 116.231.74.1 (talk) 15:03, 17 February 2017 (UTC)[reply]

MOS and etc.

[edit]

@Msnicki: Your revert is not appropriate per WP:ACCESS.

  1. Yes, this styling is idiosyncratic and you won't find anything like it (except for mathematical statements, which are a basically special exception).
  2. You are abusing the markup reserved for WP:DLISTs.
  3. You are not marking up unordered lists appropriately as unordered lists. Which those code statements are.

Please undo your edit or I will request assistance. --Izno (talk) 21:40, 9 January 2021 (UTC)[reply]

I am unable to find clear guidance in WP:ACCESS to support your claims. Either way, the guidelines are guidelines, not absolute edicts. Your edits are not improving the article. Not sure what "assistance" you intend to request. Sounds needlessly ominous and threatening. If you have a persuasive case, I think you can make it here. A lot of the content in this article was written over 10 years ago, so it's possible best practices for markup have changed. If you can achieve the same visual appearance but with more modern markup, go for it. But the indentation, use of italics, lack of bullets and the overall visual presentation are intentional, chosen to match the content and make it easier to read and understand. Msnicki (talk) 22:06, 9 January 2021 (UTC)[reply]
If you (two) are talking about this reversion, then I'd like to chip in with an opinion. The approach with indented paragraphs under (non-indented) headings may look attractive in a printed book, but it's (a) not how we do things on Wikipedia (and I know, how we do things here is what we decide, but the fact that we have a Manual of Style is itself a sign that we've decided to present a consistent presentations style), and (b) it generates some messed-up HTML inconsistent with our WP:ACCESS accessibility goals (if you view the source code produced you'll see wacky definition lists, which are bad enough on Talk pages, without infecting our articles with them).
As to the code blocks, I'm less aggrieved here, although I don't see why one user's bold (not bold) usage is better than the syntaxhighlight results that we like to use on all similar pages. I prefer the version previous to the above revert, FWIW. — JohnFromPinckney (talk) 20:35, 21 February 2021 (UTC)[reply]
We don't use indents using definition lists in articles because they serve no purpose and clog up the html so that screen reader users will hear odd markup. This is not a question of visual markup because we also have to consider the experience of visitors who cannot see the text. MOS:BOLD outlines the places where bold text is appropriate, although where it is produced with semantic meaning (such as in source code) there is an exception, and we have <syntaxhighlight>...</syntaxhighlight> for that purpose. Guidelines such as MOS:ACCESS are not optional. They enjoy community-wide consensus and editors ignore them at their peril. Although there may be occasional exceptions, any exceptions have to have strong justification. I don't see any such justification here. --RexxS (talk) 02:29, 22 February 2021 (UTC)[reply]
Agreed with Izno, JohnFromPinckney, RexxS. In short, if you are trying to create a bold pseudo-heading, use '''Pseudo-heading text here''' followed by a blank line. If you are trying to visually indent something, and it is very short, use {{in5}}. If you're trying to visually indent a block of material, use {{Block indent}} (unless it's a direct quotation, in which case use {{Blockquote}}). This is all covered between MOS:ACCESS, MOS:DLIST, MOS:BOLD, MOS:INDENT, MOS:INDENTGAP, and MOS:BQ.  — SMcCandlish ¢ 😼  03:22, 22 February 2021 (UTC)[reply]