I need to write some scripts for WinXP to support some of the analysts here at Big Financial Corp. I need to decide which type of Windows scripting best fits my needs.
My needs seem pretty simple (to me anyway)
run on WinXP Pro SP2 (version 2002)
not require my users to install anything (so PowerShell is out. Likewise Perl, Python, and other common suggestions for these types of questions on Stack Overflow)
written in a non-compiled language (so users have a chance to modify them in the future)
reasonably complete language features (especially date/time manipulation functions. I would like to also have modern concepts like subroutines, recursion, etc)
ability to launch and control other programs (at the command line)
From my hurried review of my options, it looks like my choices are
VBScript
WScript
JScript
I don't have time to learn or do an in-depth review of these (or whatever else a standard install of WinXP has available). I need to pick on and hack something together as quickly as possible.
(Current crisis is the need to run a given application, passing several date parameters).
Once the current crisis is over, there will be more requests like this.
Edit
My current skill set includes Perl, JavaScript, and Java so I'm most comfortable using something similar to these
Edit
OK. I'll try writing a WSH file in JScript. I'll let you know how it goes (and figure out accepting an answer) once things settle down around here a bit.
Edit
It all worked out in the end. Thanks for the quick responses folks. Here's what I gave my user:
<job id="main">
<script language="JScript">
// ----- Do not change anything above this line ----- //
var template = "c:\\path\\to\\program -##PARAM## --start ##date1## --end ##date2## --output F:\\path\\to\\whereever\\ouput_file_##date1##.mdb";
// Handle dates
// first, figure out what they should be
dt = new Date();
var date1 = stringFromDate(dt, 1);
var date2 = stringFromDate(dt, 2);
// then insert them into the template
template = template.replace(new RegExp("##date1##", "g"), date1);
template = template.replace(new RegExp("##date2##", "g"), date2);
// This application needs to run twice, the only difference is a single parameter
var params = ["r", "i"]; // here are the params.
// set up a shell object to run the command for us
var shellObj = new ActiveXObject("WScript.Shell");
// now run the program once for each of the above parameters
for ( var index in params )
{
var runString = template; // set up the string we'll pass to the wondows console
runString = runString.replace(new RegExp("##PARAM##", "g"), params[index]); // replace the parameter
WScript.Echo(runString);
var execObj = shellObj.Exec( runString );
while( execObj.Status == 0 )
{
WScript.Sleep(1000); //time in milliseconds
}
WScript.Echo("Finished with status: " + execObj.Status + "\n");
}
// ----- supporting functions ----- //
// Given a date, return a string of that date in the format yyyy-m-d
// If given an offset, it first adjusts the date by that number of days
function stringFromDate(dateObj, offsetDays){
if (typeof(offsetDays) == "undefined"){
offsetDays = 0;
}
dateObj.setDate( dateObj.getDate() + offsetDays );
var s = dateObj.getYear() + "-"; //Year
s += (dateObj.getMonth() + 1) + "-"; //Month (zero-based)
s += dateObj.getDate(); //Day
return(s);
}
// ----- Do not change anything below this line ----- //
</script>
</job>
Clearly it could be better... but it got the job done and is easy enough for my user to understand and extend himself.
These are all technically the same thing with different syntax. Actually WScript/CScript is the engine, VBScript and JScript are the languages.
Personal opinion only follows: My personal recommendation is JScript because it reminds me more of a real programming language, and makes me want to punch myself in the face less often than VBScript. And given your familiarity with javascript, your best bet is JScript.
Going into a bit more detail about the difference between WScript and CScript as others have: these are your execution platforms for your scripts for the Windows Script Host. They are essentially the same thing, whereas WScript is more GUI oriented, and CScript is more console oriented. If you start the script with CScript, you will see a console window, but you still have access to GUI functionality, whereas if you start with WScript, there is no console window, and many of the default output methods display as windowed objects rather than a line in the console.
If you like JavaScript, you'll probably be ok with JScript. It's a decent language, and certainly more suitable for complex scripts than VBScript.
However, Microsoft1 hates JavaScript, so you'll encounter some APIs that are trivial to use with VBScript but painful to access using JScript. Consider yourself warned...
As snicker notes, WScript is the engine that drives both.
1 Anthropomorphization used to note general lack-luster support; not to be interpreted as evidence of any official policy.
Although JScript is a much less horrible language than VB Script, the problem is that VB Script has a more complete library of helpful functions built into it for things like date and number formatting. So it's not actually as easy a choice as it first appears, unless you are able to write and install your own library of helper objects to use with JScript.
Some details here.
Don't forget CScript. And be careful here, because the windows scripting host is often disabled by group policy at large companies. If that's the case, the only option that fits all your criteria is (shudder) batch.
If none of those work out for you, your best option is probably a compiled program where you distribute the source with the program.
Use JScript. A key difference between using JScript with the WScript/cscript engine and writing JavaScript in the browser is that you don't have the browser security restrictions. You also have access to ActiveX/COM objects for manipulating applications, the registry, etc. In fact, you'll probably spend a lot more time reading up on those custom objects and interfaces than worrying about the language features. Of course, you get all the benefits of JavaScript dates, regex's, etc.
A sample JScript app from MSDN might help to get you started.
Unfortunately, most of Microsoft's sample scripts tend to be VBScript, but the syntax is pretty easy to follow, especially if you're just trying to pick out COM interface details.
To expand on the other's answers a bit, WScript and CScript are programs used to run scripts written in VBScript (Visual Basic like syntax) or JScript (JavaScript-like syntax). CScript runs scripts from a console window, so that the Echo command writes to the console, whereas WScript runs them without a window and the Echo command writes to a popup message box.
You can write WSH (Windows Scripting Host) and WSC (Windows Scripting Component) scripts that use both VBScript and JScript by combining them in an XML-based wrapper, if you need to merge pre-existing code in the two languages.
You can also write HTA scripts, which stands for "HyperText Application". These are script code in an HTML file with the HTA extension that runs in Internet Explorer, which allows you to provide an interface using HTML controls, but also have complete access to your system because the run locally.
All of these are based on the Windows Scripting Host and Active Scripting technologies which have been included with all Windows computers since Windows 98. Along with fairly powerful base languages, they also give you access to WMI for extensive system and network information and management, and COM capability for automating Word, Excel etc. Also you can use ADO and ADOX to create and work with Access MDB files even if Access is not installed.
My choice would be WSH using JScript. You could use VBScript, but why, when JScript is available.
Here is a reference for Windows Script Host.
Related
I have a folder on my desktop called "images".
Inside are a bunch of sub-folders called various things "Flower_Shape", "Smile_Shape", "Dog_Shape", etc. and each folder contains 3 images "Variant1.PNG", "Variant2.PNG", and "Variant3.PNG" and then some other file formats that are called various things but they do not end in .png, they end in things like ".psd"...
How can I take all of the contents of these hundreds of folders, and move them all into 1 folder while changing the names from "Variant1.png" to whatever the name of the folder it was in is called (for example the "Variant1.png" inside the folder "Flower_Shape" would be re-named "Flower_Shape-Variant1.png") and then delete every file that doesn't end in ".png".
My first main question is what language would I use to do something like this? Would it be PERL?
After that is established, does anyone have any tips for how to go about doing this... I'm assuming just a for loop with some if statements should be all it really takes but I know nothing of perl (or any other languages that deal with changing files on my own computer for that matter)
Thanks!
Mac OS X comes with a whole assortment of scripting languages. It comes with Perl, Python, PHP, Ruby, and BASH.
Mac OS X also comes with Automator.
What should you choose?
If you're really, really interested in learning to program, I would suggest you start with Bash. BASH is what is called the command shell. If you type a command in at a prompt, it will be executed. The Unix shell is a powerful tool, and the BASH shell includes a lot of control structures that can be used. In BASH, you could use the find command and the mv command and write a loop to do what you want.
.
Shell scripts are limited in their power. They aren't suppose to be full service languages and make no apologies for it. If you need more than a few dozen lines or more complex control, you should switch to a scripting language.
I am a Perl programmer, but I would recommend, if you're really interested in learning how to program, to learn Python. Python is probably the most popular language and its use is certainly growing.
Perl is a nice language because much of its syntax structure comes from shell scripting languages. Despite what you've heard, Perl is still very much a popular language. I've found that people pick up Perl faster than Python because of it's looser syntax rules and the fact it doesn't have to be object oriented. That is also a major problem with Perl. Most Perl programmers never get past the basic hacking stage and Perl has a reputation of being a difficult language to maintain because of the sheer number of awful Perl scripts out there.
Ruby hasn't been as popular as Perl or Python, but it has its fans. The big power of Ruby is something called Ruby on Rails. Rails is a programming framework that allows you to quickly build web-based applications. You first should learn Ruby, then learn the Rails component.
PHP use to be the glue that held the web together. I believe its popularity has been dropping in recent years as newer web development platforms have come up. PHP is the mob rule of programming. Unlike all of the other languages, it doesn't have a single champion shaping the language and has developed a lot of detritus. It is sloppy and can be hard to maintain.
.
Still, it is the basis of a lot of web based forums and content management systems like Joomla. After all, PHP was designed to live inside of webpages.
If you don't want to learn script programming, you should try Automator. It comes with a Graphical User Interface and can allow you to build programs to do all sorts of tasks. People who have gotten into Automator have done some amazing stuff with it.
Whatever you choose, you can find some tutorials and information on the web, but if you really want to learn, you should get some good manuals. O'Reilly and Associates has a long storied history with computing and the Internet. Tim O'Reilly (the brains behind the company) has been producing computer manuals since 1978. Almost all of my books are O'Reilly books. Manning is another one, and there are dozens more. Go to a real bookstore before Amazon drives them all out of business and peruse their shelves for something you like.
You have to combine File::Find with File::Copy to reach those requirements
If you use perl, you should look into Path::Class and File:::Copy. That'll handle your path parsing. You'd want to iterate over the filesystem (Path::Class::Dir->next will be your friend here), build a destination file with something like:
my $curr_file = file('whatever_path...');
my $dest_dir = dir('some other path...');
my $dest_file = file($dest_dir, $curr_file->dir->basename . '-' . $curr_file->basename);
then use File::Copy to move:
move($curr_file, $dest_file);
Start by looking up those methods/subroutines and their usage; then you just need to code up the iteration.
I was able to accomplish this using this code (and changing the value inside the "glob" function to different levels of /// manually)
#!/usr/bin/perl
foreach my $files (glob ('*/*/*')) {
use strict;
use File::Basename;
use Cwd 'abs_path';
my $f = "$files";
my $d = basename(dirname(abs_path($f)));
my($file, $dir, $ext) = fileparse($files);
my $initialName = "$dir$file";
my $finalName = "$dir$d$file";
print("$initialName --> $finalName \n");
rename($initialName, $finalName);
}
Then it was as simple as moving the files with a move function into a new folder, like so:
#!/usr/bin/perl
foreach my $files (glob ('*/*/*')) {
use strict;
use File::Basename;
use Cwd 'abs_path';
use File::Copy;
my $f = "$files";
my $d = basename(dirname(abs_path($f)));
my($file, $dir, $ext) = fileparse($files);
my $initialLocation = "$dir$file";
my $finalLocation = "AllFiles/$file";
print("$finalLocation\n");
move($initialLocation,$finalLocation);
}
I often use Sweave to produce LaTeX documents where certain chunks are produced dynamically by executing R code. This works well - but is it also possible to have code chunks that are executed in different ways, e.g. by executing the code in the shell, or by running Perl, and so on? It would be helpful to be able to mix things up, so I could do things like run some shell commands to fetch some data, run some perl commands to pre-process it, and then run R commands to analyze it.
Of course I could use all R chunks and use system() as a poor-man's substitute, but that doesn't make for very pleasant reading in the document.
The new new thing (for multi-language, multi-format) docs may be dexy.it which for example these guys at opengamma.org use as the backend.
Ana, who is behind dexy, is also giving a lot of talks about it so also look at the dexy blog.
It's not directly related to Sweave, but org-babel, which is part of Emacs org-mode, allows to mix code chunks of different languages in one file, pass data from one chunk to another, execute them, and generate LaTeX or HTML export from the output.
You can find more informations about org-mode here :
http://www.orgmode.org/
And to see how org-babel works :
http://orgmode.org/worg/org-contrib/babel/
There is certainly no easy way to do this other than through either foreign language interfaces from R (maybe through inline if it's supported), or system(). For what it's worth, I would just use system(); that should be easy enough.
You can see this previous question about having a Sweave equivalent for Python, where one of the respondents actually creates a separate interface. This can give you a sense what what it would take to embed other languages which may not already be supported. At a minimum, you have to do major hacking on the Sweave driver.
Do you know emacs" org-mode and, more specifically, Babel? If you already know Emacs or are willing to switch to Emacs, then org-mode and Babel are the answer to your question(s).
For instance, I am currently working on a document which contains some shell-scripts, does computations with R and creates flow charts with dot (graphviz). Org-mode can export a variety of formats, e.g. LaTeX (that's what I use).
There is the StatWeave project which uses java rather than R to do the weaving, but will run multiple programs instead of just R. I don't know how hard it would be to get it to do Perl or other programs like that, but the homepage indicates that it already works with R, SAS, Stata, and others:
http://www.cs.uiowa.edu/~rlenth/StatWeave/
I have been searching for a FAQ to tell me how to open a Excel Workbook/Worksheet and also how to Save the File once I have finished.
I notice that in most FAQ and all the books I have purchased on F# one is show how to create a new Workbook/Worksheet but is never shown how to either open or Save it.
Being a newbie to F# I would very much appreciate it if anyone could kindly provide me with either an answer or perhaps a few pointers?
Update
As for why F# and not C# or VB?
I am pleased to say that inspite of being a newbie (with the exception of Forth, VBA & Excel 2003, 2007 & 2010 and Visual Basic) I can do this in both VB, VBA & C# and since I've been retired on medical grounds, with plenty of time unfortunately on my hands, I like to continually set myself challenges to keep my little grey cells active and being a sucker for trying new languages....well!
F# is now an intergral part of Visual Studio 2010 so I thought - why not. Consider this - if we are not willing to use or at least try a new languages - I would always be wonder if I might have prefer it to VBA, VB, C# ..... and if you look at it from another point of view, if no one is going to use it - why create it in the first place? I suppose you can say if cave men hadn't experimented and made fire by rubbing two sticks together - where would we be now and would matches have been invented?
Although an complete answer would be good, I prefer a few pointers, to keep my challenge going.
And lastly but not least - thank you for taking the trouble to respond!
I don't think their is a specific F# library for Office, so you will just use the exact same .NET library that you use in VB.NET/C#. F# is a .NET language, so anything that can be done in C# can be done in F# (but you probably already knew that :) ). The API call will be exactly the same, it just that they will be done using the F# syntax instead of the VB/C# one. So for example something that look like this
public void SaveMyWorkbook() {
string filePath = #"C:\failworkbooks\catfail.xlsx";
workbook.Save(filepath);
}
Will be expressed in F# as
let filePath = "C:\\failworkbooks\\catfail.xlsx";
let saveWorkbook() = workbook.Save(filePath) |> ignore //if the Save method return something
Now, what you will soon realize is that the API isn't exactly designed to be easily used from a functional language. It can be done, but this task in particuliar is much more tailored to C#/VB.NET.
If you really want to enjoy F#, I suggest you use in area where its strength really show. My personal experience is that functional language are awesome when a lot of math is involved. It is also marvellous if you want to easily introduce parallelism in your application (since F# code is usually side effect free). So anything that require data crunching on a lot of data is perfect for it. But for task that consist mainly of putting together a bunch of API call to an external library, F# is kind of meh. You could say that F# is kind of like a graphic card programming language, while C# a general purpose CPU programming language. A lot of thing run better with C#, but the stuff that run better on F# run really better on it.
But if you really want to go that route, my suggestion is to try to use the Office API as you already know it, but with a F# syntax. If at some point you really have no idea how to do a specific task, ask a question about it on stackoverflow with your code and exactly want you want to do. Those question get answered ridiculously fast compared to broad all-encompassing question, so you won't wait long. (Programmer seem to love precise question with a specific answer ^^)
I hope that it helped a little.
I found this http://iouri-khramtsov.blogspot.co.uk/2011/12/automating-excel-with-f.html helpful advice. Briefly, you'd use something like this:
#r "Microsoft.Office.Interop.Excel" // Assuming it's a script
let excel = ApplicationClass(Visible = true)
let openFileName = #"C:\MyDir\MyFilenameToOpen.xls"
excel.Workbooks.Open(openFileName)
// Do stuff
let savedFileName = #"C:\MyDir\MyFilename.xls"
workbook.SaveAs(savedFileName)
Using F# with Excel seems like a natural fit.
Getting to a result in Excel requires the use of several immutable values, each driven by formulas. Excel has a brilliant user interface, a lovely model of the world - I love rows, columns and cells - but to automate or customise things requires macros. Why learn this when you can use F#? Formulas and immutable values are fundamental to its design.
Ideally you'd write formulas yourself as a User Defined Function (UDFs) also in F# - see http://excel-dna.net/ . Then, perhaps, you'd want to do something interesting with objects/types - Look for "github com mndrake ExcelObjectHandler" (I don't have enough reputation to post a 3rd link).
Jack
I need to write some vbscripts in my new project. I was told by other people that vbscripting is easy, but seems to me, it is not. For example, in the following example (provided by microsoft), these functions: CreateObject, CreateShortcut, as well as these property names: TargetPath, WindowStyle, Hotkey, etc, are used, but I just cannot find the corresponding API documentation about how to use them. In other words, how do you know you need to call these functions in your vbscripts? Visual Studio 2008/2010 do not have templates for vbscript either. Could anybody tell me what I am missing, and what the best way is to do vbscripting?
set WshShell = WScript.CreateObject("WScript.Shell")
strDesktop = WshShell.SpecialFolders("Desktop")
set oShellLink = WshShell.CreateShortcut(strDesktop _
& "\MyExcel.lnk")
oShellLink.TargetPath = _
"C:\Program Files\Microsoft Office\OFFICE11\EXCEL.EXE"
oShellLink.WindowStyle = 1
oShellLink.Hotkey = "CTRL+SHIFT+F"
oShellLink.IconLocation = _
"C:\Program Files\Microsoft Office\OFFICE11\EXCEL.EXE, 0"
oShellLink.Description = "My Excel Shortcut"
oShellLink.WorkingDirectory = strDesktop
oShellLink.Save
Take a look here (MSDN).
The objects you are working with are documented there (of course, it's MSDN documentation so it's not ideal, but it's documented nevertheless).
Specifically the WshShortcut Object and the WshShell etc.
I don't think VBScript is a very easy language, especially if you need to write larger scripts.
If you don't specifically need to write a script but it would be ok with an executable I'd look at using VB.Net instead, where you have a good development environment that makes everything much easier since you have Intellisense and you can just press F1 for the documentation. And since it's a typed language with a large framework it gets easier to avoid mistakes and many operations you need you can just call a method in the framework rather than writing your own code.
However, if you do need to do it in VBScript, I'd suggest trying to find some kind of IDE for it. I haven't used any, but at least this one seems worth looking at.
The language of VBScript is relatively easy. It's a subset of Visual Basic and VBA and simplifies some things from those environments (eg you don't need to declare variable types).
What you are dealing with above is working with the methods and properties of a given object, WshShell. There are many many objects out there, each with their own set of methods and properties to know about, many with common usage conventions, and many more with "unique" (ie idiosyncratic) usage requirements. This is where the complexity comes in, but it's not part of VBScript itself. You will run into this with any other language (JScript, Python, Delphi) that works with the myriad objects and APIs that are out there for Windows system management.
The plus side is that once you get used to the language of VBScript and the process of looking up object API references and examples on MSDN and other sites, it does become very easy to put together complicated and powerful scripts.
Like I frequently tell users, computers often make things faster the second time you do something. The first time usually requires some learning.
A great set of resources for learning VBScript and how you need to approach things is the
TechNet Script Center, their Hey, Scripting Guy! series, and the Script Repository.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Import AppleScript methods in another AppleScript?
Is there anything in AppleScript that can be used like the #include directive in C?
For instance:
INCLUDE_DIRECTIVE "Path/To/Applescript.scpt"
//Some AppleScript code here
Absolutely you can do this, and there are two variations. The first loads the entire script:
Script Foo.scpt
set theBar to "path:to:Bar.scpt" as alias
run script (theBar)
Script Bar.scpt
display dialog "Bar"
--Result: A window that displays "Bar"
The second allows you load a script and call specific methods within that script:
Foo.scpt
property OopLib : load script POSIX file "/Users/philipr/Desktop/OopLib.app"
tell OopLib
set theResult to Oop(1)
display dialog theResult
end tell
--> result: Window displaying "Eek: 1"
OopLib.scpt
on Oop(Eek)
display dialog Eek
return "Eek: " & Eek
end Oop
Use something like this to load the script
set scriptLibraryPath to (path to scripts folder from user domain as text) & "myScript.scpt"
set scriptLibrary to load script scriptLibraryPath as alias
Then to access a subroutine in that script do this...
set myValue to someMethod() of scriptLibrary
To add to what other posters have said, load script is the only built-in option; it's very primitive, but may be sufficient if your needs are modest.
Late Night Software's Script Debugger editor provides an #include-style library mechanism that can merge multiple AppleScript files when compiling a script. The downside of Script Debugger is that it's a couple hundred bucks to buy, though many regular AppleScript users will tell you it's well worth the investment.
There are a couple of third-party module loaders, Loader and ModuleLoader, that implement more sophisticated import mechanisms on top of the basic load script command, and are worth looking into if your requirements are more complex. I've not used ModuleLoader, but Loader (which I wrote) can import modules at compile- or run-time from various standard and user-specified locations, and will automatically resolve complex (even circular) dependencies between modules.
The downsides of Loader and ModuleLoader is that they rely on scripting additions to do some of the heavy lifting, which might be an issue when distributing scripts (in Loader's case, the osax is only needed to compile scripts, not to run them), plus you need to add some boilerplate code to your script to perform the actual import.