While making the script to switch the desktop between 2 versions of PB (see here), I needed a command expression to check if a task (PB and EAServer in this case) is running already. There are many ways to do it on *nix. But on Windows, it’s a bit convoluted. After researching on the net, this is what I came up with.
tasklist /nh /fi "imagename eq notepad.exe" | findstr /i "notepad.exe" >nul && (echo Notepad is running) || (Echo Notepad is not running)
That’s all in one line. If you need to break, use the continuation char, ^.
I use the above command expression in the batch file to check if a process is running already before running it again. I use this is a batch file I created to switch between 2 different versions of PowerBuilder (PB). I wanted to make sure, one version of PB is not running, before letting the user to switch, hence this check. (replace notepad.exe with PB125.exe above).
/nh means no header, /fi means filter. We are filtering for Notepad.exe only above. Then, we take that and look for Notepad.exe using a FindStr command. It will still work, even if we don’t have those 2 flags, but it makes finding the right program quicker.
&& and || are part of the conditional expressions see here. We use these to print for the IF…ELSE condition.
>nul is the equivalent of Unix /dev/null
Rest is self explanatory, I think.
I’ve also posted this scriptlet on the commandfu.com site.
Ever since I found symbolic links are available on Windows, I’ve used it in various places. To reduce the PATH entries, so it doesn’t overflow, to overcome program idiosyncrasies etc. In this post I will tell you what I did with some DLLs, so I could run different versions of a software.
Both the software are in the context of PowerBuilder, a development IDE from Sybase (Now SAP). PowerBuilder with a scripting language called ORCA. Each version of PowerBuilder comes with a version of a tool that implements OrcaScript. Most things you do inside PB IDE can be done through Orca script – for e.g., you can build, deploy entire workspaces or targets using Orca script. Yes, it’s typically used in automating build processes. Though PB comes with Orca Tool (called orcascr125.exe in PB 12.5), I had already used another tool PBOrca. I really like this tool, so I wanted to continue to use this tool. But, this is an older tool that may not work with/understand PB 12.5.
In a PBOrca script, to work with a particular version of PB, you use the Session Statement:
session begin pbOrc100.dll
The other use was when I did some beta testing with PowerBuilder 15 recently. To build and deploy our PB application, we use Powergen. This is a build tool developed by E.Crane computing for building complex PB applications. It resolves circular references in PB libraries and builds applications smoothly. Powergen apparently uses ORCA to interface with Powerbuilder.
Symbolic Links to the rescue
When I first tried using PBOrca to build code in PB 12.5, I wasn’t sure if it would work, since 12.5 wasn’t in the support list. I decided to try posing PB 12.5 dll as 10 dll with the help of, you guessed it, Symbolic Links. I created a symbolic link named pborc100.dll pointing to pborc125.dll. Bingo, I was able to connect to and build PB 12.5 code. Get it? The software thinks it’s still loading to PB 10.0 DLL (the link PBORC100.dll, which indirectly invoked PBORC125.dll!). You could do this magic to some directory renames as well. I mentioned about Repository pointing to 2 different versions in my other post.
(Though, in all fairness to PBOrca, it actually worked with PB 12.5 dlls fine, but didn’t try that initially. All I had to was change the dll name in session statement).
Next time Symbolic link came to the rescue, was when I wanted to test Powergen build process with PB 15. When I did my beta testing, I had scripts setup for me to switch from 10.2 to 12.5 (See here). I wanted to reuse these scripts, without much changes. Unfortunately, Powergen does not know, PB 15 exists yet. After some thinking, realize symbolic link could help me here. I just created a symbolic link for a PB dll used by Powergen. The symbolic link posed the PB 15 dll as a PB 12.5 dll. This worked!!! I was able to build a PB 15 version of the application using Powergen 8.5, which doesn’t naturally support PB 15 yet.
In both the above cases, posing one version of DLL as another worked only because, there wasn’t major changes to the DLLs themselves across the version. Otherwise, I would have gotten some compile or linker error.
Note: We have paid full license fee for Powergen upgrades. The hack I did was to make it work, was for test only. Please do not construe this as way to avoid licensed upgrades.
This is about running SQL*Plus in batch (script) mode. Suppose you have a script (shell or batch file) that calls SQL*Plus to execute a script file. I am talking about running it from Command line, thus:
$ sqlplus <user_id/password>@SID @<sql_file_name)
Chances are, you will want to exit SQL*Plus as soon as the script is done (EOF file is reached in SQL file), so we can continue our processing.
Typically, we add an EXIT statement at the end of the SQL file itself and this will force SQL*Plus to quit. What if you forgot or couldn’t add EXIT (in case, you use the same script in a different scenario – like this script gets called by another sql script, like a wrapper sql). If you don’t have an EXIT or QUIT statement at the end of your SQL file, you will end up seeing the SQL Prompt:
And it waits for the user to type the next statement (or if called from within a wrapper, it may produce unpredictable results depending on the next script file/statement wrapper sql has).
In such scenarios, you can add the EXIT statement externally, by typing
echo EXIT | sqlplus <user_id/password>@SID @<sql_file_name)
This works in both Unix shell scripts and Windows batch files.
This essentially types EXIT into the SQL Prompt. In case you are wondering, if it will exit immediately, the EXIT statement is really queued after all that is in the SQL*Plus input, in this case what’s in the script file. Thus, it correctly executes EXIT when SQL*Plus finished executing rest of the statements – this means when it reaches the EOF in this case.
Here is another way to achieve the same result:
exit | sqlplus <user_id/password>@SID @<sql_file_name)
(That’s it. Essentially piping exit into sqlplus command! When the End of the current script file is reached, SQL*Plus returns to the shell and your shell script (or the wrapper sql) can go on!
This also works on both DOS (Windows command prompt)_ and *nix systems.
I shared the original tip in 2012. After many years of being there, I see that this post is one of the popular ones! Who could have thought?!!
I have updated the post, to include “echo EXIT”, based on a comment below.
EXIT and QUIT are SQL*Plus commands (case doesn’t really matter, just wanted to distinguish them from OS commands). By echoing them into SQL Prompt, you force SQL*Plus to exit.
My suggestion to use exit | sqlplus, uses sending a signal to the program to exit (this is like executing Ctrl-D on Unix). In this case exit is an OS level command/program.
The difference in the 2 approaches is when you use echo EXIT, you are literally “typing” into sqlplus prompt where as in the other case, you are signaling it to end. Both will work, but using exit OS command may be OS dependent. Test on command line, before use.
A basic Operating system level unit in Powerbuilder is a library file (.PBL). Each PBL file is a self contained directory in itself, with the objects stored inside in a proprietary binary format. You need Powerbuilder to view and work with this directory structure (System tree, Library painter etc).
Sometimes, it would be nice to be able to work with individual objects as text files at the OS level. This will enable us to use any text utilities to work with the objects as files (like you would a Java or C++ file). For e.g., I have a Perl script to grep through the exported text files. With text files, you can store away these source files in any version control systems (PVCS, SVN etc) easily. And you can easily diff 2 versions of an object by using any text diff tool (Of course, there are tools available to do these from inside PB, but it’s just lot easier to work text files). PB allows the source code to be exported to text files with extensions, *.sr? (.srw for windows, .srd for datawindows etc.).
PB ORCA is an API that Powersoft developed early on for 3rd Party CASE tool vendors to work with PB objects. With PB ORCA, you can write programs to work PB libraries and objects from OS command line. Several object level operations available in PB IDE are also available in this API. Incidentally, there is a command line utility available with the same name (pborca.exe) on Google Code. The tool has several commands that correspond to API functions. You can create a ORCA script file (with .orc extension) and run it in batch mode using the tool. See here for a complete list of commands supported by the tool.
Below script uses pborca.exe in a DOS batch file to export all the objects in all the PBLs in a project directory to a corresponding directory structure. The batch file first loops on a list of .pbl files in a directory (passed in), and creates an ORCA script (latax.orc) with export commands. Then it runs the generated ORCA script using pborca.exe to export the object files (.*sr?). When the script finishes, you will have directory with several sub-directories, one for each PBL file exported.
This script uses several advanced features (%~ modifiers, ENABLEDELAYEDEXPANSION) of DOS Batch file. DOS scripts do several things a Unix script does, but it’s almost like an after thought! More on these later.
I use this script for daily backup of my development environment. Often times only a handful of files change on the developer’s PC. Once I export the PBLs to a directory, I can diff 2 different versions using a diff tool. (I use Winmerge). The files can be optionally zipped up as well.
Pborca.exe can also handle the reverse (known as bootstrapping). Exported PB object files are only useful for performing file level operations. To be useful in a PB application, they will have to be imported back in to a PBL file again which can then be opened inside Powerbuilder. As of version 9, PB ORCA can be used to bootstrap as well. See here for the idea.
REM 12,2009 Sam V REM script to export PBLS using pborca.exe (ORCA interface to PB) REM this copies all the folders from source (typically Z:) to target. REM then it creates an ORCA script to export each pbl to the subdirectories. REM Finally it runs the generated orca script in pborca REM @echo off echo %0 %1, %2 @REM copy all the directories from the powerbuilder root to the export directory @REM if a x.PBL is already in x subdirectory, you may not need MKD1 below. @echo creating the target directory; just copy the entire path with empty sub-directories xcopy /t /e /I %1 %2 @REM Here we start generating the orca file to be used with <a href="http://pborca.googlecode.com/svn/trunk/install/deploy/pborca.htm">PBORCA</a>. @echo session begin pborc100.dll > latax.orc @echo off @SETLOCAL ENABLEDELAYEDEXPANSION @FOR /f "usebackq delims=" %%a IN (`dir /s /b %1*.pbl`) DO ( @set a1=%%~dpa @REM echo a1=%a1% @call set "a1=!a1:%~1=%~2!" @REM MKD1 @REM This creates a sub-directory with the same name as PBL file mkdir "!a1!" @echo export %%~fa,,,!a1! >> latax.orc) @echo session end >> latax.orc @ENDLOCAL @echo on @echo run the script in pborca pborca latax.orc REM end of script