Implementing Shell instead of coreutils?

[faraazahmad]

So far This project has been implementing a little bit of a typical shell ala Bash and a few Coreutils like cat, ls, and cp commands which I feel are not the job of the shell to implement.

Should shellRB drop the implementation of Coreutils and focus on shell functionality instead?

or just keep going as it is, since the project's main goal, in the beginning, was to be a fun way to explore and build things in and around the shell, using Ruby?

[faraazahmad]

@tacoda Look forward to your thoughts on this

[tacoda]

I was just thinking about this after looking into using ARGF for the cat command. Looking at the delegating function, if there is no package file for the associated command name a static value of {command} not found is returned. This immediately made me think of the PATH, and where that would lead. I do think that tightening the scope would be best. If you are interested, we could pull the coreutils out to another gem. Specifically because this project is called shellrb, I think keeping this repository focused on only the shell is ideal. I do have a quick implementation of a shell built in Ruby that you can take a look at on GitLab.

[faraazahmad]

Thats definitely a good idea and your work with shell.rb is pretty amazing! My concern is that if we rip out the coreutils, what features would we add to the shell?

[tacoda]

The shell would be pretty limited on features. A shell really is just a tty interface to the system. That said, pulling the commands into a coreutils gem would allow us to continue implementing those features in ruby independent of the shell. As it currently stands, that script uses the system binaries.