Matthew DeVore <matvore@xxxxxxxxxx> writes: > Yes, it's probably better to add a point about that. Here is the new > documentation after applying your suggestions: > > - If a piped sequence which spans multiple lines, put each statement > on a separate line and put pipes on the end of each line, rather > than the start. This means you don't need to use \ to join lines, > since | implies a join already. > > (incorrect) > grep blob verify_pack_result \ > | awk -f print_1.awk \ > | sort >actual && > ... > > (correct) > grep blob verify_pack_result | > awk -f print_1.awk | > sort >actual && > ... The formatting advice to place '|' at the end applies equally to '&&' and '||' because these three syntactic elements share exactly the same trait: the shell knows you haven't finished speaking when it sees them at the end of the line and keeps listening, and humans would know that too, so there is no need for explicitly continuing the line with backslash. Organizationally speaking, I wonder if the above about formatting would better appear separate from the latter two points that are about semantics. > - In a pipe, any exit codes returned by processes besides the last > are ignored. This means that if git crashes at the beginning or > middle of a pipe, it may go undetected. Prefer writing the output > of that command to a temporary file with '>' rather than pipe it. > > - The $(git ...) construct also discards git's exit code, so if the > goal is to test that particular command, redirect its output to a > temporary file rather than wrap it with $( ).
