Some irritation due to extended output of systemd / systemctl status for sysv services

Bad is an unpleasant word, right? “On” or “off” implies some final statement, or “failed” may signal something wrong but at least terminated. But “bad”… uuuhh, blameworthy, guilty, unaccountable, still being around. Ok, before diving into linguistic depression, the change eventually turned out simple and was actually in good faith but, however, produced remarkable irritation. You know, systemctl status {service} will show an overview of some systemd unit definition with load state, current activity and so on. The load state, in particular, details, in parantheses, into the path of the unit file, the enablement and the vendor enablement preset, respectively. Original systemd units may give a load state as follows:

Loaded: loaded (/usr/lib/systemd/system/atop.service; enabled; vendor preset: disabled)

However, systemd units, that have just been derived from systemv init scripts, only printed the init script path since lately:

Loaded: loaded (/etc/rc.d/init.d/sysv-thing)

The new irritating factor now is an extension for those derived systemv init scripts, to also state the enablement, but show up as “bad” for the running enablement for whatever weird reason:

Loaded: loaded (/etc/rc.d/init.d/sysv-thing; bad; vendor preset: disabled)


Loop over sqlplus connection identifiers from in dos shell

Nearly at the same season last year, I wrote about ways and uses of piping sqlplus commands into a sqlplus session from a dos shell script (see : Piping newlined commands into sqlplus from a dos shell). The pattern worked fairly well so far such that I employed the technique more often lately to deploy code changes around database instances. However, when the piping stuff relieved me from writing that show errors and exit over and over again for every sql-script, I was still forced to duplicate script code over any database identifier and database session in action.

There was a point, eventually, when I felt I need to take this further, introduce a loop like in any programming language, in fact suffer this dos shell syntax quirksmode (a ss64 syntax redirection article was of great help) and just do it. Ok, it took some time to grab this enabledelayedexpansion thing, the array syntax and so on but here you go. Regard the doubled percent signs prefixing the loop variable, the array for the tns variable and again, the tremendous clear text password use within a script. Ahem, yes, compared to the antecessor article, you do not need the ampersand sign anymore, when the individual echo comands occupy own distinct lines (changed it over there).

@echo off
setlocal enabledelayedexpansion
set USR=joe
set PWD=joe
set TNS=(db1 db2)

chcp 1252
cd /D d:\database

for %%I in %TNS% do (
  (echo set timing off
    echo select '%USR%/%%I' as connection from dual;
    echo @package1.pck
    echo @package2.sql
    echo @package3.sql
    echo exit
  ) | sqlplus -s %USR%/%PWD%@%%I

Have fun, Peter

Piping newlined commands into sqlplus from a dos shell

sqlplus indeed does not offer a wealth of options on the command line. When it comes to running sqlplus in a dos shell the prospects even go worse for executing some batch logic outside the sql script itself (I still did not manage to find me some time to learn more abount power shell, maybe things work out smarter there). Say, for example, you want to deploy a package body to a number of instances but have no option to inject the sqlplus commands show errors and exit into the package body file. All you can do that far is setting up a batch script, probably unsing the “-s” and “@” options of sqlplus, containing a three-liner for each and every instance like so:

sqlplus -s usr/pwd@tns @./package.sql
show errors
Package Body wurde erstellt.
Abgelaufen: 00:00:00.42
show errors
Keine Fehler.

For a large number of instances, the actually (my point) superfluous two lines of show errors and exit may lead to tedious batch scripts containing almost redundant commands. Knowing how to pipe commands into scripts from un*x, I investigated options to behave comparably on windows and dos shell. Not some 15 minutes later, see the refs below, i came up with the following approach that makes the three-liner a one-liner (like that), takes no change against the package body file whatsoever and even reduces the output by another two lines.