Remote debugging only works for certain hosts

1

I just bought BashSupport Pro on the weekend and I am a total bash noob.

I use Fedora 37 on my development client VM (where IntelliJ is running), and I also have a development server VM with the same OS and identical configuration. Remote debugging works perfectly for this VM.

However, when I try to remote debug my script on a different server, one running Oracle Linux 9, it does not work well. It copies the files over and starts executing the script. But after every line that the script echos, it prints this:

** Internal debug error _Dbg_is_file(): file argument null
** Internal debug error _Dbg_is_file(): file argument null
** Internal debug error _Dbg_is_file(): file argument null
** Internal debug error _Dbg_is_file(): file argument null
** Internal debug error _Dbg_is_file(): file argument null

The script might be able to continue in this fashion, but it stops. It’s not a BashSupport Pro problem that it stops, there’s an environment variable I need to set on the server in order for it to continue. But the above error messages are making it very difficult to track what the script is doing.

Maybe this is a no-brainer for bash experts but as I said I’m not one. Any ideas on how I solve this?

client $ bash–version
GNU bash, version 5.2.15(1)-release (x86_64-redhat-linux-gnu)

server $ bash --version
GNU bash, version 5.1.8(1)-release (x86_64-redhat-linux-gnu)

2

Maybe it’s an SELinux problem … I went on the server and ran the command IntelliJ says it is running. I don’t get these errors on my dev server, but I do get them on the Oracle Linux server.

bash /home/weblogic/bash-support-pro/peCKtgjnzD/bashdb --quiet --no-highlight --library /home/weblogic/bash-support-pro/peCKtgjnzD/share/bashdb /home/weblogic/bash-support-pro/ZFW4PBdR9i/my-script-name.bash
/home/weblogic/bash-support-pro/peCKtgjnzD/share/bashdb/lib/msg.sh: line 91: /dev/pts/0: Permission denied
/home/weblogic/bash-support-pro/peCKtgjnzD/share/bashdb/lib/msg.sh: line 91: /dev/pts/0: Permission denied
/home/weblogic/bash-support-pro/peCKtgjnzD/share/bashdb/lib/msg.sh: line 91: /dev/pts/0: Permission denied
/home/weblogic/bash-support-pro/peCKtgjnzD/share/bashdb/lib/msg.sh: line 91: /dev/pts/0: Permission denied

3

sudo setenforce permissive made those errors go away when I manually run bashdb, but didn’t fix remote debugging.

4

It seems this isn’t a BashSupport Pro issue. If I run bashdb on the server and type continue, it prints those same error messages. And actually it’s only a specific part of the script that prints those messages:

  # make sure we have what we need
  # bash is redundant but here we all are
  for x in bash diff find grep java sed unzip; do
    which $x || exit 1
  done

The which line is what is printing those messages. If I change it to /usr/bin/which it works fine. Weird.

5

Hm, a difference in which seems odd. But perhaps there’s another which in your $PATH, which is not at /usr/bin/which. In general, which bash should behave the same way as the command in your snippet above, when it’s executed from within bashdb.

As an alternative, you might want to try Bash’s built-in command command -v which to find out where it’s located and command -v $x as a replacement for your call to which in your snippet.

6

They are slightly different as it turns out. On the server, where it’s printing those errors, eval is used to yield the declare -f that is immediate on the client, where it works.

client $ type which
which is aliased to `(alias; declare -f) | /usr/bin/which --tty-only --read-alias --read-functions --show-tilde --show-dot'

server $ type which
which is a function
which () 
{ 
    ( alias;
    eval ${which_declare} ) | /usr/bin/which --tty-only --read-alias --read-functions --show-tilde --show-dot $@
}
server $ echo ${which_declare}
declare -f

Thanks for suggesting command. fish also has a command builtin, it didn’t occur to me bash would have it also.