RESUBMIT: PATCH: line_edit, ps, inotify features

[Denys Vlasenko]

On Thu, Sep 8, 2011 at 9:25 AM, Flemming Madsen <busybox at themadsens.dk> wrote:
>> Standard practice is to send one change per patch.
>> Please split it up and send individual patches,
>> one per email, with the rationale why each is useful.
>> While at it, check patches for stray training whitespace.
>
> Sure. Should they be on top of each other, or all against pristine sources?

If patches are unrelated, then it doesn't matter.
If they are related, send the least controversial first, and
base the rest on it.


>>>> 3. procps.c: An 'l' option to ps without enabling full desktop option
>>>>  FEATURE_PS_LONG: Adds fields PPID, RSS, START, TIME & TTY
>>
>> This option is not in POSIX, and can easily be emulated by
>> suitable -o FIELD1,FIELD2... option.
>> ps has gazillions of options, all different in every Unix,
>> is it realistic to add all of them?
>> Why do you need -l?
>
> The -o option requires a desktop busybox build.
> I often find myself needing the start and CPU time of a process.
> Parent PID and TTY are also nice info. RSS gives a better hint at
> memory usage than VSZ
> I dont need every combination, but honestly thinks that the above are
> useful, and would be to others as well.

Well, I have no doubt that -l is useful. My point is: ps has a misfortune
of having the least standardized set of options across Unix implementations,
and standard committees had a hell of a time trying to discern some
commonality.

Hmm... let's see

The Open Group Base Specifications Issue 7:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ps.html

My understanding is that only -a, -A, -o, -p and -t
are considered to be a mandatory standard across entire gamut.

But -l *is* listed there, as XSI extension. So probably -l is fine.


>>>> 4. lineedit.c ash.c: Consider aliases and ash builtins in command
>>>>   completion
>>
>> This needs an explanation why it needs to be added.
>
> Completion of first word on the command line:
> Because they are legitimate candidates as to what command the user
> wants to invoke, yet are not considered in the current completion
> scheme. Especially not seeing the aliases are annoying.

Ok, I see your point.


>>>> 5. lineedit.c ash.c: Help on lineedit keycodes.
>>>>   FEATURE_EDITING_HELP: "Help on line editing (in ash help command)"
>>
>> Why do you think it's useful? bash doesn't do it.
>
> Mostly because bash has a man page and the 'bind -p' command. Busybox
> users has to peruse the raw source code to get at the same
> information. Also I find it darn convenient.

Ok.


>>>> 6. lineedit.c: Support for some of the the above keycodes
>>>>   FEATURE_EDITING_EXT: "Additional Meta key line editing commands"
>>>>   Enable M-b M-f M-w M-d M-w M-n M-p and M-. M-_ editing commands
>>>>
>
>>>>   a) Completion menu for browsing completion matches with S-Tab/Tab
> Bash equivalent:
>       menu-complete
>              Similar to complete, but replaces the word to be
> completed with a single match from  the
>              list  of  possible  completions.   Repeated execution of
> menu-complete steps through the
>              list of possible completions, inserting each match in
> turn.  At the end of the  list  of
>              completions,  the  bell  is rung (subject to the setting
> of bell-style) and the original
>              text is restored.  An argument of n moves n positions
> forward in the list of matches;  a
>              negative  argument  may  be  used  to  move  backward
> through the list.  This command is
>              intended to be bound to TAB, but is unbound by default.
>       menu-complete-backward
>              Identical to menu-complete, but moves backward through
> the list of possible completions,
>              as  if  menu-complete  had  been  given a negative
> argument.  This command is unbound by
>              default.
>
> I find this quite convenient as is save me from a lot of cop-paste
> work with the mouse

Ok.


>>>>   b) Find commands matching prefix before cursor with M-p M-n
> Bash equivalent:
>       history-search-forward
>              Search forward through the history for the string of
> characters between the start of the
>              current  line  and  the  current cursor position (the
> point).  This is a non-incremental
>              search.
>       history-search-backward
>              Search backward through the history for the string of
> characters between  the  start  of
>              the current line and the point.  This is a non-incremental search.
>
> I find these easier to use than C-R incremental search (which I
> profoundly hate), but this is a matter of taste.
>
>
>>>>   c) Insert last word of previous (repeated) command with M-. or M-_
> Bash equivalent:
>       yank-last-arg (M-., M-_)
>              Insert  the last argument to the previous command (the
> last word of the previous history
>              entry).  With a numeric argument, behave exactly like
> yank-nth-arg.  Successive calls to
>              yank-last-arg  move  back through the history list,
> inserting the last word (or the word
>              specified by the argument to the first call) of each
> line in turn.  Any numeric argument
>              supplied to these successive calls determines the
> direction to move through the history.
>              A negative argument switches the direction through the
> history (back or  forward).   The
>              history  expansion facilities are used to extract the
> last argument, as if the "!$" his‐
>              tory expansion had been specified.
>
> Very convenient, once you know it.
>
>>>>   d) Word/identifier deletion and movement aliases M-w M-b M-f
> Bash equivalent:
>       kill-word (M-d)
>              Kill from point the end of the current word, or if
> between words, to the end of the next
>              word.  Word boundaries are the same as those used by forward-word.
>       backward-kill-word (M-Rubout)
>              Kill the word behind point.  Word boundaries  are  the
> same  as  those  used  by  back‐
>              ward-word.
>
>
>>>>   e) Redraw line with C-X (And C-R if inremental search is disabled)
> Bash equivalent:
>       redraw-current-line
>              Refresh the current line.
>
> Useful when a log tail is running in the background, and you dont want
> to redraw the whole screen.
>
>>
>> These don't look like terribly useful, or used, features.
>
> I beg to differ sir :-) These are exactlyv why I started hacking the source ..
>
>> Are they bash-compatible?
>
> See above

Ok, but be sure to use the same keys as standard installation of bash uses.

-- 
vda