RFEs for input driver line editing.
Submitted by Stephen Crawley on Sat, 03/28/2009 - 01:51.
| Project: | JNode Shell |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
(As reported by Peter in another issue)
I'm not sure if it is described or discussed anywhere yet, but on my box I'm very used Ctrl+key commands. To name some I personally use: a (home), e (end), k (cut til eol), y (paste), r (reverse history search). All of them print strange characters in JNode. pageup/pagedown does not do anything, in my box it uses the string before the cursor position and reverse searches the history for a command starting like the string.
Another strange behaviour is on an empty prompt: If you press the key-down button you go into the history from the beginning. I'm not sure if it's a feature or a bug, but I was confused the first times it happend as I didn't expect it.
(Mine)
I find the way that JNode history entries are managed to be unhelpful. JNode won't add an entry if the line is the same as the last line. Also, if the line has been entered previously, it moves it down to the end of the history. The net result is that the "history" doesn't actually reflect history, and is harder to use than a typical UNIX shell's history.
- Login to post comments
#1
This seems like a shell issue to me, rather than part of the core; that said I agree these seemed like odd things to me as well. Another case is ESC doesn't clear the command line but rather tries to offer help.
*if* a shell is going to mimic sh, bash, ms-dos, etc. I recommend either pick a common known shell and clone it, so the desired behavior is already defined, or create a new one and don't worry about trying to match the way every other shell works. the point is pick a goal, some people will want to add the features they'd like to see, others want the features they're used to seeing and those are two different projects, or a single project with huge goals.
The key is not making it work as we like, or in a cool new way, but rather document as much of the design as possible so people can figure it out. One example is the help command, offers info about the params of a command, but doesn't say what it does.
FYI I think all this should exist in user space not in system/kernel space.
#2
Your opinions about the architecture have been noted, but I don't intend to do anything about it. Pragmatically, the current architecture is good enough for now, and I don't think it is worth spending >>my<< time changing it now.
The current behavior of the command history (and line editing) is a carry over from the old (quick and dirty) command shell implementation. A lot of people, including me, don't like the choice of bindings or the behavior of some of them; e.g. history. And there are problems with the way that control chars and non-ascii chars are displayed by the console drivers. And probably other things too. But I'm working on something else right now.
Re your "advice" about designing shells: if you look carefully, especially over time, you will see that I am trying to make the JNode command line work like Linux + sh / bash. But I cannot fix everything at once.
As always, your help (specifically coding effort) will be valued much more highly than your criticism.
#3
People who don't value criticism are letting their emotions get the better of them. Criticism and praise should both be valued. All I'm saying is plan out a good design then build it; As large as this project is we'll be in big trouble, and in some cases already are, trying to redesign classes that were not well planned.
A perfect example of this is the Java API itself, look how much is depreciated or broke because they just "made it work" rather than spending more time planning for the future.
And if your time is so important to you, I'd figure you'd like to make better use of it, rather than following a coarse of action just because it's already been started. Re-read my last post and you'll realize I'm trying to reduce the amount of work, not increase your workload.
#4
The Java API itself is also a good example why planning does not always help
I suppose they did quite some planning, at least they have much more man power than we have for planning. And still they "failed" 
We already had some people trying to make a good design document about JNode (just describing the current design) and failed. I know much of JNode, but I'm far from a point knowing everything of JNode. Or deciding if one or the other API/idea is better. And I think I may say that this applies for all of us.
Anyway, I think the idea of bjourne shell is clear: Make it bash compatible. This is also why I reported these "issues" to Steve in the first place. So I think your suggestion is already an existing goal and with that we also already have existing docs (bash docs
). And as Steve is doing good work on documenting everything he's doing, you can easly follow his state of completeness in his bjourne issue. Which gets updated quite frequently btw.
I second your thought about moving this issue to the shell project. Steve please revert if you disagree.
#5
GriffenJBS: I've got better things to do than respond to your criticisms. Find someone else to annoy.
#6
Peter: I reverted to Core by accident because your response went in while I was composing mine.
The reason I made this a Core issue in the first place is that that is where the code that implements line editing actually lives. But if you think the issue needs to be in Shell, so be it.