Subject: Re: [PATCH 2/2] t6402: check exit status of ls-files

From: Đoàn Trần Công Danh <[email-masked]>
Date: Thu, 22 Apr 2021 20:49:04 +0700

On 2021-04-21 16:32:40-0700, Junio C Hamano <[email-masked]> wrote:
> Eric Sunshine <[email-masked]> writes:
> 
> > On Wed, Apr 21, 2021 at 12:55 PM Eric Sunshine <[email-masked]> wrote:
> >>     count_ls_files 5 -s &&
> >>     count_ls_files 3 -u &&
> >>     count_ls_files 1 -u one~HEAD &&
> >>     ...
> >>
> >> The nice thing about having a helper function is that it can clean up
> >> after itself by not leaving a new file lying around, thus you wouldn't
> >> have to make adjustments to the expected number of untracked files (as
> >> mentioned in the commit message). If this is the sort of thing which
> >> comes up often enough (if there are more such cases beyond the two
> >> scripts you changed in this series), then it might make sense to
> >> promote the helper function to test-lib-functions.sh.
> >
> > The frequency with which this idiom crops up with commands beyond
> > git-ls-files suggests the more general solution of supporting it
> > directly in test-lib-functions.sh for any command. For instance:
> >
> >     test_cmd_line_count = 3 git ls-files -u &&
> >
> > Or, perhaps, a new mode of test_line_count():
> >
> >     test_line_count = 3 -c git ls-files -u &&

Hm, I'm not sure how would we implement such mode:

* Will we run such command in a subprocess and and pipe to "wc -l"
  directly to avoid a temporary file, but we will lose the exit code
  of running command in process?
* Will we run in a separated chain? Thus, a temporary file would be
  created, skimming over test-lib-functions.sh, I couldn't find any
  convention for creating such files, except for specific use cases,
  let's say "*.config".
* Another clever hacks that I don't know *shrug*

> 
> That looks nice on paper, but may be going too far.
> 
> We may want to count the lines in the error message,

Let's assume that we solve above puzzle.

Count the lines in the error messages is not too hard to be imagined,
let's say by -c2 or something like that.

> or we may want
> to count the lines after filtering the output with pipe.

However, when it involved a pipe, things becomes complicated.

> A test file that is dedicated to test ls-files with a file local
> helper "count_ls_files" smells like a better place to stop, at least
> to me.

Hence, I'll stick with local help "count_ls_files" for now.

-- 
Danh