Author Topic: ssh and colored dir - difference between OpenSSH_5.3p1 and OpenSSH_8.4p1  (Read 5767 times)

Andi B.

  • Hero Member
  • *****
  • Posts: 867
  • Karma: +13/-2
    • View Profile
I connect to some Linux box via SSH. After figuring out all the keys stuff it works. But now I've updated to 'OpenSSH_8.4p1, OpenSSL 1.1.1s  1 Nov 2022' and see some problems/differences. As I'm not familiar with all these SSH and Linux stuff I want to ask here before opening a ticket.

Old version 'OpenSSH_5.3p1, OpenSSL 0.9.8k 25 Mar 2009' worked fine. I've colored dir (dir, ls -la, ls -ls, ...) but with new version 'OpenSSH_8.4p1, OpenSSL 1.1.1s  1 Nov 2022' the colors are gone. I know I've setup these colors in some conf file on the Linux box (I think) but don't remember where anymore. But there must be a difference between our two ssh versions. Cause I can connect with the old version at the same time as with the new ssh.exe version. Old has colored dir, new not. I'm using the same user of course.

I also noticed that with the old version 'nano' works while with the new version nano gives an 'Error opening terminal: os2.'.

Anyone knows what this 'terminal: os2. means? Or how to change? Or how to find out why the old version works better than the new one?

Additional info - the old ssh version was installed here in /usr/local/bin. No clue from where I got it but most probably not from the netlabs repository as it would have been in /usr/bin then.
« Last Edit: December 16, 2023, 01:58:13 pm by Andi B. »

Steven Levine

  • Newbie
  • *
  • Posts: 48
  • Karma: +10/-0
    • View Profile
Re: ssh and colored dir - difference between OpenSSH_5.3p1 and OpenSSH_8.4p1
« Reply #1 on: December 16, 2023, 05:06:02 pm »
Hi Andy,

ArcaOS sets TERM=os2 in config.sys to match what some of the ported apps expect and there is a corresponding /usr/share/terminfo/6f/os2.

What you need to do is override TERM after the ssh login.  It's been a while, but I typically used TERM=vt100 from the *ix command line after logging in.

FWIW, your old version is probably openssh-5.3p1-bin.zip from Hobbes.

Andi B.

  • Hero Member
  • *****
  • Posts: 867
  • Karma: +13/-2
    • View Profile
Re: ssh and colored dir - difference between OpenSSH_5.3p1 and OpenSSH_8.4p1
« Reply #2 on: December 17, 2023, 10:35:51 am »
Thanks Steven. I've a program object which calls 'ssh -l git nas-ab'. Luckily it's so easy on our platform to change the environment for some objects (think 'Environment' tab is an XWP object extension) I tried with term=vt100 and it sorta works.

Colored dir is working now, thanks.

But nano opens a small window (different to the older ssh) and produces a LIBC PANIC!!. Log is appended if anyone is curious. Have to check different things ....

Btw. TAB does not work either. Which is really a pain on a *nix system. TAB is working with the old OpenSSH though.
« Last Edit: December 17, 2023, 10:50:52 am by Andi B. »

Heikki Kekki

  • Newbie
  • *
  • Posts: 26
  • Karma: +1/-0
    • View Profile
Re: ssh and colored dir - difference between OpenSSH_5.3p1 and OpenSSH_8.4p1
« Reply #3 on: December 17, 2023, 12:14:36 pm »
I've used Qputty (via SSH) for a few years to sign in to Linux box. On Qputty, nano works the same as on Xubuntu's own terminal emulator.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 5029
  • Karma: +113/-1
    • View Profile
Re: ssh and colored dir - difference between OpenSSH_5.3p1 and OpenSSH_8.4p1
« Reply #4 on: December 17, 2023, 05:33:34 pm »
Could try TERM=ansi.

Steven Levine

  • Newbie
  • *
  • Posts: 48
  • Karma: +10/-0
    • View Profile
Re: ssh and colored dir - difference between OpenSSH_5.3p1 and OpenSSH_8.4p1
« Reply #5 on: December 18, 2023, 02:43:57 am »
8.4p1 is from netlabs experimental.  You need to install more debug symbols if you actually want to debug this.  You also need to update exceptq to

  http://www.warpcave.com/betas/exceptq-7.11.6-shl-2023-02-23.zip

A quick look at the somewhat limited exceptq report implies a double free:

 001BEB28  1DBE8E3D   LIBCN0    0001:000A8E3D  ifree.c#129 __um_free_maybe_lock + 269 0001:000A8BD4 (ifree.obj)


corresponds to

src\lib\malloc\ifree.c:127
  if (_UM_HDR_STATUS (hdr) == _UMS_FREE)
    {
      _um_abort ("_um_free_maybe_lock: Tried to free block twice - block=%p lock=%d\n",
                 block, lock);
      return;
    }

It's also possible the something corrupted the heap, but we won't know until someone spends some quality time with the debugger.