Showing posts with label WSH. Show all posts
Showing posts with label WSH. Show all posts
Wednesday, May 17, 2017
Unix sed, Python CsvKit under Windows Scripting Host (WSH); Problems and solutions
This is a just a short article that described problem and finding I encountered in one of my project and were wishing that what I found can be useful to someone following a similar path as me - A short side track: Nerds or people like me working and sharing knowledge, a lot of times, were overlooked as been anti-social and less of charity or volunteering to the society. I for one, would like to pass and dispatch the messages that we, the nerd and genuine hard worker, are to be proud of our contribution to the society and world for making the world a better place.
Back to the topic.
I were involved in a Windows automation project and were writing most of my code in VBA. However, with my knowledge about the Unix way of doing things, it makes totally sense for me wanting to run some tasks through some Unix utilities program. As we all know, Unix way basically means command lines. Fortunately, Windows did not fore go the access to command lines. For VBA, there are the general Shell() command. But that is not the only option for VBA. With Microsoft COM infrastructure, VBA programmer has access to wide variety of objects. One of them is the Windows Scripting Host. By accessing to Windows Scripting Host, programmer can have better control of the DOS-shell/command-line environment.
While I was happily using the Windows Scripting Host to carry out my command line tasks, I notice that for most Windows/DOS based programs they all run great until I try to run some Unix utilities that were ported over to the Windows/DOS world.
Before I go on, I would like to point out that I did not spend a lot of time trying to figure out every single issues, so please bear with me for not be able to provide all possible solutions and explanations.
One Unix utility I used is the sed command from the MinGW/msys. I was able to verify its functionality by running some test directly under the Windows/DOS command line after removing some conflicting search paths from the PATH environment variables - for example, in my system, I also have Qt and GNAT installed.
After verifying the sed under that Windows/DOS command line, I invoked it through the Windows Scripting Host via VBA. The command failed with a return code of 2, which, for sed, could just mean errors during execution or , for DOS, could mean file not found. By testing with non-existing command, we know the Windows Scripting Host do recognize the sed command. By testing with simple 'sed -help 2>file', I realize it may have something to do with the shall's interpretation/parsing of command line. This lead me to the thought of using the Cmd.exe /C to run the sed. By running 'Cmd.exe /C sed ... ' under the Windows Scripting Host, everything worked out. The other command I run into the same problem is the Python CsvKit commands. Again, running with Cmd.exe solve the problem. At this point, I can't say I understand the problem. My hint is that it may have something to do with the redirection of the standard output since all my Unix and Python commands used the redirection.
Friday, November 8, 2013
Object library not registered error - MS ACCESS 97, VBScript, Windows 7 - WSH, Vista
Just to report a problem that I run into and hopefully this post can help someone that run into a similar problem.
The problem: Receive 'object library not registered' error when try to check referenced code in ACCESS 97 that references MS VBScript engine.
Suspected scope of the problem: This problem could also appear in code that was developed for other version of ACCESS on Windows Vista, XP or older operation system.
The sequel: I got some ACCESS 97 code that uses the regular expression object (RegExp) that was made available by Microsoft through the installation of Microsoft's VBScript engine (The latest version is the Windows Scripting Host version 5.7 and can be download from Windows Script 5.7 for Windows Server 2003). Recently, when I try to check the 'reference' (open a code module and -tools -reference) in ACCESS 97, I received the 'object library not registered' error and was not able to see the referenced object for the database.
Kernel of the problem: A reference to the 'VBScript Global' type library in Windows 7. Basically, in my old XP machine, I have to install the VBScript Engine so that the 'VBScript Global' COM (Component Object Model) object exist. But I did not do that on my Windows 7 machine.
The solution: After googling the web and found the Wikipedia article: Windows Script Host, it is clear that there is no VBScript Engine for Windows 7 to download. It should come with the Windows 7 machine. At that point, I was thinking maybe the RegExp is contained in other COM that I should reference. But I was failed to find one. In the end, I simply test the code: CreateObject("VBScript.RegExp") and it worked without me adding any reference in ACCESS.
The annoyance: Since the database is hosted on a network drive, I will have to add and remove the reference based on which machine I am using.
The problem: Receive 'object library not registered' error when try to check referenced code in ACCESS 97 that references MS VBScript engine.
Suspected scope of the problem: This problem could also appear in code that was developed for other version of ACCESS on Windows Vista, XP or older operation system.
The sequel: I got some ACCESS 97 code that uses the regular expression object (RegExp) that was made available by Microsoft through the installation of Microsoft's VBScript engine (The latest version is the Windows Scripting Host version 5.7 and can be download from Windows Script 5.7 for Windows Server 2003). Recently, when I try to check the 'reference' (open a code module and -tools -reference) in ACCESS 97, I received the 'object library not registered' error and was not able to see the referenced object for the database.
Kernel of the problem: A reference to the 'VBScript Global' type library in Windows 7. Basically, in my old XP machine, I have to install the VBScript Engine so that the 'VBScript Global' COM (Component Object Model) object exist. But I did not do that on my Windows 7 machine.
The solution: After googling the web and found the Wikipedia article: Windows Script Host, it is clear that there is no VBScript Engine for Windows 7 to download. It should come with the Windows 7 machine. At that point, I was thinking maybe the RegExp is contained in other COM that I should reference. But I was failed to find one. In the end, I simply test the code: CreateObject("VBScript.RegExp") and it worked without me adding any reference in ACCESS.
The annoyance: Since the database is hosted on a network drive, I will have to add and remove the reference based on which machine I am using.
Labels:
MS ACCESS,
VBScript,
Windows 7,
Windows Script Host,
WSH
Subscribe to:
Posts (Atom)