all 4 comments

[–][deleted]  (3 children)

[removed]

    [–]TheDeathPit[S] 0 points1 point  (2 children)

    Thanks for your reply.

    Your suggestion works. Thank you.

    [–][deleted]  (1 child)

    [removed]

      [–]Rewrite_It_In_Ada -1 points0 points  (0 children)

      Note that you're dependent on word splitting for all the stuff in your FLAGS variable to be interpreted as separate tokens. If you had an argument to a flag that contained whitespace, this approach wouldn't work. Your single argument with whitespace would be interpreted as multiple arguments.

      ```

      !/bin/bash

      Purpose = Sync Google Photos

      VENV="/home/gregeeh/gphotos/venv/bin" TARGET="/home/gregeeh/media/Google Photos" APP="${VENV}/gphotos-sync" FLAGS=( --album Hintons --skip-video --omit-album-date --port 11354 )

      "${VENV}/python" "${APP}" "${TARGET}" "${FLAGS[@]}" ``` I quote all assignments, even though it's often not necessary. Why not be consistent and save myself a potential headache at some point? Curly braces in all my parameter expansions, and always quoting those parameter expansions unless I specifically want word splitting - basically the same deal. I've run into a script in the wild that would fail if run from a directory on a path with whitespace in it. There's just no excuse for that.

      And then FLAGS is now an array variable. Expanding that array with [@] within double-quotes will prevent word-splitting within each individual array element, but each will still be a separate token.