Dev1 Galaxy Forum / Questions on environment checks in Bash script

Re: Questions on environment checks in Bash script

dummy@example.com (msi) — Tue, 27 Mar 2018 21:47:22 +0000

The script has already seen a good deal of changes since my initial post, mainly because I found out I was making some structural mistakes. I'll try to get it into a presentable shape as soon as possible, put it on GitHub and post a link on this forum.

xunilog wrote:

Nested checks or not, I expect it would need "special case" exceptions handling. For instance, conky "use_own_window=true" would need to be recognized, and handled (whitelisted)...

Because you don't want to be warned about that conky window, right? A list of programs to ignore can be provided through command line parameters.

xunilog wrote:

and, can I really hang my hat on, and trust, who a given window is "owned by"? What about text editor instance(s) launched as sudo to edit config files?

They will be handled like any other remaining window.

xunilog wrote:

What about any long-running windowless processes I may have running (as me, or as sudo) that I've forgotten about?

Can you give an example? I know that xmobar, which I use for system monitoring, is not recognized as a window by wmctrl. But that's the way I'd want it anyway.

xunilog wrote:

I hear ya about "oops, dangit!", but I would skip the prone-to-failure guessing/checking and just wire an unconditionally triggered yad or xdialog prompt inline with the desktop session exit script.

Openbox actually has that. It asks for confirmation before it exits (unless you run openbox --exit directly). My issue with that is: If there are no remaining open windows (of possible interest), I don't want to be asked for confirmation. However, if there are, I want to be warned about that. In my experience, that really makes a difference.

Re: Questions on environment checks in Bash script

dummy@example.com (xunilog) — Tue, 27 Mar 2018 19:44:12 +0000

Nested checks or not, I expect it would need "special case" exceptions handling. For instance, conky "use_own_window=true" would need to be recognized, and handled (whitelisted)... and, can I really hang my hat on, and trust, who a given window is "owned by"? What about text editor instance(s) launched as sudo to edit config files? What about any long-running windowless processes I may have running (as me, or as sudo) that I've forgotten about? I hear ya about "oops, dangit!", but I would skip the prone-to-failure guessing/checking and just wire an unconditionally triggered yad or xdialog prompt inline with the desktop session exit script.

Questions on environment checks in Bash script

dummy@example.com (msi) — Sun, 25 Mar 2018 03:16:10 +0000

I'm working on a Bash script that will display a warning dialog in case the user tries to exit the window manager when there are remaining open windows. The reason I'm doing this is that I use Openbox stand-alone without any task bar and it has happened to me time and again that I, e.g., lost notes from text editor windows that I had minimized or moved to another workspace at some point and then forgotten about.

Because I want this to be a sane script, I've created a function that performs some environment checks after the command line parameters have been processed and before any of the main script is being executed.

Currently, that function looks like this:

# Perfom environment checks

function f_check_env {  

# Check if wmctrl can be found (and executed)

  if [ ! -x "$(type -p wmctrl)" ]
  then
    return 1  # Leave function with error code 1: wmctrl not found
  fi

# Check if given window manager is supported

  local wm_supported=0

  for item in "${wm_list[@]}"
  do
    if [ "$item" = "$wm" ]
    then
      wm_supported=1
      break
    fi
  done

  if [ "$wm_supported" != 1 ]
  then
    return 2  # Leave function with error code 2: $wm is not supported
  fi

# Check if given window manager can be found on the system (and executed)

  if [ ! -x "$(type -p "$wm")" ]
  then
    return 3  # Leave function with error code 3: $wm not found
  fi

# Check if given window manager is currently being run by the current user

  if [ ! "$(ps -u "$(whoami)" | grep "$wm")" ]
  then
    return 4  # Leave function with error code 4: $wm is not currently
              # being run by the user executing this script
  fi
}

A bit of explanation: wmctrl is a tool that can be used to query and control EWMH/NetWM compatible window managers. I use it to get a list of existing windows at a later point in the script. wm_list is an array containing a list of all the window managers that the script can work with.

Now, I have two questions about this function:

1. Wouldn't it be better to nest all the checks performed there instead of having them as independent blocks? One advantage of nesting I can think of is that it would enable me to put ~~else return 0; fi at the end of the function~~ return 0 into the innermost else statement, which would then be executed if no error condition is met.

2. Is there anything wrong with how I'm using error codes? The function's return value will be dealt with in a case statement later, containing the messages corresponding to the error codes.