If Perl is built on a system without a suitable C-shell, then the glob operator uses Bourne Shell instead, and you'll get mistakes on filenames that have spaces and newlines.

-- Randal L. Schwartz, Perl hacker

Well that explains the contortions I went through a few months ago. The stripped system didn't have C-shell now that I think back! I think I should not be as reluctant to ask questions.

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.

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

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.