Loading ...
Sorry, an error occurred while loading the content.

Re: [hackers-il] My "Stop Using (and Teaching) C-Shell and Tcsh" Page

Expand Messages
  • Nadav Har'El
    ... Good summary of CSH s problems and good links. Another reason you missed is this: if you have to learn just *one* shell, make sure you learn bourne shell,
    Message 1 of 9 , Oct 7, 2007
    • 0 Attachment
      On Sat, Oct 06, 2007, Shlomi Fish wrote about "[hackers-il] My "Stop Using (and Teaching) C-Shell and Tcsh" Page":
      > We discussed the C-shell in these mailing lists before. A few days ago I
      > decided to set up the definitive anti-C-shell page, based on an email I
      > wrote, so I did:
      >
      > http://www.shlomifish.org/open-source/anti/csh/
      >
      > Comments are welcome.

      Good summary of CSH's problems and good links.

      Another reason you missed is this: if you have to learn just *one* shell,
      make sure you learn bourne shell, not csh. Because the bourne shell is the
      "standard shell" on Unix, and it - not csh - is the one that you'll always
      be sure to find on any sort of Unix machine, and it - not csh - is the
      language you'll find when you read other people's scripts on Unix machines
      (makefiles, init scripts, rpm scripts, and so on).

      What always baffles me is why people learn or teach csh at all. With all its
      downsides, bugs and problems (whether there are 5, 10 or 50 of those), what
      exactly are its positive sides?

      --
      Nadav Har'El | Sunday, Oct 7 2007, 25 Tishri 5768
      nyh@... |-----------------------------------------
      Phone +972-523-790466, ICQ 13349191 |Cats aren't clean, they're just covered
      http://nadav.harel.org.il |with cat spit.
    • Arik Baratz
      ... It was 12 years ago when I learned csh, but from what I remember the killer feature was the c-like properties of csh, the ability to program in a way
      Message 2 of 9 , Oct 7, 2007
      • 0 Attachment
        On 10/7/07, Nadav Har'El <nyh@...> wrote:

        What always baffles me is why people learn or teach csh at all. With all its
        downsides, bugs and problems (whether there are 5, 10 or 50 of those), what
        exactly are its positive sides?

        It was 12 years ago when I learned csh, but from what I remember the "killer feature" was the c-like properties of csh, the ability to program in a way that is almost, but not entirely unlike c.

        I have to admit that as my first shell (I knew nothing of Unix when I came to the Technion and we did study csh) it looked half decent, and easy to learn if you know c. Then again, as I learned to realize that my nice scripts wouldn't really run anywhere, the charm kinda went away.

        When I worked in the Technion's computer center and had to deal with the users whining about incompatible csh/tcsh versions across the different platforms, I learned to dislike it. When that physics professor was told he would have to rewrite his rather elaborate multi-kilobyte tcsh script in another language (sh was suggested) for it to run on a particular parallel computer because the compiler there wouldn't compile tcsh... fun times.

        Today I write even the simplest scripts in Python, and use bash as my shell.

        Take care,

        -- Arik

      • Beni Cherniavsky
        ... Good page. Definitely s/tcsh/bash/g is even more obvious than s/cvs/svn/g ;-) But for those of us that find even {ba,z,k}sh unsatisfactory, I highly
        Message 3 of 9 , Oct 19, 2007
        • 0 Attachment
          On 10/6/07, Shlomi Fish <shlomif@...> wrote:
          > We discussed the C-shell in these mailing lists before. A few days ago I
          > decided to set up the definitive anti-C-shell page, based on an email I
          > wrote, so I did:
          >
          > http://www.shlomifish.org/open-source/anti/csh/
          >
          Good page. Definitely s/tcsh/bash/g is even more obvious than s/cvs/svn/g ;-)

          But for those of us that find even {ba,z,k}sh unsatisfactory, I highly
          recommend trying the Friendly Interactive SHell
          <http://fishshell.org/>. It fixes many things like quoting, innovates
          in configuration and has interactive syntax-higlighted
          multiline-editing completing-on-steroids prompt.

          I do have to warn that it is still evolving, not perfectly stable, and
          has performance problems. So you might not want it as your login
          shell yet, but it's definitely worth checking out.

          See http://fishshell.org/wiki/moin.cgi/BashToFish for some highlights
          and a quick start.


          --
          Beni Cherniavsky <cben@...> (I read email only on weekends)

          Joyce hangs up an African mask and says "It cheers up the room."
          Buffy: "It's angry at the room, Mom. It wants the room to suffer."
          -- `Dead Man's Party`, BtVS S03E02
        • Shlomi Fish
          ... My problem with FISH is that its syntax is incompatible with that of the Bourne Shell, much less with bash. As such, I recommend people not to get use it,
          Message 4 of 9 , Oct 19, 2007
          • 0 Attachment
            On Friday 19 October 2007, Beni Cherniavsky wrote:
            > On 10/6/07, Shlomi Fish <shlomif@...> wrote:
            > > We discussed the C-shell in these mailing lists before. A few days ago I
            > > decided to set up the definitive anti-C-shell page, based on an email I
            > > wrote, so I did:
            > >
            > > http://www.shlomifish.org/open-source/anti/csh/
            >
            > Good page. Definitely s/tcsh/bash/g is even more obvious than s/cvs/svn/g
            > ;-)
            >
            > But for those of us that find even {ba,z,k}sh unsatisfactory, I highly
            > recommend trying the Friendly Interactive SHell
            > <http://fishshell.org/>. It fixes many things like quoting, innovates
            > in configuration and has interactive syntax-higlighted
            > multiline-editing completing-on-steroids prompt.

            My problem with FISH is that its syntax is incompatible with that of the
            Bourne Shell, much less with bash. As such, I recommend people not to get use
            it, for fear it will become the next csh/tcsh. I'd rather improve bash or zsh
            in areas that one feels they need improvement, than create something
            incompatible.

            So stay away.

            And I daresay I don't find bash unsatisfactory. I'm probably still using a
            very small of its functionality, and it has many dark corners that I haven't
            investigated yet. I still haven't even found enough motivation to use zsh
            instead of bash.

            And I'm still finding myself using Perl for many non-trivial scripting
            problems.

            >
            > I do have to warn that it is still evolving, not perfectly stable, and
            > has performance problems. So you might not want it as your login
            > shell yet, but it's definitely worth checking out.
            >

            I'd rather see the good FISH ideas integrated into bash.

            > See http://fishshell.org/wiki/moin.cgi/BashToFish for some highlights
            > and a quick start.

            Regards,

            Shlomi Fish

            ---------------------------------------------------------------------
            Shlomi Fish shlomif@...
            Homepage: http://www.shlomifish.org/

            If it's not in my E-mail it doesn't happen. And if my E-mail is saying
            one thing, and everything else says something else - E-mail will conquer.
            -- An Israeli Linuxer
          • Beni Cherniavsky
            ... It won t become the next csh because it s not vastly inferior ;-). It just as real a language as bash, only different. Whether to use it or not is a
            Message 5 of 9 , Oct 20, 2007
            • 0 Attachment
              On 10/19/07, Shlomi Fish <shlomif@...> wrote:
              > On Friday 19 October 2007, Beni Cherniavsky wrote:
              > > But for those of us that find even {ba,z,k}sh unsatisfactory, I highly
              > > recommend trying the Friendly Interactive SHell
              > > <http://fishshell.org/>. It fixes many things like quoting, innovates
              > > in configuration and has interactive syntax-higlighted
              > > multiline-editing completing-on-steroids prompt.
              >
              > My problem with FISH is that its syntax is incompatible with that of the
              > Bourne Shell, much less with bash. As such, I recommend people not to get use
              > it, for fear it will become the next csh/tcsh. I'd rather improve bash or zsh
              > in areas that one feels they need improvement, than create something
              > incompatible.
              >
              > So stay away.
              >
              It won't become the next csh because it's not vastly inferior ;-). It
              just as real a language as bash, only different. Whether to use it or
              not is a pesonal decision, depending on whether one likes it, being an
              early adopter, etc.

              Of course, as Nadav says, if somebody is going to learn just one
              shell, the only sensible recommendation is [ba]sh.

              > And I daresay I don't find bash unsatisfactory. I'm probably still using a
              > very small of its functionality, and it has many dark corners that I haven't
              > investigated yet. I still haven't even found enough motivation to use zsh
              > instead of bash.
              >
              I find any shell following Bourne shell semantics of quoting and
              variable expansion inherently broken, because it takes too much hassle
              to write correct code. IMMV.

              > And I'm still finding myself using Perl for many non-trivial scripting
              > problems.
              >
              Obviously. Command-line glue is just not flexible enough to compete
              with real data structures and interfaces that you find in a real
              language. Also, shell scripts suffer from much higher software rot
              due to dependence on numerous external programs.

              > I'd rather see the good FISH ideas integrated into bash.
              >
              Some of them (mostly the interactive features) could, and probably
              should, be integrated.
              But the syntax improvements can't be sh-compatible, because it
              explicitly sets out fix sh syntax mistakes.

              --
              Beni Cherniavsky <cben@...> (I read email only on weekends)
            • Shlomi Fish
              ... It still may introduce bad habits when using Bash for scripts. ... Right. ... Can you give some examples for that? And if so - how is FISH better? ...
              Message 6 of 9 , Oct 21, 2007
              • 0 Attachment
                On Saturday 20 October 2007, Beni Cherniavsky wrote:
                > On 10/19/07, Shlomi Fish <shlomif@...> wrote:
                > > On Friday 19 October 2007, Beni Cherniavsky wrote:
                > > > But for those of us that find even {ba,z,k}sh unsatisfactory, I highly
                > > > recommend trying the Friendly Interactive SHell
                > > > <http://fishshell.org/>. It fixes many things like quoting, innovates
                > > > in configuration and has interactive syntax-higlighted
                > > > multiline-editing completing-on-steroids prompt.
                > >
                > > My problem with FISH is that its syntax is incompatible with that of the
                > > Bourne Shell, much less with bash. As such, I recommend people not to get
                > > use it, for fear it will become the next csh/tcsh. I'd rather improve
                > > bash or zsh in areas that one feels they need improvement, than create
                > > something incompatible.
                > >
                > > So stay away.
                >
                > It won't become the next csh because it's not vastly inferior ;-). It
                > just as real a language as bash, only different. Whether to use it or
                > not is a pesonal decision, depending on whether one likes it, being an
                > early adopter, etc.

                It still may introduce bad habits when using Bash for scripts.

                >
                > Of course, as Nadav says, if somebody is going to learn just one
                > shell, the only sensible recommendation is [ba]sh.

                Right.

                >
                > > And I daresay I don't find bash unsatisfactory. I'm probably still using
                > > a very small of its functionality, and it has many dark corners that I
                > > haven't investigated yet. I still haven't even found enough motivation to
                > > use zsh instead of bash.
                >
                > I find any shell following Bourne shell semantics of quoting and
                > variable expansion inherently broken, because it takes too much hassle
                > to write correct code. IMMV.

                Can you give some examples for that? And if so - how is FISH better?

                >
                > > And I'm still finding myself using Perl for many non-trivial scripting
                > > problems.
                >
                > Obviously. Command-line glue is just not flexible enough to compete
                > with real data structures and interfaces that you find in a real
                > language. Also, shell scripts suffer from much higher software rot
                > due to dependence on numerous external programs.

                Well, there are standards defining a subset of the behaviour of such programs.

                >
                > > I'd rather see the good FISH ideas integrated into bash.
                >
                > Some of them (mostly the interactive features) could, and probably
                > should, be integrated.
                > But the syntax improvements can't be sh-compatible, because it
                > explicitly sets out fix sh syntax mistakes.

                I see.

                Regards,

                Shlomi Fish

                ---------------------------------------------------------------------
                Shlomi Fish shlomif@...
                Homepage: http://www.shlomifish.org/

                If it's not in my E-mail it doesn't happen. And if my E-mail is saying
                one thing, and everything else says something else - E-mail will conquer.
                -- An Israeli Linuxer
              • Beni Cherniavsky
                ... You CAN do anything in sh, but it s defaults are bad, which makes you use convoluted syntax or give up and write code with bugs. Consider this fish code:
                Message 7 of 9 , Dec 22, 2007
                • 0 Attachment
                  On Oct 21, 2007 8:07 PM, Shlomi Fish <shlomif@...> wrote:
                  > On Saturday 20 October 2007, Beni Cherniavsky wrote:
                  > > I find any shell following Bourne shell semantics of quoting and
                  > > variable expansion inherently broken, because it takes too much hassle
                  > > to write correct code. IMMV.
                  >
                  > Can you give some examples for that? And if so - how is FISH better?
                  >
                  You CAN do anything in sh, but it's defaults are bad, which makes you
                  use convoluted syntax or give up and write code with bugs.

                  Consider this fish code:
                  {{{
                  set files (ls) # splits on \n, creates array
                  for f in $files # space-safe!
                  cp $f ../backup/$f~ # space-safe
                  end
                  ls -l ../backup/$files~ # space-safe, adds backup/...~ around each word!
                  }}}

                  The best equivalent POSIX sh code I can come up is much uglier (by
                  "equivalent" I mean working in the same way; there are easier ways to
                  do it but I wanted examples of specific shell constucts):
                  {{{
                  IFS=$'\n' files=($(ls))
                  for f in "${files[@]}"; do
                  cp "$f" ../backup/"$f"~
                  end
                  files2=("${files[@]/#/../backup/}")
                  ls -l "${files2[@]/%/~}"
                  }}}
                  Note especially the syntax for simple one-element-one-word expansion
                  of an array variable: {{{"${files[@]}"}}}
                  In fish you just write {{{$files}}}!

                  However, I was now pleasantly surprised that bash, when not in POSIX
                  mode, has saner defaults nowdays!
                  You can remove most of the quotes in the above code. Just {{{$*}}} or
                  {{{$@}}} now works like {{{"$@"}}}.
                  Still, the fact {{{$files}}} only gives the first element of an array,
                  so you have to write {{{${files[@]}}}} :-(.

                  Fish makes array variables the default, with scalar variables just
                  being a special case.
                  And fish's behaviour of adding prefixes and suffixes to each word
                  (treating variable expansion like brace expansion) is extremely
                  convenient.

                  There are many more small cleanups in the syntax:
                  * Minimalistic command expansion syntax: {{{(command)}}}. LISPers rejoice!
                  * Simplified loop and conditionals syntax -- no {{{then}}} or
                  {{{do}}}, single {{{end}}} kw.
                  * Simplified special chars: \n and the like recognized outside quotes.

                  In many ways fish unifies various special cases to a single generic feature.
                  * My favorite example is {{{%job}}}. In bash, some builtins such as
                  fg or kill special-case this syntax.
                  In fish, it's expanded to the pid by the shell, so it's useful in
                  any command: {{{pstree %1}}} works!
                  * This goes for user interface as well as syntax.

                  See http://fishshell.org/user_doc/design.html for more nice principles
                  behind fish.
                  The bottom line is that fish's design is compact and elegant, without
                  dirty baggage.
                  This appeals to me very much. It's very possible that my impression
                  is subjective.

                  --
                  Beni Cherniavsky <cben@...> (I read email only on weekends)
                • Nadav Har'El
                  ... Just FYI, in ZSH you can do the first 4 lines even more simply, with 2 lines. Zsh has (by default, when not run in sh compatibility mode) saner space-
                  Message 8 of 9 , Dec 22, 2007
                  • 0 Attachment
                    On Sun, Dec 23, 2007, Beni Cherniavsky wrote about "Re: [hackers-il] My "Stop Using (and Teaching) C-Shell and Tcsh" Page":
                    > You CAN do anything in sh, but it's defaults are bad, which makes you
                    > use convoluted syntax or give up and write code with bugs.
                    >
                    > Consider this fish code:
                    > {{{
                    > set files (ls) # splits on \n, creates array
                    > for f in $files # space-safe!
                    > cp $f ../backup/$f~ # space-safe
                    > end
                    > ls -l ../backup/$files~ # space-safe, adds backup/...~ around each word!
                    > }}}

                    Just FYI, in ZSH you can do the first 4 lines even more simply, with 2 lines.
                    Zsh has (by default, when not run in sh compatibility mode) "saner" space-
                    separation defaults, has syntax shortcuts (no need for do/done when there's
                    just one line), and can do more things without calling external programs:

                    for f in * # space-safe, and no need to call ls!
                    cp $f ../backup/$f~

                    The 5th line in your example is slightly more complex, and I guess the
                    bash way you found

                    > files2=("${files[@]/#/../backup/}")
                    > ls -l "${files2[@]/%/~}"

                    Is one way to do it, though in zsh, you don't need to do $files[@], you can do

                    files=(*) # space safe
                    ls -l ${files/#/../backup}

                    and so on.

                    > Still, the fact {{{$files}}} only gives the first element of an array,
                    > so you have to write {{{${files[@]}}}} :-(.

                    Strange.

                    > * Minimalistic command expansion syntax: {{{(command)}}}. LISPers rejoice!

                    Other ksh-inspired shells (including zsh and bash) already allow the $(...)
                    syntax. I don't see what removing the extra "$" really buys you.

                    > In fish, it's expanded to the pid by the shell, so it's useful in
                    > any command: {{{pstree %1}}} works!

                    Interesting. Indeed sounds logical.

                    > The bottom line is that fish's design is compact and elegant, without
                    > dirty baggage.

                    I guess I should take a look at it sometime ;-) Maybe after 15 years with
                    Zsh (before which I was mostly using ksh), it's time to consider a switch...
                    Although I'm so pleased with zsh, that Fish would need to be really great
                    to win me over.

                    --
                    Nadav Har'El | Sunday, Dec 23 2007, 14 Tevet 5768
                    nyh@... |-----------------------------------------
                    Phone +972-523-790466, ICQ 13349191 |I have a watch cat! If someone breaks in,
                    http://nadav.harel.org.il |she'll watch.
                  Your message has been successfully submitted and would be delivered to recipients shortly.