Passing long argument list to remote script

[Anonymous Monk]

Monks,

I am writing scripts to automate report generation from the database tables.This too has 2 parts. User inputs are collected thru web based UI and inputs are passed to the backend scripts running on a remote server as command line args. Issue is that the use input contains DB Queries which exceed the length supported by shell. I googled for solution but could not find any viable sol. Also looked Getopt::Argvfile but could not find out the best possible method.

Thinking of putting the options in a file; copy that to remote server, make the remote script read the input from the file. BUt not sure if it is the right approach. Can any monks help with the best advice that helps me resolving the issue.

Regards and thanks.

[roboticus]

Using a file can certainly work, but I'd suggest creating a table on the database (e.g. report_queue), and let the web server add reports to the queue, and let the back end server pull off requests and execute them. The advantage is that both machines (presumably) already have access to the database server, so you don't need an additional hole in your firewall for some file sharing scheme. (Though, now that I think of it, you could publish your files in a separate server root, and let the back end server fetch them via http. Just a random thought.)

...roboticus

When your only tool is a hammer, all problems look like your thumb.

[sundialsvc4]

/me nods...

That certainly seems to me to be the most flexible approach, since you can as always be certain that changes to exactly what needs to be run will happen forevermore.   (“The only universal constant is change.”)   Whether you get the list of commands from a database table, or from a file that is supplied separately, you certainly do not want to be confined by the arbitrary size of some command-buffer.

[JavaFan]

Have you tried putting the options in a file, and copying that the remote server? Did it work? If so, why shouldn't it be a right approach?

If it doesn't work, why doesn't it work? Then it means there are restrictions in one form or another. But if we don't know what those restrictions are, we can't find a "right approach".

[salva]

Another option is to pass the inputs to the backend scripts through their stdin streams.

How do you intend to run those scripts?