Shell Programming and Scripting

Code:

#!/bin/sh
( sleep 1
  while pgrep chrome
    do  xdotool search --name Chrome 2>/dev/null | 
        while read id
           do xdotool set_window --name "Chrome" $id
           done
        sleep 1
    done
 ) &
google-chrome-stable

This indeed terminates the script upon exiting google-chrome-stable!

Code:

pgrep google-chrome-stable

did not find the chrome browser, but

Code:

pgrep chrome

did.

Initially, exiting google-chrome-stable left the one instance of the script still running until--because you folks had taught me a certain awareness--I realized that because the script was named "chrome," matters were confused. Renaming the script to something other than "chrome" shut it down entirely after exiting google-chrome-stable.

I should've never used the word "chrome" in the script's name to begin with; I wonder how many other issues I created because of the misleading name.

In fact, because of the poor title, I wonder if bakunin's original suggestion:

Code:

kill -15 %1

would've worked from the onset. I'll have to see.

Code:

ps -fe | grep [s]leep

I was not familiar with that particular use of grep. That would've headed off some earlier problems, I imagine.

Since you all have been so patient/helpful with such a seemingly arcane script, this is the overarching issue:

xubuntu_panel_embedded_in_mate_18.3_window_title_bar - Album on Imgur

That's the screen of a 7" GPD Pocket running Mate 18.3 but with a Xubuntu panel, since it was the only panel I found that can be both transparent and run directly on the window title bar. Joining the panel with the window title bar saves screen real estate, but a text-filled title covers the print-outs of the panel's genmons. So there was a big need to shorten the title, and I've modified the retitling script for the windows of Thunderbird and Links2 as well.

I have a beloved umpc MBook M1, with a 4.8" screen and without these scripts, it's just gibberish across the window title.

bakunin, I don't know why Chrome/Firefox are finicky about multiple instances. Links2 is mingy too--and it doesn't even have tabs, but it is screamingly fast, completely junk-free, and is lightweight enough to run on a abacus. I use it whenever I can for peaceful, unobtrusive browsing, especially news sites.

Once again, thank you both for your help.

It is time to correct a few of my not-so-precise statements above. Suffice it to say i learned something new myself yesterday. Many thanks to RudiC who pointed out my misconception to me.

A small explanation first of what is only a little trick: ps -fe shows all processes and if i would filter that through grep sleep it would end up finding itself (most times - it is a race condition). To avoid that (and a second grep like the often seen:

Code:

ps -fe | grep something | grep -v grep

at the same time) i use [s]leep as a regular expression here. This will also search for "sleep" but since the regexp looks different to the string searched for it will not find itself, thus saving the second grep.

Now to something else, since i explained something not quite adequate and as a beginner you should learn it the right way, not the wrong way. When i talked about "process substitution" and "command substitution" above my wording was not quite accurate. Here is the truth:

The construct ( ... ) basically opens up a "subshell": it starts a shell and runs the commands inside the braces like a separate (unnamed) script in that shell. Afterwards this shell is closed and normal operation resumes. Note that this has the side effect of removing changes in variables you did inside the subshell:

Code:

var="abc"
( var="XYZ"
  command1
  command2
)
echo $var

will result in "abc", not "XYZ". Many of the following concepts will be based on such a subshell.

Let us get to "process substitution". A process substitution happens if you use the subshell mechanism to redirect input to or output from such a subshell. In case of redirecting the output it this will offer the ability to "string together" output of differing commands.

Example: you have two files and you want to search in one for one thing and for something else in the other but you want to process the results the same way. Like this:

Code:

( grep "something" file1 ; grep "otherthing" file2 )> ....

Here is a more complex example from the ksh manual:

Code:

paste <(cut -f1 file1) <(cut -f3 file2) | tee >(process1) >(process2)

This cuts field 1 from file1 and field 3 from file2, sends these to paste so that a "table" with these two fields is created. This is in turn sent to process1 as well as process2 and also displayed on screen (all by the tee command).

Again, always keep in mind thaat all this is done in subshells, so your variable scope (and other things too) might not be what you think it is.

Finally there is "command substitution". This is done by $( ... ) (sometimes ${ ... ; }) and works similar to process substitution but you can treat the output of the whole block as a string/number:

Code:

var=$(tail -n 1 /some/file)

tail -n 1 will extract the last line of a file. The whole construct will assign this last line as a string to the variable. Again, this is done in a subshell so you will have to watch variable scope, etc., because the subshell is left at the end.

Here is another example: sometimes you may want to preserve a return code in a more complex way. Say you have 3 commands and if any of them fails you want to consider all of them failed:

Code:

MyRetVal=$( RC=0
                         if ! command1 ; then RC=1 ;  fi
                         if ! command2 ; then RC=1 ;  fi
                         if ! command3 ; then RC=1 ;  fi
                         echo $RC
                       )

If all commands succeed RC will be "0", otherwise "1". This is printed by the echo command to stdout but assigned to MyRetVal by the command substitution.

I hope this helps.

bakunin

Code:

tail

In my searches about this original script, I had read about tail, but had not seen as clear an example as yours. That is, unfortunately, an issue with general googling. Before coming here, I did due diligence troubleshooting this script, and never did find the kind of explanations that you're providing. Either I'm googling the wrong words or their algorithm isn't sophisticated enough to generate a response beyond "Here's a script."

Code:

paste <(cut -f1 file1) <(cut -f3 file2) | tee >(process1) >(process2)

I've obviously bookmarked this thread, with the hopes of returning to it to fix future problems. Since I'm no mathematician or a user of spreadsheets beyond subject-note, my scripting issues mostly lie in the realm of how things are displayed on the screen, window title bars, genmon outputs, etc.

In light of that, I was wondering if you had the energy to explain the use of an ampersand.

Code:

( sleep 1
  while pgrep google-chrome-stable
    do  xdotool search --name Chrome 2>/dev/null | 
        while read id
           do xdotool set_window --name "Chrome" $id
           done
        sleep 1
    done
 ) &
google-chrome-stable

This script worked and because of this helpful thread, I understand why it did. I understand that the amperstand used in the line ") &" essentially says the "while" stuff will run in the background as long as "google-chrome-stable" runs in the foreground.

Okay. But what happens if a user wants to add something in between:

Code:

#!/bin/sh
( sleep 1
  while pgrep links
    do  xdotool search --name links 2>/dev/null | 
        while read id
           do xdotool set_window --name "Links2" $id
           done
        sleep 1
    done
 ) &
xlinks2 &
sleep .2
wmctrl -a "Links2"
sleep .2
wmctrl -r :ACTIVE: -b toggle,maximized_vert,maximized_horz
sleep .2
xdotool key s &

[the issue at hand: Links2 doesn't start maximized and clicking "s" brings up its bookmarks]

I could not get the maximization/bookmarks commands to run until I added strategic single ampersands. Without the ampersands, the wmctrl/xdotool commands don't run until after xlinks2 is closed, defeating their purpose.

If the "while" script runs in the background, xlinks2 runs in the foreground, but I don't yet understand how subsequent ampersands *also* seem to drop xlinks2 into the background; nor do I understand why the wmctrl/xdotool commands execute themselves directly on xlinks2 rather than on the "while" script or on some other window [which I have seen happen in previous failed scripts].

Feel free to beg off this thread at any time. The final script of this thread works perfectly; I'm posting for the sake of my continued erudition, or perhaps someone else's, should s/he be lucky enough to stumble here.

Have you considered multiple instances of this script running at once? pgrep allows matching only to processes from the current session with --session 0 this may stop you subshell hanging around until all instances of links have ended:

Code:

#!/bin/sh
( sleep 1
  while pgrep --session 0 links
    do  xdotool search --name links 2>/dev/null | 
        while read id
...

man bash:
Every command list followed by an & is put into background for execution and the next command is addressed, while commands without it are waited for to terminate. So, in order to get a bunch of programs in parallel, you need to put them all into background.


Rg. your other question "why the wmctrl/xdotool commands execute themselves directly on xlinks2": it seems that unless told otherwise these commands will work on the last (highest) window on "stack" which in this case is xlinks2. You may try to verify / falsify this assumption and report back.

@Chubler_XL--thank you for the idea

Code:

while pgrep --session 0 links

I ran that in both the Chrome and Links2 scripts, but the script does continue to spawn itself, with a maximum of three instances, usually running two instances.

But the modifier was new to me and I was glad to learn about it.

As for my ampersand query, thank you, RudiC:

>> it seems that unless told otherwise these commands will work on the last (highest) window on "stack" <<

Makes sense to me. It's intriguing that

Code:

xlinks2 &

can send xlinks2 to the background, but subsequent xlinks2 commands (window maximization, key strokes, etc) act as if xlinks2 is in the foreground, or at least physically visible. It would appear that background vs foreground features of a script are not literal, meaning that a given background process can actually be the one thing you're seeing.

On UNIX and UNIX-like systems, you can think of a foreground job as one that is connected to a keyboard and a background job is one that is not connected to a keyboard at that time. In a given interactive terminal session, only one job can usually be in the foreground at any given time. The foreground job can choose to move itself into the background and bring a job that was in the background into the foreground.

I understand your confusion, but none of this has anything to do with whether or not the window containing a job running in the foreground is currently visible on the screen.