If you are really in a hurry and can't commit to learning the hundreds of forms in Common Lisp, Scheme is a minimalist alternative. The entire language has only a few forms on which make up everything else.
Scheme of 1975 was minimalist and it lacked a lot of things you need, like error handling. Since then Scheme went through various rounds of standardisation - currently Scheme R7RS large is in the works. Plus there are many quasi-standard extensions, based on SRFI: https://srfi.schemers.org.
If you add the usual stuff to Scheme then it is as large as Common Lisp.
Also Scheme is not generally simpler than Common Lisp. Macro programming or control flow in Scheme is not simpler than Common Lisp.
What is simpler than Common Lisp, is the core language used in education to teach programming concepts. For example in SICP a simple Scheme subset is used without any macro programming. But any practical variant of Scheme will quickly approach and sometimes even surpass Common Lisp.
Scheme R6RS Standard:
http://www.r6rs.org -> Standard + standard libs + appendices
Guile Manual:
https://www.gnu.org/software/guile/manual/html_node/index.ht...
Chez Scheme User's guide:
http://cisco.github.io/ChezScheme/csug9.4/csug.html
Racket Core Language:
Common Lisp has the advantage of having done a pretty good job at the hard problem of naming things and so ordinary activities have names with regular semantics like |remove| and |remove-if| -- generally |some-name| tests against a value and |some-name-if| tests against a predicate. Functions on sequences have keywords as supporting parts of speech that make it possible to state intent rather than write an implementation -- Common Lisp contains several domain specific languages that have proven to be useful.
One way to learn them is to read Steele's, Common Lisp: the language.
It's not that a programmer can't write their own version of |copy-tree| and a naive implementation is fairly easy. It's not but nominally more difficult or verbose than writing it in a Scheme or Clojure. The difference is that Common Lisp's built in |copy-tree| is probably sophisticated for performance and robustness reasons. Schemes come out of a pedagogical context and there not having a built-in |copy-tree| can be a feature because of what people may learn by its absence. Racket's Student Languages push this toward the limit.
To put it another way, Assembly Code has fewer constructs than Python, but often there is an advantage that comes with Python's higher level abstractions.
[1] Why the hurry: http://norvig.com/21-days.html
There's more stuff in Common Lisp, but once I learned the concepts behind how the naming worked, a lot of them didn't need to be learned as much as I just assumed they were there.
The "standard library" is large, but really well thought out. Writing in Scheme, I'd often need to implement functions that I knew were already in CL, so Scheme ends up being more work in the long run.
And it's not like a person needs to memorize all of the language constructs before using it. The REPL in Slime is incredibly helpful in discovering functions and verifying how they work, and Stack Overflow or web search can be really helpful finding out if a particular function is built-in or not.
There are 25 special forms in Lisp, and the standard forbids the creation of more: http://www.lispworks.com/documentation/HyperSpec/Body/03_aba...
MIT Scheme has 30 special forms: https://www.gnu.org/software/mit-scheme/documentation/mit-sc...
R7RS doesn't seem to define special forms per se; it considers anything other than define-syntax, literals, variables, calls, lambda, if & set! to be derived expression types; I think quote & quasiquote probably have to be considered special forms in at least some senses.
Scheme itself is a minimalist language, but a practical Scheme must add in plenty of functionality not specified in the standard. A truly useful Scheme will thus be roughly as big as Common Lisp, or bigger — only much less of that bulk will necessarily be standardised & portable.
Racket has a minor language for shell mix-ins[1] and Racket itself has some nice ways of dealing with command-line arguments[2]. However, all command-line arguments are passed as strings, which means extra steps in converting them to native types (numbers etc.). I find it very pleasant and Racket in particular has both a good standard library and a whole bunch of libraries that probably cover a majority of what one might need for smaller tasks. But again, it depends on what you consider "small-scale programming"
[1]: http://docs.racket-lang.org/rash/index.html
[2]: http://docs.racket-lang.org/reference/Command-Line_Parsing.h...
Racket is not just Scheme anymore, but it does still support various versions of Scheme as well as a number of Scheme-based languages. It has a package management system and a fairly large set of packages for basic tasks. The core system, base libraries, and major libraries are well documented and it's got a great built-in IDE.
Guile also does more than just Scheme, but it's been the "official extension language of GNU" for a very long time, so it's got bindings to a lot of libraries and it's used in some interesting applications and tools.
Chicken Scheme also comes with a package system, 'eggs', that has a pretty nice collection of practical packages available for easy installation. You can run your programs via the interpreter, or you can compile them via the compiler, which goes through C so it's got great C interop.
There are a lot of other options with a variety of strengths and weaknesses, but those are good ones to look at for starting out and doing scripting duties.
Personally, I use Chicken Scheme for command-line utils (thanks to AOT compilation Chicken Scheme programs start-up time is much shorter) and Racket for GUI programs. Both implementations offer stability, ongoing development and a package ecosystem which has most of the things I need. They also provide extensive tooling, with Racket going as far as providing an IDE and visual debugger.
Most of the problems you'd have when replacing PERL or Ruby with a Scheme would have to do with library/package availability. If your use-case doesn't require a library which your Scheme lacks it may be a suitable replacement for PERL, Ruby, Python or JavaScript (node).
Scheme and CL bicker over whether an empty list embodies the concept of falsehood. JavaScript says wat? And Haskell is like, lol.
Then here are some very nice SRFIs around to do most of what you want, and I believe chicken comes with basic pattern matching facilities as well (although not as sweet as the ML-type which are checked at compile time).