Note that there are some explanatory texts on larger screens.

plurals
  1. POParameter list with double quotes does not pass through properly in Bash
    text
    copied!<p>I have a Bash script that calls another Bash script. The called script does some modification and checking on a few things, shifts, and then passes the rest of the caller's command line through.</p> <p>In the called script, I have verified that I have everything managed and ready to call. Here's some debug-style code I've put in:</p> <pre><code>echo $SVN $command $@ &gt; /tmp/shimcmd bash /tmp/shimcmd $SVN $command $@ </code></pre> <p>Now, in /tmp/shimcmd you'll see:</p> <pre><code>svn commit --username=myuser --password=mypass --non-interactive --trust-server-cert -m "Auto Update autocommit Wed Apr 11 17:33:37 CDT 2012" </code></pre> <p>That is, the built command, all on one line, perfectly fine, including a -m "my string with spaces" portion.</p> <p>It's perfect. And the "bash /tmp/shimcmd" execution of it works perfectly as well.</p> <p>But of course I don't want this silly tmp file and such (only used it to debug). The problem is that calling the command directly, instead of via the shim file:</p> <pre><code>$SVN $command $@ </code></pre> <p>results in the svn command itself NOT receiving the quoted string with spaces--it garbles the '-m "my string with spaces"' parameter and shanks the command as if it was passed as '-m my string with spaces'.</p> <p>I have tried all manner of crazy escape methods to no avail. Can't believe it's dogging me this badly. Again, by echoing the very same thing ($SVN $command $@) to a file and then executing that file, it's FINE. But calling directly garbles the quoted string. That element alone shanks.</p> <p>Any ideas?</p> <p>Dan</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload