Korn Shell vs. Perl

A

A. Fuentes

Fellow Perl Netters:

At the level of the internals, IN GENERAL terms, what is the difference
in how Perl operates compared with the Korn shell?
From the Operating System view, do they operate similarly, or
entirely different?

Any Opinions/Info about this issue will be greatly appreciated.

Best,

A. Fuentes
System Admin
 
T

Tassilo v. Parseval

Also sprach A. Fuentes:
Fellow Perl Netters:

At the level of the internals, IN GENERAL terms, what is the difference
in how Perl operates compared with the Korn shell?
From the Operating System view, do they operate similarly, or
entirely different?

That's an odd question. It's like asking in which way MySQL differs
from, say, WindowMaker implementation-wise. They don't have much in
common:

The Korn shell is, as its name suggests, a shell whereas Perl is a
programming language. Similarity between those two is probably that both
are written in C. A shell is primarily made to be interactive. You have
something where to type your commands in, the shells processes this
input and produces some sort of output. Even shell scripts aren't much
different: they are considered to be a sequence of commands as if they
were given interactively.

Perl however, like most other languages, is not interactive. What it
receives is a large string that is checked and parsed against a
context-free grammar. If the string was a valid Perl program, a tree of
operators (called OPs) can be created from it. On execution perl walks
through this optree and executes each OP accordingly.

If you compared how a shell script is processed on the internals as
opposed to a Perl script, you might indeed find some similarites. Shells
often use context-free grammars as well to validate and process their
input. I am not sure about the Korn shell, but at least the bash has a
yacc/bison grammar included. So has Perl.

The main difference is that shells seldom provide a tight interaction
with the operating system. If you wanted to do something that involves
creating sockets, reading/writing from/to them etc. you'd use an
external program for it, like wget for downloading a remote file. A
shell then spawns off a new process for that. In its most basic form a
shell just needs a very limited grammar and some means to create
processes. To be more powerful they provide some ways to have different
processes interact with each other by using pipes for example.
Therefore, a typical shell command is

find /usr/include -name \*.h | xargs grep -l ^#define | sort > output.txt

In programming languages such as Perl the above could be done
differently. When you fetch a remote file, you could directly open a
socket and do all the low-level communication yourself. If you wanted to
mimic a find like the above, you could be using File::Find, open each
file, apply a regular expression to each line, collect matching
filenames in an array, sort this array, open a file output.txt and write
the sorted array into this file.

The implication this has for the internals of a shell and a programming
language should be obvious.

Btw, have you considered looking at the respective sources?

Tassilo
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top