...perl takes less than twice the memory of bash.
I suppose it depends on the system and shell, but aren't shell processes often kept in shared memory, and so additional shell processes would take little or no additional memory? I remember reading on some man page that you usually may as well spawn another process rather than use 'exec' for this (among other) reason(s). | [reply] |
I do not know what you mean. "shared memory" is the common
term used if processes share part of their memory - to exchange
data. I've never heard of shells communicating with utilities
using shared memory - for this to work shells
and utilities need to cooperate.
I guess you mean something else, but I don't know what. It's
also unclear what you mean by "spawning" a process. I think
most people would consider "fork + exec" to be "spawning"
(assuming we're talking Unix), but since you want to do something
else than "exec", it's not a typical "fork + exec" you are
referring to.
Under UNIX, there is just one way of creating a new process,
and that's by using "fork". And there's only one way to
start a different program, and that's by using a member of
the exec family.
Abigail
| [reply] |
I think he's referring to the fact that the shell's code segment will be shared, so the OS won't have to load any new code to start a shell process. Of course, if you use Perl enough, its code should already be in memory as well...
/s
| [reply] |
Indeed a shell has no meat and must rely on many executable
like grep, cut, sed, awl, find, ls. Beside the cost of
paging them in (and out if you are really short on memory),
there is the cost of forking them.
Eventually there is the problem of portability. If you want
to restrain yourself to the set of options supported
identically
everywhere, learning this set will cost you a lot.
Better learn more of perl than to learn a subset that will
bind one of you arm behind your back.
And I forgot, even if you don't use them the features of
these various command is there, you will have to carry them
as extra luggage (bigger executable).
Except if you have to maintain existing shells, writing in
Bourne shell or bash is a total loss except if people around
you don't want to learn perl. But, in that case, this is
not a technical limitation but a social one.
If there is a question, it is to choose between perl,
python and ruby. I think with CPAN perl is still a winner
even if it shows clear signs of entropy.
By the time ruby and python will have libraries as rich as
CPAN, we will be using perl6. :)
--
stefp -- check out TeXmacs
wiki
| [reply] |
| [reply] |