GNU bug report logs - #72536
[PATCH] tap: new `--merge-prefix' option to prefix stderr before merging

Previous Next

Package: automake-patches;

Reported by: Richard Hansen <rhansen <at> rhansen.org>

Date: Fri, 9 Aug 2024 08:40:01 UTC

Severity: normal

Tags: patch

Done: Karl Berry <karl <at> freefriends.org>

Bug is archived. No further changes may be made.

Full log


Message #17 received at 72536 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: rhansen <at> rhansen.org
Cc: 72536 <at> debbugs.gnu.org, jcb62281 <at> gmail.com
Subject: Re: [bug#72536] [PATCH] tap: new `--merge-prefix' option to prefix
 stderr before merging
Date: Sat, 10 Aug 2024 15:52:55 -0600
    How about `--stderr-prefix`?  
    ...
    I could make this option independent of `--merge` and always prefix each 
    line of the test script's stderr.

Sounds sensible to me. Clear behavior is good. I like that better than
implicitly turning on --merge.

    I wonder if this should have a default prefix so that users 
    don't have to figure out how to pass `#`. 

Hmm.

       * `--stderr-prefix` by itself to prefix with the default of `# `

I haven't studied this, but I wonder about "#stderr# " as the default.
Maybe that's too verbose in practice.

       * `--stderr-prefix custom-prefix` to prefix with `custom-prefix`
    This would be a bit more complicated to implement because the script 
    would need a heuristic to determine whether the user passed a custom 
    prefix or not (such as, "there is an argument after `--stderr-prefix` 
    and that argument does not begin with `-`").

Optional argument heuristics don't sound ideal to me. tap-driver.sh
takes its final non-option argument, so if the new option ended up last,
there would be:
 tap-driver.sh ... --stderr-prefix TEST-COMMAND
and nothing good would result. There's also the question of what to do
if the possibly-optional argument was "--". Let's just not go there.

Instead, as a nod to practicality aka kludge, I wonder about replacing
the string "sharp" (or "octothorpe", or some such) in the argument with a #.

    difficult to portably add a `#` character to a 
    make variable, as you can see in the test I added.  

Perusing your patch again, I see you used
    printf %03o
to get around that. I hope that's portable in practice.

I wonder if automake actually works under EBCDIC. I wouldn't be
surprised if ASCII is assumed more or less throughout. Anyway, nice
defensive thinking there. :)

    p.s. I requested a copyright assignment form.

Thanks much for all.




This bug report was last modified 95 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.