Configuring fields to be extracted by a data processor
This seems like a desperate attempt to find a use for closures, and I believe your problem would be solved much more simply by making $rec an object, perhaps even a tied object that lets you overload indexing

Some observations:


It makes the API much less useful when the calling code has to know which form of data it is dealing with anyway. ret_col_sub returns a closure that expects a simple string for its parameter, while ret_substr_sub returns a closure that requires an array reference. All of that should be hidden from the caller
I can see that ret_col_sub won't compile
Checking that a string doesn't match \D isn't sufficient to ensure that it is numeric, as an empty string will pass that test
It is correct to rebase the substring offset, but a length is a length and that should be left untouched
The postfixed ++ and -- operators have become popular because of the name of the C++ language, but unless you are using the value returned by tge operator you should be using tge prefixed version. It is wrong to rely on the compiler to optimise out the storage of the unused original value
As has been said, your style contravenes common standards, in particular those laid out in perlstyle which are the most universal