Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming Operating Systems Software Unix IT Technology

Switching from tcsh to bash? 89

Posted by Cliff from the preparing-for-major-changes dept.
momerath2003 asks: "With the advent of Mac OS X 10.3 Panther, Apple will switch its default shell from tcsh to bash (in order to conform more to the newer Linux trends). A lot of Mac power users will want to know how to make the switch, especially if they use such tcsh-specific extra files as the login/out scripts in the /usr/share/tcsh/examples directory (they automatically set up some aliases and can automatically read aliases from a specific file, among other things). So, how do we all adapt? What are some ways to emulate the behavior of the example files, and what differences are there between the bash and tcsh shells?"
This discussion has been archived. No new comments can be posted.

Switching from tcsh to bash? More

Switching from tcsh to bash?

Comments Filter:

  • big deal... (Score:4, Insightful)

    by Anonymous Coward on Thursday October 23, 2003 @11:57AM (#7291303)
    I imagine the "power users" who use tcsh will... wait for it ... here it comes ... SWITCH BACK TO TCSH!

    Really, it's no big deal. They are both fine shells. Tcsh is rotten for programming but that doesn't affect most people.
    • That's what I'll be doing.

      I've used tcsh forever (well, I used sh and csh first, but...)

      I like tcsh as my interactive shell. Honestly, I can get bash to ack exactly the same as tcsh, except that I don't know how to do reverse-video in the prompt. But I still like tcsh. I'm used to it.

      If I need to do actual scripting, I use perl. Or ksh, because all the Solaris boxes at work have ksh, but not all of them have bash and/or tcsh (new ones do, but you can't rely on that).
      • How about this?

        PS1="normal\[\033[1;7m\]inverse\033[1;0m\]"

        • Hey, neat. Thanks!

          *waits for lameness filter to time out... doot dee doot...*
          • In fact there's a whole bunch of things you can do with the ANSI escape sequences [isthe.com]. All you have to do is use \e for ESC (or \033 if octal is your thing.) bash also includes the \[ and \] meta-escape characters that you put around non-printing escape sequences to let the shell know that they're non-printing.

            My bash prompt is currently:
            PS1='\[\e]0;\l \w\007\]\n($?) \t \[\e[36m\]\l \[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n$ '

            The "ESC]0;foo\007" bit sets the rxvt terminal title to the current tty and path. $
    • This is mac-world. I'm pretty sure soon a decision will come down from On High (Apple HQ) claiming that one or the other is superior for some set of UI bullet points (like they do with their GUIs) and will be blessed by The One (Steve Jobs). Since Mac doesn't really like UI differences I'm sure the one they choose not to go with will become heavily discouraged, just like any UI that doesn't match the Apple GUI guidelines is.
    • I think those of us with Mac OS X and half a klew already use standards compliant methods to make sure scripts work on any platform, i.e.:

      #!/bin/sh -
      echo "Hello World!"
      exit 0

      99.2% of people using Mac OS X prolly don't use a shell anyway.

      With 18+ years unix I've gone from hard copy tty line printer consoles, to vt100's, wyse 75, wysel 180, to a cranky old toshiba 5200 plazma screen ( loved that ) running Xenix, then SCO, then 386/ix, and eventually BSD/386. I tried using a toshiba techra 8200 with windows
  • I already installed fink, and use Bash now. So no switch here.

    First thing I did when I got my mac, was install fink, and call bash. All my scripts and aliases are for Bash. Glad to see OSX will using bash native, since every unix box I have uses bash (or ksh).

    Now if I could just get a better terminal program like konsole to run native, instead of under X. iTerm is ok, but still has some quirks, thou it does have nice transperancy, gotta love that icandy.
    • Mac OS X already includes /bin/bash, though not as the default shell. Sure, Fink contains a copy also (perhaps a newer one), but is not required.

      First thing I do on any new Mac OS X box is to go into the NetInfo manager and change my (and root's) login shell to /bin/bash.

  • You can always edit /etc/passwd and change it from bash back to tcsh. Or maybe chsh works in OS X? As far as alaises, etc. go there is tons of help on the web, and of course you could always "man bash".

  • Put "set editing-mode vi" into your .inputrc file.
  • RTFM :D

    /etc/bashrc
    /etc/profile
    ~/.bashrc
    ~/bash_profile

    RedHat spoiled me, so I change my prompt on any machine I have that's bash capable.

    export PS1='[\u@\h \W]$ '
    • I recommend: PS1='\u@\h \[\033[1;31m\]\w\[\033[0m\]: ' Makes the working directory go red :) I'm sure most people would change the : back to a $ though...

    • Re:Easy (Score:2)

      by sICE ( 92132 )
      i use:

      PS1="\n\033[93;44m\n\033[93;92mDate: \033[93;44m\d, \t \033[0;92m\nUser: \033[0;97m[\033[0;93m\u\033[0;97m@\033[0;93m\H\033 [0;97m] \033[0;92mJobs: \033[0;97m[\033[0;93m\j\033[0;97m]\033[0;92m History: \033[0;97m[\033[0;93m\!\033[0;97m]\033[0;39m\n\033 [0;93m\w\033[0;97m$\033[0;39m"

      it displays a blue line in background when the screen scroll and it's easy to spot where you left sometimes (when you have 1000+ lines in your term buffer)

  • Um, different user target (Score:4, Insightful)

    by mugnyte ( 203225 ) * on Thursday October 23, 2003 @12:22PM (#7291545) Journal

    By the very nature of *nix environment, one should be able to switch shells without much problem. Leftover habits when coding may keep creeping in, but consistency is key. If you've done any awk/sed/csh/bash/ksh like programming, one realizes that not all the world is one language - yet.

    Presupposing that people will have "trouble" switching is kind of assuming we're dealing with a "who moved my cheese" user seen more on corporate win32 desktops. Any techie worth their salt knows how to get a job done in a shell. Perhaps the most exasperating are the escape sequences. But one just see the runtime differences and plods through the changes. no magic here.

    mug

  • Shell functions (Score:5, Informative)

    by Anonymous Cowdog ( 154277 ) on Thursday October 23, 2003 @12:23PM (#7291552) Journal
    One thing that helps in bash is shell functions, because in bash aliases don't take command line arguments (unless my copy of Unix Power Tools is wrong).

    Here's a couple examples of shell functions. I use these to put and get files to/from my notebook from my desktop (put these in .bashrc):

    nb-put () { scp $1 me@192.168.0.9:/home/me/$2; }
    nb-get () { scp me@192.168.0.9:/home/me/$1 .; }

    So then to get a file I just do nb-get <filename>

    Another thing that is nice to know is how to do for loops from the command line in bash. Not that it's hard, it's just different from tcsh:

    for n in 1 2 3; do echo $n; done

    • Another thing that is nice to know is how to do for loops from the command line in bash. Not that it's hard, it's just different from tcsh:

      for n in 1 2 3; do echo $n; done

      Out of curiosity, how would that loop be done in tcsh? I generally prefer tcsh as my interactive shell (the spell checker embedded in the tab-completion saves me from typos all the time), but if I want to do anything as complex as a loop construct, I always just drop into a bash shell to do it.

      I think bash is the better shell for s

      • Input in plain text, output in italics:

        % foreach n ( 1 2 3 )
        foreach -> echo $n
        foreach -> end
        1
        2
        3
        %

        -Ster

      • >for n in 1 2 3; do echo $n; done
        >Out of curiosity, how would that loop be done in tcsh?

        I don't know how you would do it as a one-liner. That's one of the reasons I prefer bash -- after doing a for loop, I can just Ctrl-P back to it if I need to do it again, or do it again with edits.

        In tcsh, you do:

        > foreach n (1 2 3)
        foreach? echo $n
        foreach? end

        But this is not on one line. So then if you do Ctrl-P to get back the foreach line, that's all you get -- the first line. You may have had some complic
      • after 15+ years on tcsh, this issue bugged me so much that i ended up with this solution:

        <a href="http://www.fictive.com/t/tdb/shell/loop/">ht tp://www.fictive.com/t/tdb/shell/loop/</a>

        (i would have posted it here, but the aliases employ a few iso8859-1 characters which didn't make it through /.'s form. sorry about that).

    • for n in 1 2 3; do echo $n; done

      most relevantly for me, the ability to recall and re-execute such a command-line for loop using 'up-arrow' in bash .... in csh you just get the 'foreach' line.

      Also the ability to pipe the output from whole sections of code within ( ) through a subsequent pipeline.

  • FAQs (Score:2, Informative)

    by citmanual ( 2002 )
    Google "bash tcsh differences" yields:

    "UNIX shell diferences and how to change your shell."

  • Googling for "bash tcsh differences" yields:

    "UNIX shell differences and how to change your shell"
    http://www.faqs.org/faqs/unix-faq/shell/sh ell-diff erences
  • Linux using Bash as the default shell is not a "newer Linux trend". As for the differences, there is a lot of information on each shell available on the web.

    Google is your friend.
    • Using bash as the default scripting shell *IS* a newer Linux trend. Bash has been around on other systems for ages, but no one had been silly enough to link /usr/bin/bash to /bin/sh until this one Linux party where they passed around some bad Tequila. (Thank goodness P.V. wasn't at the shindig!)

      Of course, the fact that bash will gladly accept its extensions when running in POSIX mode only worsens the issue. If you're going to write a bash script, at least have the courtesy to designate it with "#!/usr/bin

  • script mod (Score:4, Informative)

    by gmhowell ( 26755 ) <gmhowell@gmail.com> on Thursday October 23, 2003 @12:54PM (#7291946) Homepage Journal
    If you are worried about scripts, something like:

    #!/bin/tcsh

    Should appear on line one of the script.

    • If you find yourself writing C-shell-family script, consider a nice crack pipe and some hash brownies. Because you're fucking insane already. KIlling the rest of your brain cells would be a harmless mod. (I don't believe gmhowell to be one of these people; it just needed to be said.)

      The C shell was written "to mimic the C programming language." What's the primary tool in the C programming language? Functions. What did csh remove that all other shells had? Functions. What are you supposed to use i

      • Nope, not a crack smoking C-shell monkey. When I have to write a script, it's bash for me. I just couldn't figure out why the article post mentioned scripts specifically. How does choice of shell influence what a script runs, unless it makes many stoopid assumptions, like being called from a specific shell.


        • If I'm remembering POSIX correctly, when the kernel goes to exec an interpreted file that doesn't have a #! at the beginning, it always uses /bin/sh. (Otherwise it would have to do things like look up the current user's login shell, or try to find the parent process and see what shell it is, etc, etc, all of which would be slow and fragile.)

          So the article post is completely moronic; the currently running shell has no effect at all on an executed script.

          • when the kernel goes to exec an interpreted file that doesn't have a #! at the beginning, it always uses /bin/sh
            Exactly, and if you are using anything other than sh, you know to do the who # !/bin/shell thing at the top of the script
      • > If you find yourself writing C-shell-family script, consider a nice crack pipe and some hash brownies. Because you're fucking insane already. KIlling the rest of your brain cells would be a harmless mod. (I don't believe gmhowell to be one of these people; it just needed to be said.)
        >
        > The C shell was written "to mimic the C programming language." What's the primary tool in the C programming language? Functions. What did csh remove that all other shells had? Functions. What are you
  • Just run bash --tcsh scriptfile of course!
  • I don't understand why anybody would want to change bash to tcsh.

    When I started playing with FreeBSD I was forced to used tcsh, since it is installed by default.
    After some initial problems (like different keys for auto-completition and history filtering according to what you started to type) I actually started to like this style. And today, I'm left contemplating whether I should change my default shell in Linux to tcsh. But that would mean to change lots of files:
    Just imagine, you donwload something n
    • And today, I'm left contemplating whether I should change my default shell in Linux to tcsh. But that would mean to change lots of files:
      Just imagine, you donwload something nice, do "./configure" and - voila - syntax error.

      Huh? configure scripts should have

      #! /bin/sh

      as its first line, so it really shouldn't be a problem. (/bin/sh is usually just a link to bash on Linux systems.)

      K.
    • I don't understand why anybody would want to change bash to tcsh.

      I grew up on tcsh, and csh before it (IIRC, csh was the default login shell in SunOS 5.0). Darnit, I like tcsh. Aliases work like they ought to, and setting shell variables is straightforward and intuitive. I think bash is just a bad shell dream, and replace it as my login shell everywhere it shows up.YMMV, but I get 100 mpg out of tcsh, where I only get 60 mpg out of bash.
    • 1. You have too much disk space, and want a shell that's 50% bigger.

      2. Setting environment variables via setenv is too intuitive, you'd prefer a stupid non-mnemonic command like "export" (to what?)

      3. You'd rather run scripts in a huge shell than in a compact scripting language suited to the task such as python or perl.

      4. You have a bizarre belief that your scripting language and your interactive shell need to be the same program.

      5. You worship Richard Stallman.
    • history filtering according to what you started to type
      To do this in bash:

      bind '"\M-[A":history-search-backward'
      bind '"\M-[B":history-search-forward'
    • > I don't understand why anybody would want to
      > change bash to tcsh.

      Same here.

      > And today, I'm left contemplating whether I should
      > change my default shell in Linux to tcsh.

      Go for it. When I was using Slackware Linux, I used tcsh as my default shell, (I can't stand bash personally) and I never had any problems of that nature. From what I understand the bourne-dependent scripts that would take issue with this would default to bourne or bash anyway.... Defaulting root to tcsh might cau

  • Setting variables (Score:4, Informative)

    by PeekabooCaribou ( 544905 ) <slashdot@bwerp.net> on Thursday October 23, 2003 @01:27PM (#7292386) Homepage Journal
    I'm not a huge tcsh user, but the most immediate difference is the way variables are set in the two shells. Here's tcsh:

    % setenv PATH ${PATH}:/usr/local/bin
    % echo $PATH
    /bin:/usr/bin:/usr/local/bin
    % unsetenv PATH

    And bash:

    $ export PATH=$PATH:/usr/local/bin
    $ echo $PATH
    /bin:/usr/bin:/usr/local/bin
    $ unset PATH

    There are other differences, of course, but it's a start.

    • Dont forget that tcsh has two concepts of 'variables' - shell variables and environment variables.

      In tcsh, you shouldn't muck with environment variable PATH, you should set shell variable 'path' instead, eg

      set path=(/usr/bin /home/me/bin)

      instead of

      setenv PATH /usr/bin:/home/me/bin

      bash has only variables, which, if 'export'ed, become part of the environment.

      Baz
      • While this is technically true, your last sentence holds the key:
        bash has only variables, which, if 'export'ed, become part of the environment.

        So just don't export the variables used locally in your script. Set a local path variable like you would in tcsh:

        locpath="/usr/bin:/home/me/bin"

        If not exported, it goes away at the end of the script.
    • I put this in my .bashrc and it seems to work:

      setenv () { export $1=$2; }
      unsetenv () { unset $1; }

      Then "setenv" works for bash for at least some things, like setting DISPLAY.

  • Flashback (Score:5, Informative)

    by AT ( 21754 ) on Thursday October 23, 2003 @01:41PM (#7292545)
    Wow, flashback to 1995, when *I* transitioned from tcsh to bash. I had grown up on older Sun boxen where csh/tcsh was the prefered shell, but as I started using other Unices like Linux and AIX and as I started writing more shell scripts (especially little one-off scripts in interactive sessions), I decided to make the jump to bash.

    All in all, bash is a better shell, especially for scripting. Back then tcsh was more configurable and usable, but by now I think tcsh has fallen behind. Anyway, there is a one-to-one mapping between most tcsh and bash features. The only diffence is the syntax: export X=Y instead of setenv X Y, alias foo="bar" instead of alias foo "bar".

    When I switched, the two things I missed the most were tcsh's programmable completion, which is only matched by bash in version 2, and the method of doing a reverse search of the command history (tcsh's esc-p vs. bash's esc-r).

    There are lots of great sites on getting the most from bash; here are a few good starting points:
    ftp://ftp.cwru.edu/pub/bash/FAQ [cwru.edu]
    http://www.caliban.org/bash/index.shtml [caliban.org]
    http://www.deadman.org/bash.html [deadman.org]
    • All in all, bash is a better shell, especially for scripting.

      Any bourne-like shell is better for scripting. Way back when, sh and descendents were for scripting, while csh and descendents were for users. Without bash, that would still be true. But bash gave us all the goodness of ksh and tcsh in one package.

      I still program in plain vanilla bourne shell (because it's the Right Thing(tm) to do), but my user shell is bash instead of tcsh.
      • I still program in plain vanilla bourne shell (because it's the Right Thing(tm) to do), but my user shell is bash instead of tcsh.

        The right thing to do if you enjoy using backticks and eval statements.
    • I just made the switch this year after after being universally mocked for my shell choice for 8 years. I tried bash about every year to see if it could compete with tcsh, and for my purposes it only caught up this year. The default bash on OSX is still old and clunky. I set the following in my .inputrc to get tcsh-like esc-p completion:

      "\ep": history-search-backward

      Here are some other nice ones that conform to my former tcshrc:

      set bell-style none
      set completion-ignore-case on
      set show-all-if-ambiguous

      • I went back and looked at pushd again, and tcsh's implementation is really a lot better. It doesn't always echo dirs when you push, so tcsh's pushd is quieter, bash requires passing -P to cd to get it to behave, and bash's pushd doesn't have that option, and bash's pushd doesn't clear out duplicates in its stack.

        The quirky scripting syntax aside, tcsh is a really feature-rich, mature shell. I miss it dearly in my heart of hearts.

  • it would be nice if OS X actually let the user set the shell from the system preferences...on the other, anybody who cares will do it themselves and forget about it.
  • This may be a strange question -- my questions often are -- but why change just because the OS/X default changed? It's easy enough to change it back: I suspect there's a version of chsh(1), but even if there isn't, it's just the last parameter in /etc/passwd.

  • My brief summary (Score:2, Informative)

    by chad_r ( 79875 )

    What, no bash-vs-tcsh flames yet?

    After using tcsh for about 5 years, I gradually moved to bash everywhere. For me, there were a few annoyances I was glad to be rid of:

    • ability to redirect stdout and stderr separately:
      ( cmd > file.out 2> file.err)
    • nested command substitution, when using $() instead of ``:
      ls -aFl $(find $(locate xterm) -type f -perm -a+x)
    • More straightforward syntax, with the possibility of fitting while/if/case blocks on a single command line (especially useful for comm
  • Having used tcsh quite a lot (on Linux and Irix and Cygwin) and having to switch to bash, I have to say that 95% of the problem is that I am very used to typing "setenv", and also a lot of "sourced" type scripts that do nothing except setenv (ie we use lots of "source setup_foobar" to get around stupid programs that have conflicting requirements for environment variables)

    A big help would be a simple alias for bash that makes setenv work like tcsh. Just put this in the default login or something.
  • # .bashrc # User specific aliases and functions # Source global definitions if [ -f /etc/bashrc ]; then . /etc/bashrc fi alias exchange='rdesktop -l -g 1280x1024 -u paugros -d region6 localhost' alias ajax='ssh root@216.177.28.62' alias visa='netscape http://service.capitalone.com/' alias cdrom='mount /mnt/cdrom && cd /mnt/cdrom' alias cdrom1='mount /mnt/cdrom1 && cd /mnt/cdrom1' alias floppy='mount /mnt/floppy && cd /mnt/floppy' alias ucdrom='cd && umount /mnt/cdr
  • I would be interested to know what is motivating the shift exactly. I gather that the poster is not intending to use bash to write lengthy programs. On the other hand, it sounds like some other posters do use some variant of shell to write long programs. For what exactly? Is it really more convenient than using another scripting language? Part of the motivation for this question is that I have developed a little prototype optimizing interpreter for a shell-language subset (basically sh) and am looking for a
  • Just tell them not to try Apple bash with a 'Hammer', it won't work! Apart from that it is not as intuitive to write pure C on, and is in some ways alot more flexable and easier to navigate.

    The first command to learn is ($) man bash ... apart from that it is alot easier to make files and run scripts with. Another essential command is ($) man man

    I just hope the Apple guys include the man program and docs if not it will flop big time. Bash rocks!

  • Unless the assumption is that any significant portion of the OS X user base actually uses the shell, I doubt there will be many that even notice.

    I still view OS X as a definite non-unix. It's right up there with say, windows+cygwin. A non-unix kernel with some unix userland stuff sprinkled on top.

    And to address the "But it's the best integrated Unix desktop ever!" argument, tell me why the tar that ships with it breaks all the filesystem meta information (which many mac apps still rely on, in my exper
  • So, if Apple's going to make me mess around to get a shell I don't actively loathe, I may as well consider all the possibilities.

    So... which shell should I use, and why?

    To give you some ideas for what I'm looking for:

    - I don't care about scripting. If I want to write a script, I'll use a scripting language.

    - Mnemonic commands are good.

    - Good command-line editing that uses sensible keystrokes (e.g. Home and End work) is good.

    - Small memory requirements and high CPU efficiency are very good.
  • I don't own a Mac, but I work with the art dept who do. Me being the computer guy they expect me to be able to fix things, even though my experience with OSX is *very* limited. Having looked through all the menus, and some of the program folders, I can't even seem to find the shell in the first place - where the fsck is it?
  • Considering that Apple seems to avoid gpl'd programs, (curl vs. wget for example) using bash instead of tcsh is quite strange. From an end-user perspective, it makes absoutely no difference, both are excellent interactive shells, and scripting shouldn't be an issue either.

    I personally use tcsh, but I write my scripts for bourne. The bash scripting argument is weak if you ask me, simply because it isn't as portable as sh, and its extensions offer very little (if anything) beyond bourne for scripting. Wh

Slashdot Top Deals

"Ninety percent of baseball is half mental." -- Yogi Berra

Close