Re: Splitting search results from a "find -print0"

[Bernhard Voelker]

On 01/10/2015 07:24 PM, Pádraig Brady wrote:
> On 10/01/15 16:58, Bernhard Voelker wrote:
>> ...interestingly, such syntax failure wouldn't have shown up in the test 
>> result:
>>
>>   + return 1
>>   ./tests/split/lines-sep.sh: line ??: return: can only `return' from a 
>> function or sourced script
> 
> Yep, I think only `set -e` would catch that, but adding that
> to setup_() in tests/init.sh give lots of failures:
> 
> ============================================================================
> Testsuite summary for GNU coreutils 8.23.95-8c819
> ============================================================================
> # TOTAL: 572
> # PASS:  376
> # SKIP:  101

I have only 100 skipped ;-)

> # XFAIL: 0
> # FAIL:  95
> # XPASS: 0
> # ERROR: 0
> 
> Something to consider enabling shen developing new tests at least.

yes, it seems a bit hard to fix all tests to work with "set -e", e.g.
tests like tests/misc/env.sh provoking an error

   # These tests verify exact status of internal failure.
  env --- # unknown option
  test $? = 125 || fail=1

would have to be written something like such awkward thing:

  if env --- ; then fail=1; else test $? = 125 || fail=1 ; fi

OTOH this could easily be wrapped:

  assertRc 125 env ---

>> ... last question: shouldn't "split --bytes=123 --separator=X"
>> return an error like "uncompatible options"?
> 
> I did think about that.  They're not incompatible, just that --separator
> is ignored in that case.  There are many undiagnosed cases of that,
> and some with warnings issued:
> 
> $ git grep error.*ignored
> src/install.c:    error (0, 0, _("the --compare (-C) option is ignored when 
> you"
> src/numfmt.c:        error (0, 0, _("--header ignored with command-line 
> input"));
> src/sort.c:        error (0, 0, _("key %lu has zero width and will be 
> ignored"), keynum);
> src/tail.c:          error (0, 0, _("warning: --retry ignored; --retry is 
> useful"
> 
> I didn't think a warning was warranted in this case.
> Something to consider if we add --debug to more utils.

I agree.

Thanks & have a nice day,
Berny