Slashdot Mirror

← Back to Stories (view on slashdot.org)

Switching from tcsh to bash?

Posted by Cliff on 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?"

89 comments

  1. big deal... by Anonymous Coward · · Score: 4, Insightful

    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.

    1. Re:big deal... by Jethro · · Score: 1

      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).

      --


      In the land of the blind, the one-eyed man is kinky.
    2. Re:big deal... by AuMatar · · Score: 1

      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 still have more fans than freaks. WTF is wrong with you people?
    3. Re:big deal... by Gudlyf · · Score: 1
      How about this?

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

      --
      Trolls lurk everywhere. Mod them down.
    4. Re:big deal... by Jethro · · Score: 1

      Hey, neat. Thanks!

      *waits for lameness filter to time out... doot dee doot...*

      --


      In the land of the blind, the one-eyed man is kinky.
    5. Re:big deal... by oobar · · Score: 1

      In fact there's a whole bunch of things you can do with the ANSI escape sequences. 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. $? is the exit code of the last command, \t is the time, \l is the tty, \u is the user name, \h is the hostname, \w is the CWD. (All of these are in the bash info pages.)

  2. Bash with Fink. by BrookHarty · · Score: 1

    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.

  3. No change forced... by i.r.id10t · · Score: 1

    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".

    --
    Don't blame me, I voted for Kodos
    1. Re:No change forced... by Col.+Klink+(retired) · · Score: 1

      > You can always edit /etc/passwd

      Why not use the command designed for this sort of thing, "chsh"?

      --

      -- Don't Tase me, bro!

    2. Re:No change forced... by notfancy · · Score: 5, Informative

      >> You can always edit /etc/passwd

      > Why not use the command designed for this sort of thing, "chsh"?

      Since chsh updates /etc/passwd, and since Mac OS X doesn't generally rely on /etc files but on the NetInfo database, neither would work. You have to use the niutil command or the NetInfo Manager application (it lives in Applications/Utilities).
    3. Re:No change forced... by i.r.id10t · · Score: 1

      If you noticed, I did ask if there was a chsh in OSX....

      --
      Don't blame me, I voted for Kodos
    4. Re:No change forced... by PeekabooCaribou · · Score: 2, Informative
      % sudo niutil -createprop / /users/$USER shell /bin/bash

      As you mentioned, chsh will not work.

      --
      "I'll say it again for the logic-impaired." -- Larry Wall.
    5. Re:No change forced... by GrumpyOldMan · · Score: 0

      No need to change your shell. Just create a file
      called .profile in your home directory with this
      in it:

      if [ -f /bin/tcsh ]; then
      exec /bin/tcsh
      fi

      That will start tcsh each time you ssh in, or start a Terminal window.

    6. Re:No change forced... by Anonymous Coward · · Score: 0

      The rumor is that chsh WILL work in 10.3 (I'm not yet able to test)

      Can anyone confirm?

    7. Re:No change forced... by Anonymous Coward · · Score: 0

      Sorry, doesn't work.

    8. Re:No change forced... by geggibus · · Score: 2, Interesting

      You can disable netinfo if you want and just use the "plain files" ...

      Never cared to find out what that lookupd-process is doing?

      There's another way you can make it work....
      You can make some nidump dump something into /etc/passwd, then use chsh, and after that niload a certain file.. ;)

      -K

    9. Re:No change forced... by PeekabooCaribou · · Score: 1

      Yeah, you can enable BSD Configuration Files in Directory Access, but I can't think of a real compelling reason to go that far. Never done it myself, but I assume it works.

      --
      "I'll say it again for the logic-impaired." -- Larry Wall.
  4. hmm... by Anonymous Coward · · Score: 0

    echo "tcsh" > .bashrc

    life is...you know...tough...or something

  5. So, how do we all adapt? by pmz · · Score: 1


    Put "set editing-mode vi" into your .inputrc file.

    --
    Healthcare article at Kuro5hin
  6. Easy by Micro$will · · Score: 1

    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]$ '

    1. Re:Easy by TwistedSquare · · Score: 1

      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...

    2. Re:Easy by sICE · · Score: 1
      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)
      --
      -- search the web
    3. Re:Easy by Anonymous Coward · · Score: 0

      "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..."

      I use PS1="$(rip-slashdot-headlines.sh|uniq) : "

  7. Um, different user target by mugnyte · · Score: 3, Insightful


    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

  8. Shell functions by Anonymous+Cowdog · · Score: 5, Informative

    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

    1. Re:Shell functions by babbage · · Score: 1

      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 scripts (or semi-scripts, like this example) exactly because it seems easier to do constructs like this in bash than it does in tcsh. For general, mundane use though, tcsh just feels friendlier to me, even if it's not as flexible for doing more complex tasks.

      Even if it's the less popular shell by Linux users, I still think that Apple made the right choice by making tcsh the default shell for OSX. They had a unusual, but very nice default setup for it, and it was very pleasant to work with. I hope that the defaults for their bash logins are as nice, or I'll just switch back to using tcsh again.

      --
      DO NOT LEAVE IT IS NOT REAL
    2. Re:Shell functions by Ster · · Score: 1
      Input in plain text, output in italics:

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

      -Ster

    3. Re:Shell functions by Anonymous+Cowdog · · Score: 1

      >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 complicated stuff inside the foreach, and you then have to manually cut and paste it. Or you can just make the whole thing into a shell script, a much better idea. But as far as I know there's no way to do the whole thing in one line using tcsh. If I'm wrong, someone please show us an example that works!

      Also with that for command in bash, you can put in other commands on the same line. Not surprising, but here's how to do it, since the man page is as usual about as clear as mud:

      for n in 1 2 3; do echo "doing ls $n"; ls; echo "done with ls $n"; done

    4. Re:Shell functions by Eula · · Score: 1

      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.

    5. Re:Shell functions by bubbulus · · Score: 1

      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).

    6. Re:Shell functions by bubbulus · · Score: 1

      i know i know. but i swear the menu said "HTML Text" when i hit "Submit"!

    7. Re:Shell functions by Anonymous Coward · · Score: 0
      I recently found (through /. ;-) a neater way to do loops in bash, just wanted to share:

      for ((i=0;i<10;i++)) ; do echo $i; done
  9. FAQs by citmanual · · Score: 2, Informative

    Google "bash tcsh differences" yields:

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

    1. Re:FAQs by Anonymous Coward · · Score: 0
      have you ever consider using:
      <a href=url>title</a>
      Just change the url with the real url, and title with anything that you want the link to say and you have a nice little hyperlink
  10. FAQs by citmanual · · Score: 1

    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

  11. Wow. (Was: Re:FAQs) by Anonymous Coward · · Score: 0

    >Googling for "bash tcsh differences" yields:
    >"UNIX shell differences and how to change your shell"
    >http://www.faqs.org/faqs/unix-faq/shell/s hell-dif ferences

    Did you even click on the link after your oh-so-helpful google didacticism?

    That's one of the least helpful FAQ documents I've ever seen. Just a table of cryptically named commands. Scary. And I think the original post was aimed at Mac users, so this would be *really* scary for them.

  12. Newer Linux Trends by Goo.cc · · Score: 1

    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.

    1. Re:Newer Linux Trends by Brandybuck · · Score: 1

      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/bash".

      --
      Don't blame me, I didn't vote for either of them!
  13. script mod by gmhowell · · Score: 4, Informative

    If you are worried about scripts, something like:

    #!/bin/tcsh

    Should appear on line one of the script.

    --
    Jesus was all right but his disciples were thick and ordinary. -John Lennon
  14. Bash without Fink by Tor · · Score: 1

    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.

  15. tcsh emulation by jhunsake · · Score: 1

    Just run bash --tcsh scriptfile of course!

  16. bash is nice, tcsh is nicer... by kwench · · Score: 1

    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 nice, do "./configure" and - voila - syntax error.

    1. Re:bash is nice, tcsh is nicer... by neden · · Score: 2, Informative

      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.

    2. Re:bash is nice, tcsh is nicer... by Quixotic+Raindrop · · Score: 1

      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.

      --
      Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. (Einstein)
    3. Re:bash is nice, tcsh is nicer... by Captain+Pedantic · · Score: 1

      It was SunOS 4, you tosser. SunOS 5 is Solaris.

      --

      None are more hopelessly enslaved than those who falsely believe they are free. Johann Wolfgang von Goethe.
    4. Re:bash is nice, tcsh is nicer... by Brandybuck · · Score: 1

      /bin/sh is usually just a link to bash on Linux systems

      Boo hiss! Evil! Bad, bad, very bad, not good.

      --
      Don't blame me, I didn't vote for either of them!
    5. Re:bash is nice, tcsh is nicer... by Quixotic+Raindrop · · Score: 1

      Actually, SunOS 5 is co-equivilent with Solaris 2, but it actually reported itself as SunOS 5.x.x when you logged in.

      --
      Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. (Einstein)
    6. Re:bash is nice, tcsh is nicer... by mgaiman · · Score: 1
      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'
    7. Re:bash is nice, tcsh is nicer... by Aeonsfx · · Score: 1
      > 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 cause issues though, haven't tried that.

      Gotta love tcsh! ;)

      --Tim

  17. Setting variables by PeekabooCaribou · · Score: 3, Informative
    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.

    --
    "I'll say it again for the logic-impaired." -- Larry Wall.
    1. Re:Setting variables by Bazman · · Score: 1

      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

    2. Re:Setting variables by IpalindromeI · · Score: 1

      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.

      --

      --
      Promoting critical thinking since 1994.
  18. Flashback by AT · · Score: 4, Informative

    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
    http://www.caliban.org/bash/index.shtml
    http://www.deadman.org/bash.html

    1. Re:Flashback by Brandybuck · · Score: 1

      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.

      --
      Don't blame me, I didn't vote for either of them!
    2. Re:Flashback by figa · · Score: 1
      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 on
      set mark-symlinked-directories on
      set print-completions-horizontally on
      "\en": history-search-forward
      "\t": menu-complete
      "\C-d": delete-char-or-list
      "\C-u": kill-whole-line

      I'm surprised by how many longtime bash users just go with the default settings.

      I'm happy to have made the switch, since Debian has some incredible completions in /etc/bash_completion, especially for apt-get and ant.

      There are still some things that bug me about bash. If anyone knows how to handle them, please reply. I have a hard time writing completion scripts that return a value without appending a space at the end. That wasn't a problem with tcsh. I would like to be able to complete Java class names in a classpath, and I had that working well in tcsh.

      I also don't like that it's difficult to control when bash appends a forward slash to directories. It catches me up when I'm removing symbolic links to directories, and the completion adds a forward slash at the end.

      It also peeves me that bash escapes $ when I complete on a shell variable that is assigned to a directory. Tcsh would leave it alone, and I had a number of variables assigned to my project directories.

      I'm also not happy with how pushd works. In tcsh, pushd without arguments goes to the home directory, and it's easy to alias cd to pushd.

    3. Re:Flashback by figa · · Score: 1
      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.

    4. Re:Flashback by Suppafly · · Score: 1

      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.

  19. more a niggle with OS X by grocer · · Score: 2, Insightful

    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.

  20. But why? by crmartin · · Score: 1

    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.

  21. My brief summary by chad_r · · Score: 2, Informative

    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 command substitutions)
      for file in $files; do mv $file $file.old && echo "$file moved"; done

    • Otherwise, I have made my shell environments pretty similar, to the point that I wouldn't readily notice the difference.

  22. setenv is the only real problem I've ever seen by spitzak · · Score: 1

    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.

    1. Re:setenv is the only real problem I've ever seen by Ella+the+Cat · · Score: 1

      Yep. Happened to me yesterday building nVIDIA drivers, I use tcsh normally, switched to bash, set the enviroment variable bash-style but forgot to -export- it (CC_IGNORE_MISMATCH) - d'oh!

  23. Even better script mod by devphil · · Score: 1


    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 in their place?

    goto

    Give me a fucking break. Teaching scripting in [t]csh is like teaching structured programming in cobol, or recursive programming in fortran77. I'd like to reuse my code, thankyouverymuch, not copy and paste it everywhere.

    --
    You cannot apply a technological solution to a sociological problem. (Edwards' Law)
    1. Re:Even better script mod by gmhowell · · Score: 1

      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.

      --
      Jesus was all right but his disciples were thick and ordinary. -John Lennon
    2. Re:Even better script mod by devphil · · Score: 1


      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.

      --
      You cannot apply a technological solution to a sociological problem. (Edwards' Law)
    3. Re:Even better script mod by Tackhead · · Score: 1
      > 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 in their place?
      >
      > goto

      And to that end: Csh Programming Considered Harmful.

      Anyone who puts me in tcsh had can expect serious bashing or Korn holing in return.

    4. Re:Even better script mod by Suppafly · · Score: 1

      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

  24. ~/.bashrc by polyphemus-blinder · · Score: 1

    # .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/cdrom' alias ucdrom1='cd && umount /mnt/cdrom1' alias ufloppy='cd && umount /mnt/floppy' alias ll='ls -lSh' alias du='du -h' alias ping='ping -U' alias xxx='killall -9' alias ftp='ftp -i' alias df='df -h' alias ls='ls --color=tty' alias lsl='ls -lh' alias lsa='ls -A' alias lsal='ls -Alh' alias lsla='ls -Alh' alias rc='jed ~/.bashrc' alias less='less -M' alias c='clear' alias a='cd ..' alias d='pwd' alias p='ping 216.204.0.33' alias rcs='source ~/.bashrc' ############# # LS_COLORS # ############# # Directories = yellow LS_COLORS=di="33;01" # C source code and object files = white LS_COLORS=$LS_COLORS:"*.c=37;01":"*.C=37;01":"*.h= 37;01":"*.H=37;01" LS_COLORS=$LS_COLORS:"*.cpp=37;01":"*.o=37;01" # Image files = magenta LS_COLORS=$LS_COLORS:"*.JPG=35;01":"*.jpg=35;01":" *.gif=35;01":"*.tif=35;01" LS_COLORS=$LS_COLORS:"*.tiff=35;01":"*.bmp=35;01": "*.xbm=35;01" LS_COLORS=$LS_COLORS:"*.xpm=35;01":"*.ps=35;01":"* .png=35;01" LS_COLORS=$LS_COLORS:"*.fts=35;01":"*.jpeg=35;01" # Archive files = blue LS_COLORS=$LS_COLORS:"*.gz=34;01":"*.tgz=34;01":"* .tar=34;01" LS_COLORS=$LS_COLORS:"*.Z=34;01":"*.zip=34;01":"*. bz=34;01":"*.bz2=34;01" # RPMs = red LS_COLORS=$LS_COLORS:"*.rpm=31;01" PS1="\[\e[1;37m\]\h:\w$\[\e[0;0m\] " PATH=$PATH:$HOME/bin:/sbin:/bin/bash2:/usr/sbin:/u sr/local/bin:/usr/local/sbin:/ usr/games:/usr/local/games:./:/usr/X11R6/lib/xscre ensaver:/home/paul/dev/perl:/u sr/java/j2re1.4.0_01/bin: EDITOR=jed HOME=/home/paulKNOTPLOT_HOME=/usr/local/knot export LS_COLORS PS1 PATH EDITOR KNOTPLOT_HOME unset LESSOPEN #fortune -s #echo

    --

    It's all going according to .plan.
  25. Re:My bash sucks by Anonymous Coward · · Score: 0

    Even vi is straining to keep up as I type this.

    Don't you mean vi lite?

  26. haiku by Anonymous Coward · · Score: 0

    flask of ripe urine
    pressed to bsd lips
    bsd drink up

  27. why shell anyway? by Ristretto · · Score: 1

    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 applications, especially where performance is an issue.

  28. Using Bash on Apple by ratfynk · · Score: 1
    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!

    --
    OH THE SHAME I fell off the wagon and use sigs again!
  29. bash what? by Anonymous Coward · · Score: 0

    what are we bashing now?
    unix, linux, microsoft, macintosh, apple ][, amiga, commodore 64, broadband, dial-up, bbs, vi, emacs, sed, awk, grep, perl, openwindows, motif, xbox, nintendo, sega, atari, intellivision, rambus, sdram, intel, amd, via, nvidia, ati, ...

    whatever happen to the rambus news on slashdot?

    WhatMeWorry

  30. Yeah, but would anyone ever notice? by transiit · · Score: 1

    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 experience). I've heard similar problems with the rest of the user space utils (i.e., cp)

    Or, of course, the complete disregard for the Unix filesystem hierarchy standard

    -transiit

    1. Re:Yeah, but would anyone ever notice? by Anonymous Coward · · Score: 0

      Actually, it use a BSD kernel on a modified Mach Microkernel, and I guess it's UNIXness depends on how you viewed the UNIXness of NeXTStep.

      Apple is trying to phase out metadata, and all new OSX programs are supposed to only rely on one fork. It comes with Stuffit, which handles TAR files and handles metadata properly. If you need to use cp, use the command ditto, which can transfer metadata.

      Apple has extra folders for libraries and applications, but these are Mac applications, not Unix ones. You won't have to run /usr/bin/Safari, but your unix commands, cp, rm, tcsh would be in FHS compatible folders.

      So yes, it's not unix in that it doesn't run X. However, Darwin (The unixy core) would probably look just like a Unix to most, the additional folders seperate the Aqua stuff from the darwin stuff, although I concede that it might be blurred when you look at the /System or /Library folder (Mac is at home, can't check)

  31. Top five reasons to switch to bash by metamatic · · Score: 1

    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.

    --
    GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
    1. Re:Top five reasons to switch to bash by Anonymous Coward · · Score: 0

      1. Unless you're using some really old machine, this shouldn't be a problem. My oldest machine that still works is my home-build linux router. Its a 166Mhz IBM 6x86 with 32MB of RAM and a 6GB hard drive. I have a somewhat minimal install of Debian SID that takes up less than a gig. I don't think the size of bash is going to make too much of a difference. 2. Since no even 1/100th of my commands in the shell is not setting environment vars, this is not a big deal. I'll admit its kinda goofy, but still easily compensated for. 3. Hmm, well I guess. But then on my router, I dont even have python installed but perl is installed. I'm not going to go rewrite every since BASH script in perl just because perl is a better scripting language than bash. I'd have to say that it would really suck to have to use perl as a shell for non-scripting tasks though. That's where BASH is a CLI not just a scripting "host". 4. No they don't have to, but then why are you using tcsh then. That kind of makes your point #3 moot eh? Why even use a CLI at all, might as well just use a GUI and let the scripts sit in python or perl like you said. 5. I could have you killed for taking the name of the GNU/Holy GNU/Father in MS/Vain.

    2. Re:Top five reasons to switch to bash by Anonymous Coward · · Score: 0

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

      To child processes.

      Remember, the only intuitive interface is the nipple. (And maybe the ass as well, for MBAs.)

  32. Related question by metamatic · · Score: 1

    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.

    --
    GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
  33. Don't do this, it breaks sftp by kcurrie · · Score: 1

    That will start tcsh each time you ssh in, or start a Terminal window.
    ..and it will break sftp too, as sftp runs your login shell (and it's associated start up files) prior to starting the sftp after authenticating. Authenticated sessions will now hang with a mod as shown above.

    --
    -- I speak only for myself.
    1. Re:Don't do this, it breaks sftp by GrumpyOldMan · · Score: 1

      Good thing I always use scp..

    2. Re:Don't do this, it breaks sftp by kcurrie · · Score: 1

      Hehe, me too, and when I don't do that I use rsync over ssh like this:
      rsync -e ssh -avr remotebox:/pathto/myfiles /localdir
      ...while cutting over thousands of engineers from telnet/rsh to ssh/scp/sftp I ran into the execing in a shell startup problem at least 20+ times.
      --
      -- I speak only for myself.
  34. Re:big deal... #!/bin/sh - ????? by dezb · · Score: 1

    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 95, 98, 2000 and it was crap, then went to using an old Mac Powerbook 150 and never looked back - I've always had a mac around the place, but once I started using a mac, I found it the closest thing to having a sun workstation in a laptop, without the cli ( bugger ) - I even ran Apple's "Apple UX" BSD system once, but it was heavy on old mac's, even ran the tenon stuff - same deal.

    So when Mac OS X 10.0 came out, I dropped everything and ran to the nearest ( yes, I said ran! ) shop, and got a 15 inch G4 and have never looked back. Now I can't understand why people run PC platform latop's with Linux when they can have the perfect world of a Mach kernel ( the best ), a FreeBSD core with the whole of the open source world at their feet, and everything I have ever needed that ran on Linux runs on Darwin just fine ( unless some moron has written pissy code and then they can get stuffed - I'll write it myself ).

    Convert now - dump intel, bring your linux thinking, and run Darwin on PPC and see a brighter world!

    ++dez;

    ---
    Dez Blanchfield
    dez@blanchfield.com.au
    http://WebSea rch.COM.AU

    --
    --- Dez Blanchfield http://WebSearch.COM.AU "Will work for bandwidth.."
  35. How do I get the OSX shell anyway? by shish · · Score: 1

    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?

    --
    I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
    1. Re:How do I get the OSX shell anyway? by Anonymous Coward · · Score: 0

      Applications/Utilities/Terminal.app, beeyotch!

  36. To be more precise, by Anonymous Coward · · Score: 0

    On a POSIX system, /bin/sh is required to be a POSIX-compliant shell (or, as usually happens, a symlink to one). As far as I know, no GNU/Linux distribution has actually paid to be certified as POSIX-compliant, but in order to be compatible with other Unixes, they all aim for POSIX compatibility.

    bash, ksh, and ash are POSIX shells (each supports a superset of POSIX functionality), but csh isn't; as a result, portable shell scripts starting with #!/bin/sh should never get run under csh anyway.

    In most Linux distributions /bin/sh is a symlink to /bin/bash, although there are exceptions (the Debian install floppies use ash, a smaller and less featureful POSIX shell, because bash wouldn't fit). I understand some BSDs link /bin/sh to /bin/ksh instead.

  37. tcsh-to-bash script by Gudlyf · · Score: 1
    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.

    --
    Trolls lurk everywhere. Mod them down.
  38. not very consistent by Aeonsfx · · Score: 1
    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. Whenever I run into a "bash script" I port it to bourne... immediately.

    This seems more like a popularity move than anything else the way I see it...

    --Tim