Perhaps you shouldn't insult those responding to you. Respectfully, your statement doesn't seem to address anyone in particular.
I apologize you feel that everyone you're encountering doesn't know shells or Linux. Perhaps it's a misunderstanding of what OpenWrt is. I honestly think what you desire has to be compiled into OpenWrt. You also keep mentioning the history, you are aware that in the default install of OpenWrt, that the history is wiped at logoff, correct?
This behavior is similar to MOST router OSes (Cisco, Juniper, etc.). I've never seen the history in a router OS persist over multiple sessions as you describe anyways.
This is not a desktop or server Operating System. This is why I suggest that you confirm that the features that you desire in bash - are actually written into the OpenWrt version.
I'd look into however termcap or the equivalent is handled, as well as perhaps libreadline.
I've never tried [home] and [end], as ctrl-A and ctrl-E (or your choice of vi-esque bindings) is second nature for me.
You might also want to install sudo and create a user that has bash as their shell. It's considered best practice to not muck with root's shell. bash is quickly losing favor as the shell for core operations, with sh, dash or a similar lightweight shell, rather than hack of /bin/sh being a mode of bash. Debian and Ubuntu have already moved that way. FreeBSD never left.
Nothing wrong to ask, what is wrong is not to listen.
Tab-completion works with the default shell, @anomeome has pointed out how to build a version with most of the features you desire. It's been pointed out that others don't have the problems that you are having, yet you apparently haven't started to figure out what is wrong with your configuration.
bash is, by definition, incompatible. It's one thing to use it for day-to-day use, a completely different thing to use it for system administration. It is critical that scripts have the intended behavior when running with escalated privilege, in exactly the same way as the system would execute them. That said, there shouldn't be any "day-to-day" use of a device intended to provide security.
I (for one) 100% inderstand. Bash doesn't work for you, your title originally said you has issue with the HOME and END keys. You then described fruther that you also want command line history. I COMPLETELY UNDERSTAND THIS.
You asked if we knew what's wrong with it
Instead, we're telling you how to fix it
We also understand scripts begin with
I suggested this:
Your issue may be that you have to compile them in yourself. but you stated:
Alternatives have been provided to get most of the behavior you have asked for. Paths to try to find out why your install of bash is not behaving as you might desire have been provided. Why not stop flaming and start looking at your install and where it might be missing the information required to respond to the [end] and [home] keys? Since you're "100% sure" I take it you've looked at the package make file and the configuration of bash and all the OS hooks it needs. Or have you?
A quick check, since you have prodded one to use Google, would reveal that [end] and [home] are not documented as being bound in bash by default.
And I agree now...this doesn't require you to compile; but for it to be the "default behavior" of a user-installed package (which by logic, breaks portions of the requisite installed package), it would require work to be done by the developers. At some point, a recompile of the involved packages is necessary by someone.
If your problem is solved, please consider editing the title (by clicking the pencil icon) and appending "[SOLVED]" to the beginning.
You may also consider writing a response explaining the process (and including a link to your bug report) - to help others who may search this thread seeking to replace Busybox with Bash.
I'm not sure that the OP replacedbusybox with bash, but installed bash and then dynamically modifies their /etc/passwd file to use bash in all situations as the shell for the root user. The general process up to that last step is very straightforward.
Changing the root shell in that manner is dubious as it changes it for non-interactive shells as well. Better to have a second user for interactive tasks, or to have bash activated only on interactive shells.
It's not delivered on any of the `nix OSes I use. Like many "dot-rc" files, it is optional for overrides to the default behavior.
no, it was never needed, because it is installed automatically.
now, where I know that it need to be there, I can install it manually. But I try to make a bug-report on github packages about it, in hope it will also help others.
the directory/file expansion is not solved (I have written about on the 3 post) - and maybe it is a regression with the new bash version, because with the one before it was all ok... I try to figure it out... but maybe someone else have also an idea.
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
# This file is interpreted as shell script.
# Put your custom iptables rules here, they will
# be executed with each firewall (re-)start.
# Internal uci firewall chains are flushed and recreated on reload, so
# put custom rules into the root chains e.g. INPUT or FORWARD or into the
# special user chains, e.g. input_wan_rule or postrouting_lan_rule.
So this requires re-developing (at least verification). As I said, I understand now. It works for you; but someone would have to recmompile all of this to work by default.
But however for ME it is okay - I know about it... and at first it is my personal "firewall.user" script and next I have never seen compatibility throwback when run POSIX shell optimized script in bash... only in other direction.