Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes:
> I was curious if the project has a preference between `uniq filename`
> and `uniq <filename`, but apparently we haven't:
>
> % git grep 'uniq <' -- t | wc -l
> 2
> git grep 'uniq [a-z0-9]' -- t | wc -l
> 2
>
> Though there does seem to be a global preference in the project to
> specify the filename directly to the command rather than redirecting
> from stdin. For instance:
>
> % git grep 'sort <' -- t | wc -l
> 54
> % git grep 'sort [a-z0-9]' -- t | wc -l
> 140
Have you inspected the hits from these grep runs?
$ git grep -c 'sort [a-z0-9]' -- t/t7004-tag.sh
t/t7004-tag.sh:17
Among 17 of them, 15 are on test titles.
$ git grep -c '^test_expect_[sf].*sort [a-z0-9]' -- t/t7004-tag.sh
t/t7004-tag.sh:15
So the above numbers are totally unreliable as a guide, I am afraid.
It is probably better to use sort/uniq without input redirection
because your
$ sort/uniq input >output
can be easily extended to
$ sort/uniq input-a input-b input-c >output
but
$ sort/uniq <input >output
cannot be extended the same way, and you'd end up doing nonsense
pipe like this:
$ cat input-a input-b input-c | sort >output
which is a no-no.
In reality, however, we are not all that logical.
$ git grep -e '^[ ]*sort [a-z0-9][-a-z0-9]* ' -- t | wc -l
46
$ git grep -e '^[ ]*sort <' -- t | wc -l
51
with "s/sort/uniq/", the numbers are 0 vs 1.
There are a handful of sort invocations that take their input from
redirected <<HEREDOC included in the latter number, but the overall
picture does not change with them excluded.
