6

Whenever I ssh into my arch linux box I get this error message:

setterm: terminal xterm does not support --blength

Also when executing:

$ sudo su -

Interestingly not when using

$ sudo su

I have sifted through various man pages trying to find where this terminal attribute is being set. Those included setterm and terminfo. I went even so far doing

find / -type f -iname "terminfo" -exec grep -i blength {} \;

That returned 0 results. Also looked into /etc/.bashrcand /etc/bash.basrcbut nowhere I discovered anything that invokes settermor even includes *blength* in its statement.

This issue really just is a minor nuisance but I find it highly irritating simply because I don't like seeing error messages of a system that is in the state running when queried with systemctl status --system. In addition I made sure PuTTY (using SuperPuTTY as its frontend) is not passing in any commands. I would really appreciate some pointers on this issue. Thank you very much.

Improve this question
5
  • I am getting this error every time I create a shell after upgrading from Ubuntu 14.04 to Ubuntu 16.04. I tried deleting the corresponding parts of /usr/share/bash-completion/completions/setterm, but that didn't help.
    – Andrew Wagner
    Apr 6, 2017 at 8:52
  • to help narrow down, you could try one or more of these: * disabling X11 forwarding ssh -o ForwardX11=no * rename .bash_profile * rename .bashrc
    – strobelight
    Apr 7, 2017 at 2:00
  • 1
    oh, and you could try setting your terminal settings to use a visual bell instead of an audible one. In any event setterm wants -blength, not --blength. /etc/profile and /etc/profile.d/* are also possible ways to get terminal settings entered, as well as stty.
    – strobelight
    Apr 7, 2017 at 2:20
  • @strobelight Didn't rename files for worries over messing things up but I did looked into every file thats named bash_profile but couldn't grep blength anywhere. What is the significance of disabling X11 forwarding ?
    – Sven M.
    Apr 10, 2017 at 17:43
  • "disabling X11" was simply something else to try.... one less thing for ssh to do in case it was an ssh problem.
    – strobelight
    Apr 13, 2017 at 1:49

2 Answers 2

Reset to default
5

Oh dear after long last I found it thanks to one of the comments of strobelight pointing out that possible candidates for the setting to look into are in /etc/profile.d/

[..] /etc/profile and /etc/profile.d/* are also possible ways to get terminal settings entered [..]

I then promptly did just that with grep -e "blength" /etc/profile.d/*. The output of which was:

disable-beep.sh:setterm -blength 0

So I first commented it out, logged out, back in again and the error was gone.

I then looked at the command a second time since it didn't have double dashes -- but just a single one.

So I assumed since commenting out the line fixes the error¹, the command setterm expects key value pairs and handles the dashes itself or insert another implementation detail but in any case I have to provide the command as such:

setterm blength 0

Said, done, saved, relogged and the error is still gone and the bell most likely stays silent. Again wouldn't have found this without strobelight`s comment.

¹ but probably enables the bell again, which I couldn't tell since I am RDP'd into the machine thats running the ssh session w/o forwarding sounds - why the additional layer you might ask, to which I answer corporate notebook w/o rights to do shit, which yes is stupid considering my job

Improve this answer
3
  • glad I helped point the way! So many flavors of linux and not all have the same scripts.
    – strobelight
    Apr 13, 2017 at 1:51
  • It's interesting that you used blength instead of -blength or --blength and it fixed your problem. Where/how can I find documentation about that behavior? I have been searching and couldn't find. Thanks to this I also solved similar message, by replacing setterm -blank 0 with setterm blank 0 in .bashrc file.
    – mikl
    Sep 26, 2020 at 6:34
  • @mikl, setterm simply ignores that incorrect input. So it's effectively means a no-op.
    – 0andriy
    Jan 4, 2021 at 19:54
0

I had the same issue. Turns out to be setting in my own .bashrc. After commenting out the line:

setterm -blength 0

I am not getting the error message any more.

Improve this answer
3
  • That's the funny thing. I do also faintly remember setting that value myself way in the past at some point. I logged on as root and did find / -type f -name "*ashr*" -exec grep -e "blength" {} \; but didn't come up with anything. Not sure what other files might be candidates to look in. Any ideas?
    – Sven M.
    Apr 10, 2017 at 17:35
  • well, you could try '*ashr*' since "*ashr*" would expand to every file in the current directory containing an "ashr" instead of what you really wanted which is to find all files with containing "ashr". Basically you don't want the asterisk to expand so it needs to be in single quotes.
    – strobelight
    Apr 13, 2017 at 1:53
  • @strobelight Probably should look into command expansion for this but I still don't get how those two commands differ. I feel even your explanation basically says both commands are equivalent. Would appreciate if you could elaborate or just provide a few links to this topic. Sorry for being so daft. ;)
    – Sven M.
    Apr 16, 2017 at 13:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .