{"id":194,"date":"2020-08-18T19:23:47","date_gmt":"2020-08-18T20:23:47","guid":{"rendered":"http:\/\/www.linux-tutorial.info\/?page_id=77"},"modified":"2020-08-22T19:26:39","modified_gmt":"2020-08-22T20:26:39","slug":"this-is-the-page-title-toplevel-28","status":"publish","type":"page","link":"http:\/\/www.linux-tutorial.info\/?page_id=194","title":{"rendered":"The C-Shell"},"content":{"rendered":"\n<title>The C-Shell<\/title>\n<p>\nOne of the first &#8220;new&#8221; shells to emerge was the csh or C-Shell. It is so\nnamed because much of the syntax it uses is very similar to the C programming\nlanguage. This isn&#8217;t to say that this <glossary>shell<\/glossary>\nis only for C programmers, or programmers in general. Rather, knowing C makes learning the\nsyntax much easier. However, it isn&#8217;t essential. (Note: The csh syntax is <em>similar to C<\/em>,\nso don&#8217;t get your dander up if it&#8217;s not <em>exactly<\/em> the same.)\n<\/p>\n<p>\nThe csh is normally the <glossary>shell<\/glossary> that users get on many <glossary>UNIX<\/glossary>\nsystems. Every place I ever got a <glossary>UNIX<\/glossary>\n<glossary>account<\/glossary>,\n it was automatically assumed that I wanted csh\nas my <glossary>shell<\/glossary>.\n When I first started out with <glossary>UNIX<\/glossary>,\n that was true. In fact, this is\ntrue for most users. Because they don&#8217;t know any other shells, the csh is a good\nplace to start. You might actually have tcsh on your system, but the principles\nare the same as for csh.\n<\/p>\n<p>\nAs you <glossary>login<\/glossary>\nwith csh as your <glossary>shell<\/glossary>, the system first looks in the global\nfile <file>\/etc\/cshrc<\/file>. Here, the system <glossary>administrator<\/glossary>\ncan define variables or actions\nthat should be taken by every csh user. Next, the system reads two files in your\nhome directory: .login and .cshrc. The .login file normally contains the\nvariables you want to set and the actions you want to occur each time you log\nin.\n<\/p>\n<question id=\"61\" text=\"On most systems it is okay for the root user to have the C-Shell as its default shell.\" \/>\n<p>\n<concept id=\"\" description=\"On most systems it is not a good idea for the root user to have the C-Shell as its default shell.\" \/>\nIn both of these files, setting variables have a syntax that is unique to\nthe csh. This is one <em>major<\/em> difference between the csh and\nother shells. It is also a reason why it is not a good idea to give root csh\nas its default <glossary>shell<\/glossary>.\n The syntax for csh is\n<\/p>\n<question id=\"62\" text=\"What is C-shell syntax to define a variable?\" \/>\n<p>\n<commandexample>set variable_name=value<\/commandexample>\n<\/p>\n<p>\nwhereas for the other two, it is simply\n<\/p>\n<p>\n<commandexample>variable=value <\/commandexample>\n<\/p>\n<p>\nBecause many of the system commands are Bourne scripts, executing them with\ncsh ends up giving you a lot of syntax errors.\n<\/p>\n<question id=\"\" type=\"\" text=\"What are the two common configuration files for csh?\" \/>\n<p>\nOnce the system has processed your .login file, your .cshrc is processed.\nThe .cshrc contains things that you want executed or configured every time you\nstart a csh. At first, I wasn&#8217;t clear with this concept. If you are logging in\nwith the csh, don&#8217;t you want to start a csh? Well, yes. However, the reverse is\nnot true. Every time I start a csh, I don&#8217;t want the system to behave as if I\nwere logging in.\n<\/p>\n<question id=\"63\" text=\"What does the C-Shell SHELL variable define?\" \/>\n<p>\nLet&#8217;s take a look as this for a minute. One of the variables that gets set\nfor you is the SHELL <glossary>variable<\/glossary>. This is the <glossary>shell<\/glossary>\nyou use anytime you do a\n<i><em>shell escape<\/em><\/i> from a program. A <glossary>shell<\/glossary>\nescape is starting a shell as a subprocess of a program. An example of a program that allows a <glossary>shell<\/glossary> escape is vi.\n<\/p>\n<p>\nWhen you do a <glossary>shell<\/glossary>\nescape, the system starts a shell as a new (child)\nprocess of whatever program you are running at the time. As we talked about\nearlier, once this <glossary>shell<\/glossary>\nexits, you are back to the original program. Because\nthere is no default, the <glossary>variable<\/glossary>\n<i><em>must<\/em><\/i> be set to a <glossary>shell<\/glossary>.\n If the variable is set to something else, you end up with an <glossary>error message<\/glossary>\nlike the following from vi:\n<\/p>\n<p>\n<commandexample>invalid SHELL value: &lt;something_else&gt;<\/commandexample>\n<\/p>\n<p>\nwhere &lt;something_else&gt; is whatever your SHELL <glossary>variable<\/glossary>\nis defined  as.\n<\/p>\n<p>\nIf you are running <command>csh<\/command> and your SHELL <glossary>variable<\/glossary>\nis set to <command>\/bin\/csh<\/command>, every\ntime you do a <glossary>shell<\/glossary>\nescape, the shell you get is csh. If you have a .cshrc file\nin your <glossary>home directory<\/glossary>,\n not only is this started when you log in, but\n<i><em>anytime<\/em><\/i> you start a new csh. This can be useful if you want to\naccess personal aliases from inside of subshells.\n<\/p>\n<question id=\"64\" text=\"With the C-Shell you can repeat and edit previous commands.\" \/>\n<p>\nOne advantage that the <command>csh<\/command> offered over the Bourne Shell is its ability to\nrepeat, and even edit, previous commands. Newer shells also have this ability,\nbut the mechanism is slightly different. Commands are stored in a <glossary>shell<\/glossary>\n&#8220;history list,&#8221; which, by default, contains the last 20 commands. This is normally\ndefined in your <file type=\"\">.cshrc<\/file> file, or you can define them from the <glossary>command line<\/glossary>.\nThe command set\n<\/p>\n<commandexample command=\"csh\">history=100<\/commandexample>\n<p>\nwould change the size of your history list to 100.\nHowever, keep in mind that everything you type at the <glossary>command line<\/glossary>\nis saved in the history file. Even if you mistype something, the <glossary>shell<\/glossary>\ntosses it into the\nhistory file.\n<\/p>\n<p>\nWhat good is the history file? Well, the first thing is that by simply\ntyping &#8220;history&#8221; with nothing else you get to see the contents of your history\nfile. That way, if you can&#8217;t remember the exact syntax of a command you typed\nfive minutes ago, you can check your history file.\n<\/p>\n<p>\nThis is a nice trick, but it goes far beyond that. Each time you issue a\ncommand from the csh prompt, the system increments an internal counter that\ntells the <glossary>shell<\/glossary>\nhow many commands have been input up to that point. By default,\nthe csh often has the prompt set to be a number followed by a {3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}. That number is\nthe current command, which you can use to repeat those previous commands. This\nis done with an exclamation mark (!), followed by the command number as it\nappears in the <glossary>shell<\/glossary>\nhistory.\n<\/p>\n<p>\nFor example, if the last part of your <glossary>shell<\/glossary>\nhistory looked like this:\n<\/p>\n<p>\n<screenoutput>\n21 date\n22 vi letter.john\n23 ps\n24 who\n<\/screenoutput>\n<p>\nYou could edit <file type=\"\">letter.john<\/file> again by simply typing in <keyinput>!22<keyinput>. This repeats the\ncommand vi letter.john and adds this command to your history file. After you\nfinish editing the file, this portion of the history file would look like\n<\/p>\n<p>\n<screenoutput>\n21 date\n22 vi letter.john\n23 ps\n24 who\n25 vi letter.john\n<\/screenoutput>\n<p>\nAnother neat trick that&#8217;s built into this history mechanism is the ability to\nrepeat commands without using the numbers. If you know that sometime within your\nhistory you edited a file using vi, you could edit it again by simply typing\n!vi. This searches backward though the history file until it finds the last time\nyou used vi. If there were no other commands since the last time you used vi,\nyou could also Enter !v.\n<\/p>\n<p>\nTo redo the last command you entered, you could do so simply by typing in\n<keyinput>!!<keyinput>.\n<\/p>\n<p>\nThis history mechanism can also be used to <em>edit<\/em> previously issued\ncommands. Lets say that instead of typing vi letter.john, we had typed in\n<keyinput>vi letter.jonh<\/keyinput>. Maybe we know someone named jonh, but that&#8217;s not who we meant to\naddress this letter to. So, rather than typing in the whole command, we can edit\nit. The command we would issue would be !!:s\/nh\/hn\/.\n<\/p>\n<p>\nAt first, this seems a little confusing. The first part, however, should be\nclear. The &#8220;!!&#8221; tells the system to repeat the previous command. The colon (:)\ntells the <glossary>shell<\/glossary>\nto expect some editing commands. The &#8220;<keyinput>s\/nh\/hn\/<keyinput>&#8221; says to\nsubstitute for pattern nh the hn. (If you are familiar with vi or sed, you\nunderstand this. If not, we get into this syntax in the\n<tutorial id=19>section on regular expressions and metacharacters<\/tutorial>.)\n<\/p>\n<p>\nWhat would happen if we had edited a letter to john, done some other work\nand decided we wanted to edit a letter to chris instead. We could simply type\n<keyinput>!22:s\/john\/chris\/<keyinput>. Granted, this is actually more keystrokes than if we had\ntyped everything over again. However, you hopefully see the potential for this.\nCheck out the csh <glossary>man-page<\/glossary>\nfor many different tricks for editing previous\ncommands.\n<\/p>\n<p>\nIn the default .cshrc are two aliases that I found quite useful. These are\npushd and popd. These aliases are used to maintain a directory &#8220;stack&#8221;. When you\nrun pushd &lt;dir_name&gt;, your current directory is pushed onto (added to) the\nstack and you change the directory to &lt;dir_name&gt;. When you use popd, it\npops (removes) the top of the directory <glossary>stack<\/glossary>\nand you change directories to it.\n<\/p>\n<p>\nLike other kinds of stacks, this directory <glossary>stack<\/glossary>\ncan be several layers deep. For example, lets say that we are currently in our\n<glossary>home directory<\/glossary>.\nA &#8220;<keyinput>pushd \/bin<keyinput>&#8221; makes our current directory <directory>\/bin<\/directory> with our <glossary>home directory<\/glossary>\nthe top of the stack. A &#8220;<keyinput>pushd \/etc<keyinput>&#8221; brings us to <directory>\/etc<\/directory>. We do it one more time with <command>pushd<\/command>\n<directory>\/usr\/bin<\/directory>, and now we are in \/usr\/bin. The directory \/usr\/bin is now the top of the <glossary>stack<\/glossary>.\n<\/p>\n<p>\nIf we run <command>popd<\/command> (no argument), <directory>\/usr\/bin <\/directory>is popped from the <glossary>stack<\/glossary>\nand \/<directory>etc<\/directory> is\nour new directory. Another <command>popd<\/command>, and <directory>\/bin<\/directory> is popped, and we are now in \/bin. One\nmore pop brings me back to the <glossary>home directory<\/glossary>.\n(In all honesty, I have never used this to do anything more than to switch directories, then jump back to where I was. Even that is a neat trick.)\n<\/p>\n<p>\nThere is another useful trick built into the <command>csh<\/command> for changing directories.\nThis is the concept of a directory path. Like the execution <glossary>search path<\/glossary>,\n the\ndirectory path is a set of values that are searched for matches. Rather than\nsearching for commands to execute, the directory path is searched for\ndirectories to change into.\n<\/p>\n<question id=\"65\" text=\"The cdpath variable defines your default search path for changing directories.\" \/>\n<concept id=\"100\" description=\"The cdpath variable defines your default search path for changing directories.\" \/>\n<p>\nThe way this works is by setting the cdpath <glossary>variable<\/glossary>. This is done like any\nother <glossary>variable<\/glossary> in csh. For example, if, as system <glossary>administrator<\/glossary>,\n we wanted to\ncheck up on the various spool directories, we could define cdpath like this:\n<\/p>\n<p>\n<commandexample>set cdpath = \/usr\/spool<\/commandexample>\n<\/p>\n<p>\nThen, we could enter\n<\/p>\n<p>\n<commandexample>cd lp <\/commandexample>\n<\/p>\n<p>\nIf the <glossary>shell<\/glossary>\ncan&#8217;t find a <glossary>subdirectory<\/glossary>\nnamed lp, it looks in the cdpath\nvariable. Because it is defined as \/usr\/spool and there is a \/usr\/spool\/lp\ndirectory, we jump into \/usr\/spool\/lp. From there, if we type\n<\/p>\n<p>\n<commandexample>cd mail <\/commandexample>\n<\/p>\n<p>\nwe jump to \/usr\/spool\/mail. We can also set this to be several directories,\nlike this:\n<\/p>\n<p>\n<commandexample>set cdpath = ( \/usr\/spool \/usr\/lib \/etc ) <\/commandexample>\n<\/p>\n<p>\nIn doing so, each of the three named directories will be searched.\n<\/p>\n<concept id=\"101\" description=\"The cdspell mechanism attempts to figure out the correct spelling when changing directories.\" \/>\n <question id=\"66\" text=\"The cdspell mechanism attempts to figure out the correct spelling when changing directories.\" \/>\n<p>\nThe csh can also make guesses about where you might want to change\ndirectories. This is accomplished through the cdspell <glossary>variable<\/glossary>.\n This is a\nBoolean <glossary>variable<\/glossary>\n(true\/false) that is set simply by typing\n<\/p>\n<p>\n<commandexample>set cdspell <\/commandexample>\n<\/p>\n<p>\nWhen set, the cdspell <glossary>variable<\/glossary>\ntells the csh that it should try to guess\nwhat is really meant when we misspell a <glossary>directory name<\/glossary>.\n For example, if we typed\n<\/p>\n<p>\n<commandexample command=\"bash\">cd \/sur\/bin (instead of \/usr\/bin) <\/commandexample>\n<\/p>\n<p>\nthe cdspell mechanism attempts to figure out what the correct spelling is.\nYou are then prompted with the name that it guessed as being correct. By typing\nin anything other than &#8220;n&#8221; or &#8220;N,&#8221; you are changing into this directory. There\nare limitations, however. Once it finds what it thinks is a match, it doesn&#8217;t\nsearch any further.\n<\/p>\n<p>\nFor example, we have three directories, &#8220;a,&#8221; &#8220;b,&#8221; and &#8220;c.&#8221; If we type &#8220;cd\nd,&#8221; any of the three could be the one we want. The <glossary>shell<\/glossary>\nwill make a guess and\nchoose one, which may or may not be correct.\n<\/p>\n<p>\nNote that you may not have the C-Shell on your system. Instead, you might\nhave something called tcsh. The primary difference is that tcsh does command\nline completion and <glossary>command line<\/glossary>\nediting.\n<\/p>\n","protected":false},"excerpt":{"rendered":"<p>The C-Shell One of the first &#8220;new&#8221; shells to emerge was the csh or C-Shell. It is so named because much of the syntax it uses is very similar to the C programming language. This isn&#8217;t to say that this &hellip; <a href=\"http:\/\/www.linux-tutorial.info\/?page_id=194\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-194","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/194","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=194"}],"version-history":[{"count":1,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/194\/revisions"}],"predecessor-version":[{"id":736,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/194\/revisions\/736"}],"wp:attachment":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=194"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}