As part of the Cat Proof Computing Initiative, I want to have a shell that is extra rhobust, and will keep users safe from bad things, and becoming interactive at a certain point. I'm a bit pumped up from Linuxfest.
- I want to be safe from having files names -rf.
- I want parenthesis matching
- I want abnormal filename detection.
- colorized edit line. (all the text editors do it)
- interaction with the terminal so that an output that would display encoded characters does not leave the other applications that follow it in a strange character mode.
some of this danger could be mitigated with aliases.
some of this might require simulation.
*For the simulation*
I can conceive of situations where the action could not be simulated... say with self modifying code, or detection of the conditions like being on a different filesystem.
white listing actions could be interesting... but this isn't an easy problem to solve.
I just had a thought that I could use mount --bind to make a read only copy of my file system. I then could make a folder differences apparent by having unionfs overlay, then perform the actions and confirm that what happened was ok, then apply those changes.
I think this is a bit like having a transaction based shell... well we have transaction based filesystems, so that is likely the best way to deal with the idea... and reverting has less overhead.
*For shell and terminal interaction, I have seen terminals tell me what program is running inside it. It should be able to reset it's characters everytime the shell comes back. by paying attention to it's child processes.
3 comments:
VIM has some great colorization.
There has got to be a way to use these libraries for bash.
http://vimdoc.sourceforge.net/htmldoc/usr_06.html
http://vimdoc.sourceforge.net/htmldoc/usr_44.html
basic idea, have my own program that filters, and redirects output to vim
(it would need to filter out esc, up, down)
It would then need to pass it to a vim instance, and copy the output, including the escape codes, to the program.
This could end up being a lot of data transfered each key press, but computers should be fast enough to handle it.
It would be better to directly take those parts out of vim, and use them.
Post a Comment