Return to Answer

For efficiency, you can do it without calling any tools like sed:

output=$(git status); echo " ${output//$'\n'/$'\n' }." 

Or, in a function:

indent() { local unindented unindented="$(< /dev/stdin)" echo " ${unindented//$'\n'/$'\n' }." } git status | indent 

How it works: Bash parameter expansion replaces every "end of line" to "end of line" + . The first line is not preceded by "end of line", so we prepend to the whole string.

This saves the time to start the whole sed/etc process.

Like most solutions, tabs in the original output, which may look like 8 spaces, are simply prepended with 2 spaces, and the tabs shrinks, and thus it still looks like idented with 8 spaces. This might be desired or not.

Edit: About "efficiency":

On my system, my solution is faster than all sed solutions at 50 lines and gets slower at ~100 lines of git status output. It all depends on the use case: If you want to edit files with 100s of lines, use sed. If you have smaller input and runtime matters (like in a bash completion script), use parameter expansion.

You can do it without calling any tools like sed:

output=$(git status); echo " ${output//$'\n'/$'\n' }." 

Or, in a function:

indent() { local unindented unindented="$(< /dev/stdin)" echo " ${unindented//$'\n'/$'\n' }." } git status | indent 

How it works: Bash parameter expansion replaces every "end of line" to "end of line" + . The first line is not preceded by "end of line", so we prepend to the whole string.

Like most solutions, tabs in the original output, which may look like 8 spaces, are simply prepended with 2 spaces, and the tabs shrinks, and thus it still looks like indented with 8 spaces. This might be desired or not.

Edit: About efficiency:

On my system, my solution is faster than all sed solutions at 50 lines and gets slower at ~100 lines of git status output. CervEd (see comments) has made tests where my solution already starts being slower at ~30 lines after 9999 repetitions. What you want to use depends a lot on the use case: If your input can get large or you need to be POSIX conform, I would use sed. If your input is known to be small or you do not even have sed, I would use this solution.

For efficiency, you can do it without calling any tools like sed:

output=$(git status); echo " ${output//$'\n'/$'\n' }." 

Or, in a function:

indent() { local unindented unindented="$(< /dev/stdin)" echo " ${unindented//$'\n'/$'\n' }." } git status | indent 

How it works: Bash parameter expansion replaces every "end of line" to "end of line" + . The first line is not preceded by "end of line", so we prepend to the whole string.

This saves the time to start the whole sed/etc process (though, in this case, where the output is not yet in a variable, it might cost more time to allocate the variable, if the text is bigger than your sed binary).

Like most solutions, tabs in the original output, which may look like 8 spaces, are simply prepended with 2 spaces, and the tabs shrinks, and thus it still looks like idented with 8 spaces. This might be desired or not.

Edit: About "efficiency":

On my system, my solution is faster than all sed solutions at 50 lines and gets slower at ~100 lines of git status output. It all depends on the use case: If you want to edit files with 100s of lines, use sed. If you have smaller input and runtime matters (like in a bash completion script), use parameter expansion.

For efficiency, you can do it without calling any tools like sed:

output=$(git status); echo " ${output//$'\n'/$'\n' }." 

Or, in a function:

indent() { local unindented unindented="$(< /dev/stdin)" echo " ${unindented//$'\n'/$'\n' }." } git status | indent 

How it works: Bash parameter expansion replaces every "end of line" to "end of line" + . The first line is not preceded by "end of line", so we prepend to the whole string.

This saves the time to start the whole sed/etc process.

Like most solutions, tabs in the original output, which may look like 8 spaces, are simply prepended with 2 spaces, and the tabs shrinks, and thus it still looks like idented with 8 spaces. This might be desired or not.

Edit: About "efficiency":

On my system, my solution is faster than all sed solutions at 50 lines and gets slower at ~100 lines of git status output. It all depends on the use case: If you want to edit files with 100s of lines, use sed. If you have smaller input and runtime matters (like in a bash completion script), use parameter expansion.

For efficiency, you can do it without calling any tools like sed:

output=$(git status); echo " ${output//$'\n'/$'\n' }." 

Or, in a function:

indent() { local unindented unindented="$(< /dev/stdin)" echo " ${unindented//$'\n'/$'\n' }." } git status | indent 

How it works: Bash parameter expansion replaces every "end of line" to "end of line" + . The first line is not preceded by "end of line", so we prepend to the whole string.

This saves the time to start the whole sed/etc process (though, in this case, where the output is not yet in a variable, it might cost more time to allocate the variable, if the text is bigger than your sed binary).

Like most solutions, tabs in the original output, which may look like 8 spaces, are simply prepended with 2 spaces, and the tabs shrinks, and thus it still looks like idented with 8 spaces. This might be desired or not.

Edit: About "efficiency":

On my system, my solution is faster than all sed solutions at 50 lines and gets slower at ~100 lines of git status output. It all depends on the use case: If you want to edit files with 100s of lines, use sed. If you have smaller input and runtime matters (like in a bash completion script), use pattern expansion.

For efficiency, you can do it without calling any tools like sed:

output=$(git status); echo " ${output//$'\n'/$'\n' }." 

Or, in a function:

indent() { local unindented unindented="$(< /dev/stdin)" echo " ${unindented//$'\n'/$'\n' }." } git status | indent 

How it works: Bash parameter expansion replaces every "end of line" to "end of line" + . The first line is not preceded by "end of line", so we prepend to the whole string.

This saves the time to start the whole sed/etc process (though, in this case, where the output is not yet in a variable, it might cost more time to allocate the variable, if the text is bigger than your sed binary).

Like most solutions, tabs in the original output, which may look like 8 spaces, are simply prepended with 2 spaces, and the tabs shrinks, and thus it still looks like idented with 8 spaces. This might be desired or not.

Edit: About "efficiency":

On my system, my solution is faster than all sed solutions at 50 lines and gets slower at ~100 lines of git status output. It all depends on the use case: If you want to edit files with 100s of lines, use sed. If you have smaller input and runtime matters (like in a bash completion script), use parameter expansion.