Newbie Question: Shell-like Scripting in Python?

[Alex Martelli]

Scott Meyers wrote:
        ...
> Another thing I want to do is write short shell-like scripts for my
> Windows machine, e.g., copy and move or rename files whose size fulfills
> some
> criteria or whose name matches some regexp, etc.  One of the reasons I

Yes, Python is quite suitable for these kinds of tasks (as well as others).


> decided to play with Python was that I thought it could do these
> scripting-like things; the first sentence on the back of "Learning Python"
> refers to its suitability for "quick scripts."  However, I haven't seen
> anything in the book's TOC or index on shell-like scripts, and a cursory
> scan of the info at www.python.org didn't show any examples of things like
> manipulating the underlying file system in a shell-script like manner.  So

I agree that there's a dearth of such examples.

> here's my question: will Python let me do that?  I'm not asking about how
> powerful the language is -- I know I can do anything with it.  But suppose
> I want to rename files matching foo.* to be bar.*.  Ideally, I'd like to
> be able to say something like this:
> 
>   rename foo.* bar.*
> 
> Will Python let me do that kind of thing?  If so, great.  If not, that's

The only problem is whether you can convince "Windows" to run something
called 'replace' via the Python interpreter.  That depends entirely on
what Windows version you have.  COMMAND.COM can't do it: by "rename" it
tries to run rename.bat, rename.com, rename.exe -- that's all.  CMD.EXE
IS extensible enough to do it -- you can set environment variables that
tell it to add PY to that set of extensions (and pass PY files to
Python -- that's called a "file association" in Windows) -- but in
most versions I have tried CMD.EXE has bugs when these options are
used together with IO redirection.

Python can't fix the bugs and limitations of your chosen commandline
shell -- unless you choose to use a Python program INSTEAD of your
chosen commandline shell, of course (there is such a beast written to
replace command.com, but I forget its name).

Most likely you'll need to give to (e.g.) command.com a line such as:

python /scripts/replace foo.* bar.*

or you could package up a tiny (e.g.) .BAT (or .CMD for CMD.EXE) to
let you write a more confortable

py replace foo.* bar.*

automatically using python.exe and the directory or directories where
you keep your scripts.

Once the Python script finally does get control it will easily be
able to perform your desired task.  You will often use several modules
from the standard Python library:

sys     to access the program arguments (sys.argv)
glob    to expand wildcards
fnmatch to check if a specific file matches a wildcard
os      for lots of OS-level operations
os.path for lots MORE os-level oeprations
shutil  for file-copying (and directory-tree removal)

and no doubt even more.

If you have Microsoft's Windows Scripting Host (WSH) and Python's
Win32 extensions (Hammond's win32all) you gain many more ways to
perform similar tasks (e.g. via wsh's "cscript" script-runner and
win32all's installation of Python as an ActiveScripting language)
as well as ways to perform many tasks that are normally hard to
impossible for Windows scripts (COM, which win32all equips your
Python with, unlocks basically all doors in Windows -- and those
you don't get to via COM, you can handle via WIn32 API calls,
through win32all and/or calldll for those win32all doesn't
support, such as the PSAPI for process-management tasks -- if
you DO use calldll, see e.g
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/117219
for an example).  WMI, in particular (the "Windows Management
Instrumentation" technology) is awesome -- huge, rambling,
disorganized, whatever, but I suspect that ANY sysadm task you
may ever want to perform can use WMI for system interaction,
and Python with win32all (thus, with COM) lets you use that.


> okay, too.  At this point, I'm just trying to set my expectations
> correctly.

You can set them very high for Python and anything directly
Python-related -- very low for COMMAND.COM, an old and unlovely
hack that never got much maintenance and improvements -- and
somewhere in-between for CMD.EXE and most other Microsoft-supplied
pieces of software, which your scripts will no doubt have to
interact with (COM-related technologies seem mostly pretty
good, except for the little detail that they're often huge,
rambling, and full of redundancies and pitfalls -- this goes
for the object model of WMI just as well as for those of MS
Office applications).


Alex