|
From: Diogo K. <di...@ma...> - 2002-12-04 00:02:29
|
About modularity, I think there should be at least three modules: o A module to interface with the user (read commands, interpret them, show messages); o A module to execute the commands; o A module to control both the interface and the execution (a main module). I don't think #define'd commands are a good idea, because defines can store a very limited amount of information about the commands. One solution I like to use in my programs is to define a constant array of structures. In this case, each item of the array would have information about one command (name, syntax, arguments). If you observe most *nix systems, you'll see that most of the shell commands are implemented as external programs, and I see no reason to modify that. It would be nice, though, if we were able to abstract and standardize the command line parameters these programs use, like some sort of "translator". It would work like this: an entry in the config file like: "find: grep --recursive $(text) $(files)" Would allow us to define the find command as "find <text> <files>" or "<files> . find <text>" without breaking everything. It would also allow users to customize unishell to his/her distribution or operating system. Scripting is important too, IMO. It doesn't need to be much powerful, just if/for each/while/variables would be enough for me. -- Diogo Kollross di...@ma... -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup One click access to the Top Search Engines http://www.exactsearchbar.com/mailcom |