1

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.

2
  • 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, 2016 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, 2016 at 19:23

1 Answer 1

Reset to default
1

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.

3
  • 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, 2016 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, 2016 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, 2016 at 19:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .