in reply to Why a C shell?

Perl used to fire off a csh or tcsh when trying to <kbd>glob()</kbd> on some systems but nowadays it calls File::Glob::glob() instead. Yes, oddly a module now serves the purpose of providing a perl core function, at least on Unix like OSes that is what happens (MacOS and VMS have their own unique glob implementations that are distinct).

Oddly the File::Glob code contains some readdir() code that was written by Guido van Rossum and placed under the BSD license. Why folks seem to insist that there is no cooperation between Python developers and Perl developers is actually counter indicated by the content of the perl source tar ball.

Which CLI is fired off by calling system() is actually dependent on your C run time library. For example, on VMS calling system() from C (or from Perl) will execute your default login CLI, which is usually DCL and not a Bourne like shell. Similar comments hold for using backticks on Mac OS: some commands are actually parsed and handed off to the MPW Toolserver since the MPW shell does not really provide support for a C RTL implementation of system(). On most Unixes system() will run with the deafult CLI, the one that the root account uses, etc. It happens to be sh (or bsh on AIX) for hysterical raisons.

Replies are listed 'Best First'.
Re: Re: Why a C shell?
by merlyn (Sage) on May 23, 2001 at 18:56 UTC
    On most Unixes system() will run with the deafult CLI, the one that the root account uses, etc. It happens to be sh (or bsh on AIX) for hysterical raisons.
    Uh, not in my recollection. It's hardwired to /bin/sh, and has nothing to do with what root has selected for a login shell.

    Imagine the hysteria that would result the day root selected /bin/tcsh as their login shell!

    Besides, the Bourne shell has a much more complete and clean syntax, especially for things like file-descriptor shuffling and control structures. The C-shell is hackish along those lines. There's a great paper on "CSH Programming Considered Harmful" out there that explains the problems. So it's a Good Thing that /bin/sh is used for system(3).

    -- Randal L. Schwartz, Perl hacker

[reply]

      Yes the default is /bin/sh not csh nor tcsh. One can rewrite your libc's implementation of the system() function to call another shell if you'd like but it rarely gets invoked as a login shell. Most system() implementations hard wire to <kbd>/bin/sh -c</kbd> or the equivalent for your system (e.g. Linux has a symlink named /bin/sh that points to /bin/bash).

      Historically sh was the first shell (circa 1972) and there was no csh (much less a tcsh) until Bill Joy and the BSD gang decided that they wanted a shell with a syntax closer to the C programming language syntax. By most any measure they failed miserably (among other things {t}csh script do not use a semi-colon as a statement terminator nor as statement separator). csh implementations vary quite widely between vendors - since Bill's csh source was never opened various line length limits were allowed to creep into various csh flavors. That csh could not even support shell functions meant that it was nowhere near C's usefulness.

      By "default CLI" I think that the previous poster meant /bin/sh, and was not referring to the shell entry in /etc/passwd for any user.

[reply]
        Linux has a symlink named /bin/sh that points to /bin/bash

        It's worth pointing out that the shell will behave differently depending on whether it is called as sh or bash, so the fact that /bin/sh and /bin/bash are the same file does not mean they behave the same when they are executed, they share a lot of code (both being bourne shells) which is why they were made into the same file but bash enhancements won't work from /bin/sh.
[reply]

In Section Seekers of Perl Wisdom