There are two ways I can interpret this question - it would seem you either want to overwrite what was already written to the terminal with something different - which is fairly easily done - or else you want to programmatically feed the current interactive shell input.
The thing is - these questions ultimately mean two very different things. A mistake a lot of people make (one I certainly did anyway - repeatedly) is to equate the visual characters printed on the terminal screen with the input typed at the keyboard as one and the same. In truth, though, the keyboard is a much more simple thing to handle than is the output on screen - there's a lot of work going on between the two to transform the former into the latter. The printout on the terminal is a convenience - and it often lies.
If you want to feed input to the shell, then writing to the screen is probably not going to help you. You can do it of course, emitting a standard VT102+ escape sequence for moving up a terminal line could look like:
...but if you do that it won't look like much happened - and this is because the shell isn't reading that - it's writing to the same place you are. You can do:
printf '\033[A'; cat
...to actually see what it does, because
cat will prevent the shell from immediately drawing a new prompt. You can (probably) add a numeric parameter between the
[ bracket and the
A for multiple lines. You can go down with
B, left with
D, and right with
C. Saving the output of
tput as called with the
termcap sequences you can find in
man termcap to named variables is usually the way people go though - and rightly so. Terminals are funny things.
If you want to have some real fun you can try:
stty raw isig -echoctl; cat >/dev/null
xterm-compatible terminal emulator (provided
-echoctl - but if it doesn't you shouldn't need it anyway) that should basically allow you to walk all over your terminal screen with the arrow keys and type over any of the text there. But none of that matters much because you're overwriting the display - the shell doesn't care for that at all.
If you want to affect a shell you have to talk to its stdin. An interactive shell will typically not listen much to what you have to say on that front unless you tell it up-front - when you call it. Otherwise it's just going to listen to the keyboard - that's what it's for (or rather, more correctly, the keyboard is its stdin). But you do have options.
A good way to script an interactive shell's input is to delay it. For example, you can get a dummy prompt - one which will do basically nothing but accept keyboard input and echo that to
sh -niv 2>&1 >/dev/null | ...
It needn't be your
/bin/sh either - it will work fine for
bash or whatever.
bash will do all of the typical
readline stuff - even command history and
$PS1 - but it will execute
-verbosely print all input to the pipe. You can then channel it however you like - maybe over another pipe to another
bash after filtering a little.
You can do a lot of these kinds of things - but you can't go back in time. The last command is already over once your script starts. You can't change it - but you can arrange it so you can filter future commands.