On 2010-11-15 14:14, Ethan Grammatikidis wrote:
> p9p/9base rc doesn't do job control that I know of. Are you using
> Byron's rc, or do you mean if a user subsequently runs bash job control
> won't work?
I was using p9p rc, I was thinking things like Ctrl-C didn't work
either, it's been a while since I tried it though.
> > As for bashsims, there are a few, I figured if I was going to have to
> > use sh instead of rc, I might as well go with bash.
> > - Use "$@" and the like because sh doesn't support lists like rc.
>
> Not a bashism.
>
> > - The getopt/eval/read commands may be bash-specific.
>
> Not a bashism.
I believe the syntax/flags are though e.g. `read -ep' and things like
${comma...@]}.
> > - Use the `history' command since the console doesn't have mouse
>
> Out of bash, dash, and busybox ash only bash as the history command
> itself, but I don't quite get why it's wanted. In 14 years of bash use
> I've used the command maybe 3 or 4 times, and then it was to grep for
> some complex command I should probably have typed into a text editor
> first. I can understand wanting history for interactive shells but
> busybox ash provides that, (I can't speak for dash,) it just doesn't
> provide the history builtin. I also can't see the point of history in
> the init system. ;)
>
> > support for copy-paste by default.
>
> May be a fair reason to go with bash. busybox ash lacks it, but if my
> perspective is worth anything, that hasn't annoyed me to the point of
> stopping what I'm doing when hacking on my PDA.
>
> > - Uses readline (via read -ep) for line editing.
>
> I think busybox ash supports this. I imagine any shell which supports
> editing of its own command line would support the same in read.
It's a little convoluted how history/read get used. By default,
mkinit.rc and mkinit.rc run a read-eval-print loop on /dev/console. The
`history -s' and `read -e' commands are used to store the lines you type
into a buffer so you can get back to them by pressing the up arrow.
Note that this is something most init daemons don't do, and by some
logic is a gaping security hole.
In summary, with respect to rc, all the bashisms are either bug fixes
(or me not knowing how to do something in rc) or unnecessary frills :)
