Re: [dev] s - suckless shell
On 2016-08-13 12:31, Connor Lane Smith wrote:
> Is there no support for 'splatting' a string into several strings? rc
> has a coherent approach to this, in that each variable is not a string
> but a list of strings. 'Splat' should be supported, but only when done
> explicitly.
Yeah I believe rc is the shell that does this right. I did not want to
add array data structures to mine (at least this early) as it would be a
large undertaking. I don't have a good solution for splatting at the
moment but it's something I'll think about more.
> But I think functions and aliases (which I take it are also missing)
> are the greater evil, since they are not first-class: `xargs ll` will
> not work if `ll` is a function or an alias. If such things are to
> exist, they must also be able to be found in $PATH, some way or
> another. They are a real wart on shell languages.
Agreed! I shall make this an explicit anti-goal. I think that listing
the feature to be avoid is as important as those desired.
> IO redirection being done by separate programs, though, seems like a
> wrong decision. Streaming the data through a separate process is
> considerably less efficient than just setting a file descriptor to an
> open file, and not always equivalent in behaviour either. For example,
> `tty < $TTY` is obviously very different to `cat $TTY | tty`. In my
> opinion this is a bug in your design, and needs to be fixed.
This tty manipulation is actually unknown to me, I'm very grateful that
you pointed this flaw out though! I'll implement your solution of
multi-arg redirection operations.
The efficiency point was very interesting too. I did implement
redirection in the shell in a previous commit, but I took it out as it
made parser more complex. I don't have anything against redir ops being
part of the shell language but I just wanted to try it out as a separate
process.
> I think what's particularly useful about a very
> slimline shell like this is that we could potentially use it to try
> out new features that aren't in traditional shells, rather than
> assuming that those shells got it right.
That's very nice to read! I tried to make the code as easy to dip into
to and as hackable as possible - everybody is of course welcome to use
it for experiments.
> I do agree though that 's' is a bit of an unfortunate name, and rc is
> not as bloated as you made it out to be. But I hardly think that rc is
> the be-all and end-all of shells.
Oh sure! I don't actually think rc is bloated and to rename is trivial.
I was just joking around with Mattias because he said he did not even
read my post :)
> Thanks,
> cls
Thank you very much for pointing out the flaws and the in depth comments
on the shell, it is much appreciated!
Received on Sat Aug 13 2016 - 17:14:43 CEST
This archive was generated by hypermail 2.3.0
: Sat Aug 13 2016 - 17:24:11 CEST