Tabs are not evil!

[nikolay]

I using tabs, because of the great application in these heredocs:

#!/usr/bin/env bash

main() {
    cat > "message.txt" <<-EOF
        Hello, ${USER}!

        This has no leading whitespace.
        It is also nested in a more readable way.
        All indentation here is with tabs.
    EOF
}

[[ "$0" == "${BASH_SOURCE}" ]] && main "$@"

[progrium]

This is a great find and a great argument for hard tabs. Thank you.

[delitescere]

Wow. Now I have to undo my "turn tabs into 2 spaces" everywhere.

Although, I'm not unhappy with the spaced way either. It is nested in a way that makes it stand out as unusual, in that I most often use heredocs to generate a bash script dynamically (usually executed remotely), so we might have (using 2-space indents):

#!/usr/bin/env bash
main() {
    cat > "dynamic.sh" <<-EOF
#!/usr/bin/env bash

main() {
  echo "Our own indentation level is distinct from the generator."
  echo "Also, watch out for the inception level of interpolation."
  echo "Like '$1' is the generator's first arg, while '\$1' is the generated script's first arg."
}

[[ "$0" == "${BASH_SOURCE}" ]] && main "$@"

EOF

  chmod +x dynamic.sh
  ./dynamic.sh
}

[[ "$0" == "${BASH_SOURCE}" ]] && main "$@"

[progrium]

Good point, I'm "not unhappy" with this either, which I do regularly for nested scripts where you want to keep indenting. Though since Bash doesn't care about indenting it only matters if humans are expected to read generated scripts... which they aren't, they usually read the source they were generated from.

Plus you can still do this when you need while using tabs elsewhere. I don't know. Would love to hear more thoughts.

[nikolay]

I added a variable to showcase why this had to be embedded otherwise it didn't make much sense being a fully-static text.

[nikolay]

@delitescere You had to use <<-"EOF" otherwise variables will be expanded.

[progrium]

@nikolay I think the point got across even without the variable. :)

I also didn't know about that optional variable expansion with heredocs... so you just double quote the boundary string? Can you give a full example?

[nikolay]

cat <<-"EOF"
    $No $Expansion
EOF

[nikolay]

You can also use <<-'EOF'. Of course, all these work without the - as well, but leading tabs are not ignored.

[delitescere]

Awesome, never knew about the quoted boundary string either. 😲

[delitescere]

@progrium totally right, those generated scripts don't need the indentation retained.

[ernstki]

This is an excellent argument for a beneficial use of tabs, and an equally good argument for having your editor's "show whitespace" menu option on speed-dial (:set list if you use Vim).

As for advocating a mix of tabs and spaces, there is a point of diminishing returns, especially if you also spaces for visual alignment of operators and pipelines.

if [[ $doupdate
      && some-really-long-condition-that-doesnt-fit-on-one-line
      && some-other-condition-thats-also-pretty-long ]]; then

    time \
      updatedb --require-visibility 0 \
               --add-prunenames .git \
               --database-root "$BASEPATH" \
               --output "$DB"

fi

Granted, that's probably a fairly unusual coding style and the text editor I use makes it trivial to maintain such code (whereas other editors might not). But Bash script doesn't have to be ugly, or hard to read. Unless that's your
plan for ensuring you have job security. ;)

The spaces-vs-tabs thing has to be a choice you make for yourself, or agree upon with your team. It will always only ever be that.