I have the following scenario.

I have a Perl script that takes an ID and looks up some arguments from a DB. lets say look_up_args.pl 234 prints the following abc 123 "something with spaces"

I have another shell script script.sh that does the following

some_command --param1 $1 --param2 $2 --par3 "$3" ...

what I am trying to do is to call the script with the arguments

I have tried the following 2 methods

./script.sh `./look_up_args.pl 234`
./script.sh $(./look_up_args.pl 234)

still whenever I run the script.sh, $3 seems to contain only "something" causing my script to fail. I am looking for away to pass the quoted string with out any form of shell expansion/etc... The third parameter may contain other special bash characters, but will always be quoted.

  • 1
    To avoid the comedy of errors that is posix shell word splitting, another option might be (the comedy of errors that is) JSON or something via standard I/O lookupargs 234 | thenextthing
    – thrig
    Nov 10 '16 at 19:02
  • While this is probably a better way of doing this. Its just seems overly complex for a simple problem. All I am trying to do is to run a command with some arguments stored in a database.
    – Smartelf
    Nov 10 '16 at 19:23

I wouldn't recommend this, but try:

eval "./script.sh $(./look_up_args.pl 234)"

This should work, but keep in mind that eval will evaluate whatever look_up_args.pl happens to output, meaning you leave yourself vulnerable to code injection.

A better option would be what @thrig suggested in the comments: use a standardized data format to pass data between tools. Even a newline-delimited string would be a fine format for a shell-style processing pipeline.

  • Thanks, eval seems to have done the trick. This isn't production code, so I can live with the security risk. Still there should be a way to just escape the arguments somehow.
    – Smartelf
    Nov 10 '16 at 19:20
  • Assuming you control the output of look_up_args.pl, it's not so much a security risk as it is a stability risk. Unexpected and unpredictable behavior is the major concern.
    – jayhendren
    Nov 10 '16 at 19:22
  • Yeh, I understand that. I was just hoping not to have to change script.sh since I already call that from elsewhere. I can modify the Perl script anyway I want thought.
    – Smartelf
    Nov 10 '16 at 19:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.