Hi Ben,
Quoth Ben Woolley:
>> We could simplify grep(1) by
>> pulling out regular expressions, or sed(1) by having it handle only
>> s/// commands. But in each case there would be a new, less general
>> tool to learn whose only reason for existence is a lower line count.
>
>Those tools are already minimal, and actually the patch command can
>be thought of as a minimal sed. The support of sed for such uses is
>actually being dropped from projects because it is too dangerous. So
>that is a bad example.
sed is a useful general-purpose tool. My point was that limiting it
to a single command in the name of simplicity would destroy its
general usefulness. But I’m not sure I understand your point. Do you
mean that general tools like sed should be replaced by specialized
programs, and that such general tools are “dangerous”?
>> You might complain about the bloat of sh,
>> but I doubt that a shell language stripped of excess could be much
>> simpler than rc(1) without sacrificing most of what makes shells
>> useful.
>
>We now have very good automation tools that are not shells, like Python
>and Lua, so wouldn't it make sense to take a second look at shells that
>are more specific to command interpretation?
You are free to use Python and Lua, of course, but that is not a good
reason to cripple the shell.
Since this discussion included the argument that 10K lines is too much
for a shell, I also don’t understand it sucks less to use these (much
bigger) languages instead of a well-designed shell language. If you
want to restrict your shell programs to imperative command execution
with a few pipes, the simplest and most secure method would be to do
it in C.
Regards,
--
wcm
Received on Sun Aug 14 2016 - 07:19:32 CEST