[colug-432] bash history broken

[Jon Miller]

I've used the tput method as well as the straight ascii escape
sequences. I've also ran into the same problem you've described. What
I believe you're missing the the "\" escape on the opening bracket "["
before your tput or escape sequence in your PS1.

Try the following command to take you to the section of the bash
man-page I'm referring to:
LESS="-pbegin.a.sequence.of.non-printing.characters" man bash

The shell needs to be told that the characters following "\[" are not
to be counted for characters printed to the terminal. Without you'll
get the odd overwriting behavior you're experiencing.

-- Jon Miller

On Thu, Dec 29, 2011 at 8:51 PM, Rick Hornsby <richardjhornsby at gmail.com> wrote:
>
> On Dec 28, 2011, at 17:00 , Rob Funk wrote:
>
>>> PS1='[\u@\e[0;36m\h\e[0m \W]# '
>>
>> Expanding tput commands is actually the better way to do it, since it's more
>> portable to other terminal types than putting raw terminal controls in there,
>> as well as being much more readable.
>> Either way, you should wrap all your terminal controls in \[ and \], to tell
>> bash that the characters within don't take any space.
>> So a simplified version of my prompt setting is:
>> PS1="\[`tput smso`\]\h \@\[`tput rmso`\] \w\[`tput smul`\]\[`tput rmul`\]\\$ "
>
> Odd, the IBM doc I found said \e[0;36 etc was the way to go, but if tput is more readable (and isn't the source of my problem) then I'll probably switch back to using it.
>
>
>>> I found this
>>> http://jongartman.tumblr.com/post/5049206374/term-ps1-and-bash-history,
>>> but changing the TERM from xterm to xterm-color, linux, or ansi
>>> doesn't seem to help.  I'm pretty sure it is something to do with the
>>> color handling of PS1, but I posted the rest of the output from set
>>> below just in case.
>>
>> What are you using as your actual terminal? (not the TERM variable, but the
>> terminal program itself?)
>
> xShell (yes, I know. They give us Windows laptops, and several of the key corporate sites only work in IE. I asked for a Mac and my manager shot that down.) http://www.netsarang.com/products/xsh_overview.html.  However, we've seen this with PuTTY, and mRemote as well.
>
> I tried switching xShell to use several different terminal types, but they all act the same.  The reason for wanting to color the prompt is to make it easier to differentiate when you're logged in if the system is production (red, which have change control rules) or non-production (cyan).  I'm considering dropping the color altogether and coming up with a different approach, something like surrounding the prompt with *'s instead of [ and ].  I don't like putting "PROD" or "CERT" into the prompt as strings because it is redundant, appears on every single line and just wastes screen space.
>
>> Are you setting TERM explicitly anywhere, or just letting it take the default?
>> Your problem may be with the TERM setting, but it has to match what your
>> terminal actually handles.
>
> I need to check very carefully, but I'm pretty sure the app is being allowed to set the terminal type, what I think you mean by "take the default"
>
>>> USER=root
>>
>> You're logging in as root? Yikes! You do know sudo, right?  :-)
>
> Yeah :/  Another inane corporate thing I'm trying to change since arriving here in April - and one of my very first moments where I really cringed after joining the company - every single one of the thousands of linux servers has its own local credential store - so suffice it to say in most cases there aren't local accounts.  Because things are getting out of control, I think I've got them convinced to let me try to start moving some of the servers to authenticate off the AD.  Hopefully I can figure a way to do group membership from the AD as well so that we can centrally manage who is a member of the tcadmins group - which on some servers gives them access to run sudo commands related to tomcat.
>
> The environment was never properly configured from the start to allow users to log in.  The assumption was simply made "if you need to log in, you probably have to do something as root, and creating local accounts is dumb, so everyone - here is the store containing all the root passwords - log in to the servers as root" - Please trust me, one of the first questions I asked was - okay … so how do you know who did what to the servers and how do you control what people can and cannot do?  Ah yes, the auditors would have a field day if they knew...
>
>
>
> _______________________________________________
> colug-432 mailing list
> colug-432 at colug.net
> http://lists.colug.net/mailman/listinfo/colug-432