With lines.txt:

  printf '(%s)\n' "one two" "three four five"
  echo "How you doin'?"

Running:

  while read -r line; do
    eval command=($line)
    command+=("arg with spaces" "other arg")
    "${command[@]}"
  done < lines.txt

Yields

  (one two)
  (three four five)
  (arg with spaces)
  (other arg)
  How you doin'? arg with spaces other arg

Bash handles spaces just fine.

  # store the command in an array
  X=(echo "A B")
  # execute the command
  "${X[@]}"

Yields:

  A B

Meanwhile, UPS's web site has mostly gone down. Their home page now reads "Sorry! We Can’t Find That Page. Looks like the page you’re trying to find may have been moved or deleted."

Handling command-line arguments in Bash is easy. Bash's `getopts` handles short and long arguments gnu-style without any problem, out of the box, without any need for libraries or complicated packages.

This pattern handles lots of styles of options: short and long options (-h, --help), `--` for separating options from positional args, with GNU-style long options (--output-file=$filename).

  while getopts :o:h-: option
  do case $option in
         h ) print_help;;
         o ) output_file=$OPTARG;;
         - ) case $OPTARG in
                 help ) print_help;;
                 output-file=* ) output_file=${OPTARG##*=};;
                 * ) echo "bad option $OPTARG" >&2; exit 1;;
             esac;;
         '?' ) echo "unknown option: $OPTARG" >&2; exit 1;;
         : ) echo "option missing argument: $OPTARG" >&2; exit 1;;
         * ) echo "bad state in getopts" >&2; exit 1;;
     esac
  done
  shift $((OPTIND-1))
  (( $# > 0 )) && printf 'remaining arg: %s\n' "$@"

The video in the linked page mentions this.

The video in the linked page says that getopts only supports short options.

>I don't know where you learned shell scripting, but your formatting is very confusing

i don't know where you learned English composition, but I can't follow your critique. are you pointing out your preferences (which may well match gnu or bsd standards, i don't know tell me) or things that actually make a difference? Did he break emacs auto-indent? Are you pointing out all the flaws or the correct ways, i'm having to eyeball diff. Use more of your words.

    while
    do

doesn't seem substantially worse/confusing compared to while;do unless you have some reason?

spacing out ;; does it make a difference? or do you like things spaced out?

etc.

I thought it was "professional", helpful, and a great comment. I didn't think yours was constructive, just unhelpfully treating a different formatting style as objectively worse, in an unfriendly way. "Be kind"! It was also hard to parse, as the GP pointed out.

edit: You changed your comment after I wrote this. Now it mentions that you flagged the GP. That's ridiculous.

You have way too much time on your hands and seem determined to argue nonconstructively. Have a good one.

> You have way too much time on your hands and seem determined to argue nonconstructively. Have a good one.

Please refresh on the HN comment guidelines. And reconsider who has been "constructive" vs "nonconstructive" in this thread.

If you refer to my example above, you'll find that Bash's native "getopts" handles long options just fine. It accepts short option `-`, with an argument. This handles --long-options and --long-options=with-arguments.

Feel free to use your own formatting preferences.

It turns out they are very similar to binary loadlifters in most respects.

You're thinking of vaporators. Binary loadlifters are heavy-lifting droids, though the binary programming language of those droids was quite similar to that of moisture vaporators. Maybe that's what you meant.

Bash `getopts` handles short and long arguments gnu-style without any problem. The following code handles args like "-h", "-i $input-file", "-i$input-file", "--in=$input-file", and "--help":

  while getopts :i:h-: option
  do case $option in
         # accept -i $input-file, -i$input-file
         i ) input_file=$OPTARG;;
         h ) print_help;;
         - ) case $OPTARG in
                 help ) print_help;;
                 help=* ) echo "Option has unexpected argument: ${OPTARG%%=*}" >&2; exit 1;;
                 in=* ) input_file=${OPTARG##*=};;
                 in ) echo "Option missing argument: $OPTARG" >&2; exit 1;;
                 * ) echo "Bad option $OPTARG" >&2; exit 1;;
             esac;;
         '?' ) echo "Unknown option $OPTARG" >&2; exit 1;;
         : ) echo "Option missing argument: $OPTARG" >&2; exit 1;;
         * ) echo "Bad state in getopts" >&2; exit 1;;
     esac
  done
  shift $((OPTIND-1))

Like @bxparks, I have a template for my bash scripts command-line parsing, but I like to stick to GNU-style options and I find that Bash's getopts command handles all these cases without trouble:

command -ffilename -f filename --file=filename -- -f is not an option

My template is at https://gist.github.com/webb/ff380b0eee96dafe1c20c2a136d85ef....

Using `-:` to build long-options on top of the short-option-only `getopts` builtin is a great hack.

Thanks!

It would not be difficult. Nuclear reactors could provide power almost indefinitely. Greenhouses could maintain plant life. Animals could be bred and slaughtered. A quick survey would have to be made of all the suitable mine sites in the country, but I shouldn't be surprised if several hundred thousand of our people could be accommodated. Every nation would undoubtedly follow suit.

I use GraphViz to produce a visual, browsable version of the NIEM data model. GraphViz can output images and HTML maps, which allows easy building of clickable web pages with hover notes.

See the diagram at https://niem.github.io/model/4.2/nc/ItemType/ . Hover over a term to see its definition. Click on a term to navigate to its diagram.

My go-to would be tar:

`$ tar -C $source-dir -c . | tar -C $dest-dir -x`