{"thread":{"id":"58973","subject":"[PATCH] tests: make 'test_oid' print trailing newline","startedAt":"2022-12-18T17:34:22Z","lastAt":"2022-12-23T00:56:45Z","messageCount":7,"participants":["SZEDER Gábor","Junio C Hamano","brian m. carlson","Ævar Arnfjörð Bjarmason"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"469253","messageId":"20221218162905.3508164-1-szeder.dev@gmail.com","threadId":"58973","inReplyTo":null,"subject":"[PATCH] tests: make 'test_oid' print trailing newline","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2022-12-18T16:29:05Z","receivedAt":"2022-12-18T17:34:22Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"Unlike other test helper functions, 'test_oid' doesn't terminate its\noutput with a LF, but, alas, the reason for this, if any, is not\nmentioned in 2c02b110da (t: add test functions to translate\nhash-related values, 2018-09-13)).\n\nNow, in the vast majority of cases 'test_oid' is invoked in a command\nsubstitution that is part of a heredoc or supplies an argument to a\ncommand or the value to a variable, and the command substitution would\nchop off any trailing LFs, so in these cases the lack or presence of a\ntrailing LF in its output doesn't matter.  However:\n\n  - There appear to be only three cases where 'test_oid' is not\n    invoked in a command substitution:\n\n      $ git grep '\\stest_oid ' -- ':/t/*.sh'\n      t0000-basic.sh:  test_oid zero >actual &&\n      t0000-basic.sh:  test_oid zero >actual &&\n      t0000-basic.sh:  test_oid zero >actual &&\n\n    These are all in test cases checking that 'test_oid' actually\n    works, and that the size of its output matches the size of the\n    corresponding hash function with conditions like\n\n      test $(wc -c <actual) -eq 40\n\n    In these cases the lack of trailing LF does actually matter,\n    though they could be trivially updated to account for the presence\n    of a trailing LF.\n\n  - There are also a few cases where the lack of trailing LF in\n    'test_oid's output actually hurts, because tests need to compare\n    its output with LF terminated file contents, forcing developers to\n    invoke it as 'echo $(test_oid ...)' to append the missing LF:\n\n      $ git grep 'echo \"\\?$(test_oid ' -- ':/t/*.sh'\n      t1302-repo-version.sh:  echo $(test_oid version) >expect &&\n      t1500-rev-parse.sh:     echo \"$(test_oid algo)\" >expect &&\n      t4044-diff-index-unique-abbrev.sh:      echo \"$(test_oid val1)\" > foo &&\n      t4044-diff-index-unique-abbrev.sh:      echo \"$(test_oid val2)\" > foo &&\n      t5313-pack-bounds-checks.sh:    echo $(test_oid oidfff) >file &&\n\n    And there is yet another similar case in an in-flight topic at:\n\n      https://public-inbox.org/git/813e81a058227bd373cec802e443fcd677042fb4.1670862677.git.gitgitgadget@gmail.com/\n\nArguably we would be better off if 'test_oid' terminated its output\nwith a LF.  So let's update 'test_oid' accordingly, update its tests\nin t0000 to account for the extra character in those size tests, and\nremove the now unnecessary 'echo $(...)' command substitutions around\n'test_oid' invocations as well.\n\nSigned-off-by: SZEDER Gábor <szeder.dev@gmail.com>\n---\n t/t0000-basic.sh                    | 7 ++++---\n t/t1302-repo-version.sh             | 2 +-\n t/t1500-rev-parse.sh                | 2 +-\n t/t4044-diff-index-unique-abbrev.sh | 4 ++--\n t/t5313-pack-bounds-checks.sh       | 2 +-\n t/test-lib-functions.sh             | 2 +-\n 6 files changed, 10 insertions(+), 9 deletions(-)\n\ndiff --git a/t/t0000-basic.sh b/t/t0000-basic.sh\nindex 502b4bcf9e..8ea31d187a 100755\n--- a/t/t0000-basic.sh\n+++ b/t/t0000-basic.sh\n@@ -815,7 +815,8 @@ test_expect_success 'test_oid provides sane info by default' '\n \tgrep \"^00*\\$\" actual &&\n \trawsz=\"$(test_oid rawsz)\" &&\n \thexsz=\"$(test_oid hexsz)\" &&\n-\ttest \"$hexsz\" -eq $(wc -c <actual) &&\n+\t# +1 accounts for the trailing newline\n+\ttest $(( $hexsz + 1)) -eq $(wc -c <actual) &&\n \ttest $(( $rawsz * 2)) -eq \"$hexsz\"\n '\n \n@@ -826,7 +827,7 @@ test_expect_success 'test_oid can look up data for SHA-1' '\n \tgrep \"^00*\\$\" actual &&\n \trawsz=\"$(test_oid rawsz)\" &&\n \thexsz=\"$(test_oid hexsz)\" &&\n-\ttest $(wc -c <actual) -eq 40 &&\n+\ttest $(wc -c <actual) -eq 41 &&\n \ttest \"$rawsz\" -eq 20 &&\n \ttest \"$hexsz\" -eq 40\n '\n@@ -838,7 +839,7 @@ test_expect_success 'test_oid can look up data for SHA-256' '\n \tgrep \"^00*\\$\" actual &&\n \trawsz=\"$(test_oid rawsz)\" &&\n \thexsz=\"$(test_oid hexsz)\" &&\n-\ttest $(wc -c <actual) -eq 64 &&\n+\ttest $(wc -c <actual) -eq 65 &&\n \ttest \"$rawsz\" -eq 32 &&\n \ttest \"$hexsz\" -eq 64\n '\ndiff --git a/t/t1302-repo-version.sh b/t/t1302-repo-version.sh\nindex 0acabb6d11..7cf80bf66a 100755\n--- a/t/t1302-repo-version.sh\n+++ b/t/t1302-repo-version.sh\n@@ -27,7 +27,7 @@ test_expect_success 'setup' '\n '\n \n test_expect_success 'gitdir selection on normal repos' '\n-\techo $(test_oid version) >expect &&\n+\ttest_oid version >expect &&\n \tgit config core.repositoryformatversion >actual &&\n \tgit -C test config core.repositoryformatversion >actual2 &&\n \ttest_cmp expect actual &&\ndiff --git a/t/t1500-rev-parse.sh b/t/t1500-rev-parse.sh\nindex 81de584ea2..37ee5091b5 100755\n--- a/t/t1500-rev-parse.sh\n+++ b/t/t1500-rev-parse.sh\n@@ -195,7 +195,7 @@ test_expect_success 'rev-parse --is-shallow-repository in non-shallow repo' '\n '\n \n test_expect_success 'rev-parse --show-object-format in repo' '\n-\techo \"$(test_oid algo)\" >expect &&\n+\ttest_oid algo >expect &&\n \tgit rev-parse --show-object-format >actual &&\n \ttest_cmp expect actual &&\n \tgit rev-parse --show-object-format=storage >actual &&\ndiff --git a/t/t4044-diff-index-unique-abbrev.sh b/t/t4044-diff-index-unique-abbrev.sh\nindex 29e49d2290..9f6043daba 100755\n--- a/t/t4044-diff-index-unique-abbrev.sh\n+++ b/t/t4044-diff-index-unique-abbrev.sh\n@@ -34,12 +34,12 @@ test_expect_success 'setup' '\n \t100644 blob $(test_oid hash2)\tfoo\n \tEOF\n \n-\techo \"$(test_oid val1)\" > foo &&\n+\ttest_oid val1 > foo &&\n \tgit add foo &&\n \tgit commit -m \"initial\" &&\n \tgit cat-file -p HEAD: > actual &&\n \ttest_cmp expect_initial actual &&\n-\techo \"$(test_oid val2)\" > foo &&\n+\ttest_oid val2 > foo &&\n \tgit commit -a -m \"update\" &&\n \tgit cat-file -p HEAD: > actual &&\n \ttest_cmp expect_update actual\ndiff --git a/t/t5313-pack-bounds-checks.sh b/t/t5313-pack-bounds-checks.sh\nindex cc4cfaa9d3..ceaa6700a2 100755\n--- a/t/t5313-pack-bounds-checks.sh\n+++ b/t/t5313-pack-bounds-checks.sh\n@@ -59,7 +59,7 @@ test_expect_success 'setup' '\n test_expect_success 'set up base packfile and variables' '\n \t# the hash of this content starts with ff, which\n \t# makes some later computations much simpler\n-\techo $(test_oid oidfff) >file &&\n+\ttest_oid oidfff >file &&\n \tgit add file &&\n \tgit commit -m base &&\n \tgit repack -ad &&\ndiff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh\nindex 796093a7b3..f51b97663f 100644\n--- a/t/test-lib-functions.sh\n+++ b/t/test-lib-functions.sh\n@@ -1682,7 +1682,7 @@ test_oid () {\n \tthen\n \t\tBUG \"undefined key '$1'\"\n \tfi &&\n-\teval \"printf '%s' \\\"\\${$var}\\\"\"\n+\teval \"printf '%s\\n' \\\"\\${$var}\\\"\"\n }\n \n # Insert a slash into an object ID so it can be used to reference a location\n-- \n2.39.0.269.g5ff869c7c0\n\n"},{"id":"469255","messageId":"xmqqy1r4usjy.fsf@gitster.g","threadId":"58973","inReplyTo":"20221218162905.3508164-1-szeder.dev@gmail.com","subject":"Re: [PATCH] tests: make 'test_oid' print trailing newline","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-12-19T00:48:49Z","receivedAt":"2022-12-19T00:48:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"SZEDER Gábor <szeder.dev@gmail.com> writes:\n\n> Unlike other test helper functions, 'test_oid' doesn't terminate its\n> output with a LF, but, alas, the reason for this, if any, is not\n> mentioned in 2c02b110da (t: add test functions to translate\n> hash-related values, 2018-09-13)).\n\nI (obviously) agree with the analysis in the proposed log message.\nHaving to touch the sanity checking tests in 0-basic is a bit\nannoying, but having to do an artificial echo is even more annoying,\nso these changes may probably be a net win, I would say.\n\nHaving said that.\n\n>       $ git grep '\\stest_oid ' -- ':/t/*.sh'\n>       $ git grep 'echo \"\\?$(test_oid ' -- ':/t/*.sh'\n\nI found these examples in the log message a bit annoying to see, as\nboth invite an undefined behaviour by having an ordinary character\n('s' or '?')  preceded by an unescaped backslash in a POSIXly\ncorrect implementation of BRE.  GNU libc seems to be OK with it (I\ndouble checked by adding \"-G\" on the command line to make sure my\nexperiments are not affected by any grep.patterntype), but they may\nfail for folks on stricter platforms.\n\nThanks.  Will queue.\n"},{"id":"469285","messageId":"Y6BvKdWJIHKq7GMs@tapette.crustytoothpaste.net","threadId":"58973","inReplyTo":"20221218162905.3508164-1-szeder.dev@gmail.com","subject":"Re: [PATCH] tests: make 'test_oid' print trailing newline","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-12-19T14:03:21Z","receivedAt":"2022-12-19T14:03:32Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2022-12-18 at 16:29:05, SZEDER Gábor wrote:\n> Arguably we would be better off if 'test_oid' terminated its output\n> with a LF.  So let's update 'test_oid' accordingly, update its tests\n> in t0000 to account for the extra character in those size tests, and\n> remove the now unnecessary 'echo $(...)' command substitutions around\n> 'test_oid' invocations as well.\n\nI don't recall that there was a particular reason for me to do it the\nway that it was, and if the commit message doesn't mention it, I think\nit's fine to replace it.  Perhaps I intended to allow writing the binary\nform as well as the text form, in which case a newline would be\nundesirable, but I simply don't recall.\n\nAll that to say, I think this patch is fine as it stands.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"469297","messageId":"221219.864jtrz9yf.gmgdl@evledraar.gmail.com","threadId":"58973","inReplyTo":"20221218162905.3508164-1-szeder.dev@gmail.com","subject":"Re: [PATCH] tests: make 'test_oid' print trailing newline","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-12-19T15:27:12Z","receivedAt":"2022-12-19T15:32:00Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sun, Dec 18 2022, SZEDER Gábor wrote:\n\n> Unlike other test helper functions, 'test_oid' doesn't terminate its\n> output with a LF, but, alas, the reason for this, if any, is not\n> mentioned in 2c02b110da (t: add test functions to translate\n> hash-related values, 2018-09-13)).\n>\n> Now, in the vast majority of cases 'test_oid' is invoked in a command\n> substitution that is part of a heredoc or supplies an argument to a\n> command or the value to a variable, and the command substitution would\n> chop off any trailing LFs, so in these cases the lack or presence of a\n> trailing LF in its output doesn't matter.  However:\n>\n>   - There appear to be only three cases where 'test_oid' is not\n>     invoked in a command substitution:\n>\n>       $ git grep '\\stest_oid ' -- ':/t/*.sh'\n>       t0000-basic.sh:  test_oid zero >actual &&\n>       t0000-basic.sh:  test_oid zero >actual &&\n>       t0000-basic.sh:  test_oid zero >actual &&\n>\n>     These are all in test cases checking that 'test_oid' actually\n>     works, and that the size of its output matches the size of the\n>     corresponding hash function with conditions like\n>\n>       test $(wc -c <actual) -eq 40\n>\n>     In these cases the lack of trailing LF does actually matter,\n>     though they could be trivially updated to account for the presence\n>     of a trailing LF.\n>\n>   - There are also a few cases where the lack of trailing LF in\n>     'test_oid's output actually hurts, because tests need to compare\n>     its output with LF terminated file contents, forcing developers to\n>     invoke it as 'echo $(test_oid ...)' to append the missing LF:\n>\n>       $ git grep 'echo \"\\?$(test_oid ' -- ':/t/*.sh'\n>       t1302-repo-version.sh:  echo $(test_oid version) >expect &&\n>       t1500-rev-parse.sh:     echo \"$(test_oid algo)\" >expect &&\n>       t4044-diff-index-unique-abbrev.sh:      echo \"$(test_oid val1)\" > foo &&\n>       t4044-diff-index-unique-abbrev.sh:      echo \"$(test_oid val2)\" > foo &&\n>       t5313-pack-bounds-checks.sh:    echo $(test_oid oidfff) >file &&\n>\n>     And there is yet another similar case in an in-flight topic at:\n>\n>       https://public-inbox.org/git/813e81a058227bd373cec802e443fcd677042fb4.1670862677.git.gitgitgadget@gmail.com/\n>\n> Arguably we would be better off if 'test_oid' terminated its output\n> with a LF.  So let's update 'test_oid' accordingly, update its tests\n> in t0000 to account for the extra character in those size tests, and\n> remove the now unnecessary 'echo $(...)' command substitutions around\n> 'test_oid' invocations as well.\n\nI'm inclined to like this, as it certainly makes some examples better,\nbut e.g. here:\n\n> @@ -826,7 +827,7 @@ test_expect_success 'test_oid can look up data for SHA-1' '\n>  \tgrep \"^00*\\$\" actual &&\n>  \trawsz=\"$(test_oid rawsz)\" &&\n>  \thexsz=\"$(test_oid hexsz)\" &&\n> -\ttest $(wc -c <actual) -eq 40 &&\n> +\ttest $(wc -c <actual) -eq 41 &&\n>  \ttest \"$rawsz\" -eq 20 &&\n>  \ttest \"$hexsz\" -eq 40\n> [...]\n>  '\n> @@ -838,7 +839,7 @@ test_expect_success 'test_oid can look up data for SHA-256' '\n>  \tgrep \"^00*\\$\" actual &&\n>  \trawsz=\"$(test_oid rawsz)\" &&\n>  \thexsz=\"$(test_oid hexsz)\" &&\n> -\ttest $(wc -c <actual) -eq 64 &&\n> +\ttest $(wc -c <actual) -eq 65 &&\n>  \ttest \"$rawsz\" -eq 32 &&\n>  \ttest \"$hexsz\" -eq 64\n\n\nIf we have sibling tests we really should try to make these\nconsistent. These are still understandable, but it's rather annoying\nthat we aren't consistent here. I.e. we have 64 changed to 65, but not\n32 to 33 etc.\n\nI also vaguely recall (although probably nobody worries about such a\nplatform anymore) that POSIX utilities left themselves room to not work\non things that weren't \\n-terminated.\n\n>  test_expect_success 'gitdir selection on normal repos' '\n> -\techo $(test_oid version) >expect &&\n> +\ttest_oid version >expect &&\n>  \tgit config core.repositoryformatversion >actual &&\n>  \tgit -C test config core.repositoryformatversion >actual2 &&\n>  \ttest_cmp expect actual &&\n> diff --git a/t/t1500-rev-parse.sh b/t/t1500-rev-parse.sh\n> index 81de584ea2..37ee5091b5 100755\n> --- a/t/t1500-rev-parse.sh\n> +++ b/t/t1500-rev-parse.sh\n> @@ -195,7 +195,7 @@ test_expect_success 'rev-parse --is-shallow-repository in non-shallow repo' '\n>  '\n>  \n>  test_expect_success 'rev-parse --show-object-format in repo' '\n> -\techo \"$(test_oid algo)\" >expect &&\n> +\ttest_oid algo >expect &&\n>  \tgit rev-parse --show-object-format >actual &&\n>  \ttest_cmp expect actual &&\n>  \tgit rev-parse --show-object-format=storage >actual &&\n\nThis sort of thing is much nicer though, so maybe it's all worth it...\n\nI wonder though if we shouldn't just have a test_cmp_oid, which would\nabstract this away, and not care if it's \\n-terminated or not...\n"},{"id":"469321","messageId":"xmqqfsdb2beq.fsf@gitster.g","threadId":"58973","inReplyTo":"221219.864jtrz9yf.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH] tests: make 'test_oid' print trailing newline","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-12-19T23:58:53Z","receivedAt":"2022-12-19T23:58:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n>> @@ -826,7 +827,7 @@ test_expect_success 'test_oid can look up data for SHA-1' '\n>>  \tgrep \"^00*\\$\" actual &&\n> ...\n> I also vaguely recall (although probably nobody worries about such a\n> platform anymore) that POSIX utilities left themselves room to not work\n> on things that weren't \\n-terminated.\n\n[jc: totally irrelevant curiosity-hunt]\n\nI think you have in mind the combination of these.\n\n * \"3.195 Incomplete Line\" defines an incomple line as \"A sequence\n   of one or more non-<newline> characters at the end of the file.\"\n\n * \"3.403 Text File\" defines a text file to be \"A file that contains\n   characters organized into zero or more lines. ... many utilities\n   only produce predictable or meaningful output when operating on\n   text files\".\n\n * \"INPUT FILES\" section of \"grep\" for example says \"The input files\n   shall be text files\".\n\nIt may look unclear if \"an incomplete line\" is supposed to be a\n\"line\", and if it is not, then the output from \"test_oid zero\" we\nare grepping in in the above snippet is not a \"text file\".\n\nThe \"INPUT FILES\" section of \"sort\" states something interesting.\n\n    The input files shall be text files, except that the sort\n    utility shall add a <newline> to the end of a file ending with\n    an incomplete last line.\n\nWhy is this interesting?  Because it smells like it is clarifying\nwhether it makes file a text to end in an incomplete line, but it\ndoes not do any such thing ;-)  You can read it in two ways:\n\n * You must feed text files to \"sort\", but if you did feed a file\n   that ends with an incomplete line, the utility adds <newline> at\n   the end, which makes it a text, so the inputs to the utilities\n   all becomes \"text\".\n\n   Under this reading, you can as an exception feed a non-text file\n   to the utility, as long as its non-text-ness is limited to ending\n   with an incomplete line.  So, a file that ends with an incomplete\n   line is *not* text.\n\n * You must feed text files to \"sort\", and an text file that ends\n   with an incomplete line gains terminating <newline> at the end of\n   that last line, so a hit on that line will be shown, terminated\n   with <newline>, just like a hit on any other line.\n\n   Under this reading, a text file may or may not end with an\n   incomplete line, so a file that ends with an incomplete line is\n   text.\n\nhttps://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html\nhttps://pubs.opengroup.org/onlinepubs/9699919799/utilities/grep.html\nhttps://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html\n\nSo I dunno.\n\nIn any case, I think it is a good practice to avoid having to worry\nabout how the standard utilities would behave by making sure our\nlines are complete.\n\n"},{"id":"469476","messageId":"20221222185804.GE3411@szeder.dev","threadId":"58973","inReplyTo":"xmqqy1r4usjy.fsf@gitster.g","subject":"Re: [PATCH] tests: make 'test_oid' print trailing newline","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2022-12-22T18:58:04Z","receivedAt":"2022-12-22T18:58:13Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Mon, Dec 19, 2022 at 09:48:49AM +0900, Junio C Hamano wrote:\n> SZEDER Gábor <szeder.dev@gmail.com> writes:\n> >       $ git grep '\\stest_oid ' -- ':/t/*.sh'\n> >       $ git grep 'echo \"\\?$(test_oid ' -- ':/t/*.sh'\n> \n> I found these examples in the log message a bit annoying to see, as\n> both invite an undefined behaviour by having an ordinary character\n> ('s' or '?')  preceded by an unescaped backslash in a POSIXly\n> correct implementation of BRE.  GNU libc seems to be OK with it (I\n> double checked by adding \"-G\" on the command line to make sure my\n> experiments are not affected by any grep.patterntype), but they may\n> fail for folks on stricter platforms.\n\nPlease feel free to amend the commit message as you see fit.  Usually\nI would do that myself as I'm rather picky of my commit messages, but,\nalas, I'm not versed in portability issues of regexes, so I'm not sure\nwhat the right regexes would be.\n\n"},{"id":"469482","messageId":"xmqq3597rl88.fsf@gitster.g","threadId":"58973","inReplyTo":"20221222185804.GE3411@szeder.dev","subject":"Re: [PATCH] tests: make 'test_oid' print trailing newline","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-12-23T00:56:39Z","receivedAt":"2022-12-23T00:56:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"SZEDER Gábor <szeder.dev@gmail.com> writes:\n\n> On Mon, Dec 19, 2022 at 09:48:49AM +0900, Junio C Hamano wrote:\n>> SZEDER Gábor <szeder.dev@gmail.com> writes:\n>> >       $ git grep '\\stest_oid ' -- ':/t/*.sh'\n>> >       $ git grep 'echo \"\\?$(test_oid ' -- ':/t/*.sh'\n>>  ...\n>> I found these examples in the log message a bit annoying to see, as\n>> experiments are not affected by any grep.patterntype), but they may\n>> fail for folks on stricter platforms.\n>\n> Please feel free to amend the commit message as you see fit.  Usually\n> I would do that myself as I'm rather picky of my commit messages, but,\n> alas, I'm not versed in portability issues of regexes, so I'm not sure\n> what the right regexes would be.\n\nI guess ERE would give us enough expressiveness to say \"zero or one\"\nwithout relying on GNU extension.  Saying \"Any whitespace\" concisely\nas \"\\s\" would require PCRE (i.e. \"grep -P\") but because use of it is\noptional, the best we could do is \"[ ]\" (in the [bracket]), one is\nTAB and the other is SPACE).\n\nBut reading the message again, they are what the author of the patch\ndid to observe the current codebase, so I think being faithful to\nwhat you did would be fine ;-)\n\nIn any case, thanks for cleaning it up.\n\n\n"}]}