Currently Script allows you to specify up to 255 script files in a comma delimited argument -i (http://docs.synergyde.com/tk/tkChap2Compilingscripts.html#Rkae11919); however there are several limitations to this:

1. The first limitation is the 255 Script File Limit (we currently have 1,023 Script files that need to be scripted) the 255 Limit seems aribrarty in any case.
2. The Windows Command Line Interperter has a limitation of 8191 characters anyway https://support.microsoft.com/en-us/kb/830473 if you're using descriptive names for the scripts you blow the limit very quickly.
   1. Both of the above can be solved by chunking to meet the artificial limitations, however it seems like needless work on end users when the compiler itself should just be enhanced.
3. Script stops execution after the first error (this might be by design)
4. The current output of Script is not condusive to understanding where the error comes from.
   1. Enhancements such as an XML Driven output would assist (there is an Idea for this here: https://synergexresourcecenter.force.com/apex/SiteIdea?id=08732000000CxHOAA0)

Allowing for an aribrary number of script inputs would improve the situation.

I see a few possible solutions:

1. Enhance Script to take a new optional flag -rsp that takes in it a Response File that indicates the files for which to process
   1. This is the perferred solution; and is similar to the behavior of the MDIL Compiler (https://msdn.microsoft.com/en-us/library/windows/desktop/aa367284(v=vs.85).aspx)
   2. It allows for the files to be explicitly listed as opposed to the other solutions below; also avoids the need for craziness with input redirection.
2. Enhance Script to support specifying a directory which contains all of the files to be scripted
   1. This is not a perferred solution; but better than the ones presented below. Allow for the specification of a directory to process script files in, other processes would populate the directory with the files that need to be scripted.
3. Enhance Script to support use of a Wild Card in the -i parameter
   1. This is not a perferred solution; but better than the ones presented below. Allow for the use of Wildcards (*) in the -i argument.
   2. This opens pandora's box with regards to bad script files (such as files maybe not ready for production) making its way into developers builds.
4. Enhance Script to take input from StdIn
   1. This is not a perferred solution; similar to how dbl behaves dump a user into a CLI that takes in input for scripts to process.
   2. This introduces complexity when attempting to automate/wrap this process and is not recommended.

Our current solution is to individually script each file; this is time consuming and inefficent, however due to limitations in Logging and complexity involved in the chunking process, it was the path of least resistance.