HOME and END keys don't work, replaced Busybox with BASH

I agree.

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.

1 Like

sorry - but this discussion leed to nothing helpful for me. And yes, I know OpenWRT is just OpenWRT - but I am really happy with it - and I am mush more happy, that it has a bash-package.

Whats wrong with it to ask for help?`

yes, but many many ppl change dash back to bash, because of compatibility :wink: - just google for it and your know what I mean.

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.

1 Like

oh man ...

at first - I was asking for BASH and not for a other shell... I know others shell are also present and working in the way the do!

the second thing is that it is my choice!

and also:

all scripts use #!/bin/sh in the header - SO THEY USE NOT BASH - only when I remove the symlink from /bin/sh to busybox.

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:

I am be 100% sure, that is no feature that need to be compiled in.

It is like someone has a problem with it`s car... U only say - use a other car

thats no solution - only when the problem car has really fatal problems where cost of repair is more than the price of a new car.

But a price we cant compare on software. there are other facts more interesting.

1 Like

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.


8.4.1 Commands For Moving

beginning-of-line (C-a)
Move to the start of the current line.

end-of-line (C-e)
Move to the end of the line.

Here's your answer -- which has nothing to do with OpenWRT, so stop whining.


I am not flaming - and yes I have looked in the Makefile, but I am not so deep inside bash coding (on C) and Makefiles and all thouse deep inside things.

And to instantly repeating that I should not use bash is not really helpful.

I googled, but didn't found this (maybe my google foo is to bad). THIS is the first really on topic helpful answer and get me a little bit closer to the solution. :+1:

I am not frustrated that I don't get a answer - I be because I get forced and hunted that I want to use bash.

"You can lead a horse to water, but you can't make them drink."

The path to your answer has been posted, yet you haven't even looked at it.

No, I have it - and look into it right now... will see if the inputrc works.

EDIT: year, your my king :slight_smile:

It works.

Is only my file/folder expansion problem left. On a other LEDE router with bash (BASH_VERSION='4.3.42(1)-release'), it is not present. So it look like it is new.

hmm... maybe the inputrc should be delivered with libreadline package - than it has something todo with OpenWRT :zipper_mouth_face:

Wait...are you saying that you never created the customization file?

Also, if you are implying that you would like OpenWrt to include this file for you...or that it's "required," then you should make a bug report:


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 replaced busybox 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.

1 Like

as I have written also above, this don't change anything for interactive shells, because all scripts are using /bin/sh (read on the header of a script - there is a #!/bin/sh).

the file inputrc is delivered on many default linux OSes - on debian/ubuntu as a seperate package readline-common - which is installed as dependency of libreadline:

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.

1 Like

No they don't:


# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

exit 0


# 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.

Be sure to fix those if you use them.

get run by /bin/sh

only this get run by system call...


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.

A workaround which worked for me on any OS and with any kind of shell til now:
Ctrl+A => HOME
Ctrl+S => END