Re: [dev] s - suckless shell

From: Wolfgang Corcoran-Mathe <wcm_AT_sigwinch.xyz>
Date: Sun, 14 Aug 2016 01:19:32 -0400

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

This archive was generated by hypermail 2.3.0 : Sun Aug 14 2016 - 07:24:14 CEST