There is no good, single equivalent to AppleScript in Unix-ish environments outside Mac OS X.
For intra-application scripting, many applications embed languages for use in configuration and customization, but there is little standardization as to which language(s) are embedded. Tcl was designed to be embedded into applications, but many applications seem to prefer embedding a more trendy (or at least previously trendy) language like Perl or Ruby. Some less well-known examples of embeddable languages include S-Lang, io, and Lua. Lisp, and Scheme are common bases for custom languages (like Emacs Lisp). Sometimes applications use completely novel languages. Finally, not all applications embed languages at all (even in Mac OS (X), not all applications support AppleScript).
One view of the Unix philosophy is “small, specialized, composable programs that read and write text streams”. This view tends to emphasize inter-command scripting. The most common composition method is filtering (utilized as ˜pipes’ and ˜I/O redirection’). The idea is that the user can string together a host of small, specialized commands to create more complex pieces of functionality (which then might themselves be composed).
Some of the most common programs used this way include grep (filters out lines that match/do-not-match a “regular expression” (a (set of) mini-languages that are recurring themes in many tools/programs/commands/applications)), sort (sort lines according to various parts of the line), head (extract some of the first lines of an input stream, discarding the rest), tail (extract just the last lines of an input stream, discarding the rest), find (recursively search for files that match given criteria and produce a stream of pathnames), xargs (consume a stream of arguments and integrate them into new command strings), ls (list files), cp (copy files), mv (move/rename files), rm (delete files), curl/wget (HTTP/FTP/. upload/download), etc.
As an example, for your “#1” item, you might use convert from ImageMagick for image resizing, zip for zipping, and mv for moving. mv is standard, zip is usually standard (Info-ZIP is open source), ImageMagic is open source and is probably available on most systems (it has pre-compiled binaries available (or you could use something like MacPorts to compile it for you)).
The core of such scripting can be almost any “scripting” language that makes it easy to run other commands with some minimal amount of control over the supplied input and the generated output. The most common languages used in this area are the “shells”. Chief among the shells are those that are related to the Bourne shell (the traditional /bin/sh). The Bourne-type shells include sh, ash, dash, ksh, bash, and zsh (maybe a few others, too; often sh is a compatibility-mode version of one of these other shells). One or more of these shells is present on every modern Unix-ish system and almost every other Unix-ish system from the past three decades. This makes Bourne shell scripting the number one environment for portable command scripting.
When (extreme) portability is not a requirement, or when the required manipulations become more complex, some of the more recently developed languages are often used in the place of a shell language. The common ones are Perl, Python, Ruby, and Tcl, though there are many, many other candidates.
Learning to script in a Unix-ish environment will come in two parts: the language (take your pick), and the “library” (all the small programs that can be combined together in useful ways, plus the library of functionality included with your language). I know of no shortcut to learning all the small programs. Read others’ scripts, ask task-oriented questions in scripting-related communities (Usenet, forums, mailing lists, groups, Q&A sites, etc.). For each of the languages, there are probably one or more books available and many free online tutorials and resources.
Eventually, you may come to a situation where you want to do some intra-application scripting but the application does not support any of the languages you know. First, try to approach the problem from a different perspective. You might be able to reimplement the functionality in your preferred language with the help of some of the composable tools you have already learned. If that is not possible, you now have an opportunity to broaden your knowledge. Start to learn the new language. If the new language is different enough from what you already know, learning the new language will often make you a better programmer/scripter/user because it forces your mind to generalize and reinterpret your existing knowledge.