[Bug other/102664] New: contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[Bug other/102664] New: contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

            Bug ID: 102664
           Summary: contrib/gcc-git-customization.sh uses echo -n, which
                    isn't portable
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: egallager at gcc dot gnu.org
  Target Milestone: ---

Specifically, in ask(), it does:

    echo -n $question "["$default"]? "

which results in the "-n" being included literally on systems whose echo
doesn't support that flag:

-n Local name for upstream repository [origin]?

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-10-09
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
https://pubs.opengroup.org/onlinepubs/009604599/utilities/echo.html

Confirmed.
The informative part of the documentation recommands using printf instead.

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |easyhack
           Severity|normal                      |trivial
                 CC|                            |rearnsha at arm dot com

--- Comment #2 from Eric Gallager <egallager at gcc dot gnu.org> ---
git blame says it's been there since Richard Earnshaw first committed the file
in g:743d4d8; cc-ing him

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #3 from Eric Gallager <egallager at gcc dot gnu.org> ---
Along these lines, there's also some non-portable usage of `expr` in the file,
too (which I brought up on IRC), but I forget what exactly it was...

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #4 from Eric Gallager <egallager at gcc dot gnu.org> ---
I think one of the Martins might be taking part of the `expr` usage by
rewriting gcc-descr here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588849.html

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #5 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Eric Gallager from comment #3)
> Along these lines, there's also some non-portable usage of `expr` in the
> file, too (which I brought up on IRC), but I forget what exactly it was...

Do you know what exactly is problematic regarding the portability?

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |iains at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org

--- Comment #6 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #5)
> (In reply to Eric Gallager from comment #3)
> > Along these lines, there's also some non-portable usage of `expr` in the
> > file, too (which I brought up on IRC), but I forget what exactly it was...
> 
> Do you know what exactly is problematic regarding the portability?

Ah, I found my IRC log; apparently it was the `expr match` part:

 1635762461 31<egallager>30     hm, looks like I need to use gexpr instead of
just-plain expr
T 1635762474 31<egallager>30    I guess it's a GNU vs. BSD thing 
T 1635762672 31<egallager>30    so I guess that's a separate bug to file
T 1635762691 31<egallager>30    I guess the g:hash syntax will do for now for
the other one I was filing 
T 1635762767 18<iains>  yes, there are some non-portable parts in the
customisation … 
T 1635762803 18<jakub>  expr is used twice there, is the problem with expr
match or with expr x - y
T 1635762865 18*        iains thought the initial problem was with the match ..
but ICBW
T 1635762967 18<jakub>  I guess it can be replaced with echo | grep -q too, but
for bash that is unnecessary slowdown...; perhaps gcc-git-customization.sh
could check if expr match works and if not, use something different...
T 1635763046 31<egallager>30    I think it's the expr match part

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Limitations-of-Usual-Tools.html#index-g_t_0040command_007bexpr_007d-1813

The expr match regex should not start with ^ (that is implied anyway, and some
versions of expr don't like it)

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #7)
> https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
> Limitations-of-Usual-Tools.html#index-g_t_0040command_007bexpr_007d-1813
> 
> The expr match regex should not start with ^ (that is implied anyway, and
> some versions of expr don't like it)

This part is fixed at r12-6898

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #9 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Jonathan Wakely from comment #7)
> > https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
> > Limitations-of-Usual-Tools.html#index-g_t_0040command_007bexpr_007d-1813
> > 
> > The expr match regex should not start with ^ (that is implied anyway, and
> > some versions of expr don't like it)
> 
> This part is fixed at r12-6898

I still get "expr: syntax error" when trying to do `git gcc-descr 716bb02b`
after re-running `sh ./contrib/gcc-git-customization.sh`

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #10 from Martin Liška <marxin at gcc dot gnu.org> ---
> I still get "expr: syntax error" when trying to do `git gcc-descr 716bb02b`
> after re-running `sh ./contrib/gcc-git-customization.sh`

Ok, so can you please run:

$ bash -x ./contrib/git-descr.sh 716bb02b

What OS do you use?

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
git-descr.sh uses ${r:-no} which is a bash feature, but the shebang says
/bin/sh

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Ah no, my mistake, any POSIX shell should expand that correctly.

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Ah, but 'expr match str re' is not in POSIX, it should be 'expr str : re'

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #14 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #13)
> Ah, but 'expr match str re' is not in POSIX, it should be 'expr str : re'

Great, I can confirm it works for me. Can you please install the change?

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #7)
> https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
> Limitations-of-Usual-Tools.html#index-g_t_0040command_007bexpr_007d-1813
> 
> The expr match regex should not start with ^ (that is implied anyway, and
> some versions of expr don't like it)

As it says at that link:

"Don't use length, substr, match and index."

I'll fix it now.

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Using "${r}" instead of ${r:-no} would be simpler too, but that can be done
separately.

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:10ecf5182a0f63d79a44b953483ecfbb54d29bcb

commit r12-7536-g10ecf5182a0f63d79a44b953483ecfbb54d29bcb
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Mar 8 16:44:17 2022 +0000

    contrib: Fix gcc-descr script [PR102664]

    POSIX expr does not support the 'match' keyword, so the git-descr.sh
    scripts should use ':' instead.

    contrib/ChangeLog:

            PR other/102664
            * git-descr.sh: Use portable form of expr match.

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #18 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Eric, please try again now.

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #19 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #10)
> > I still get "expr: syntax error" when trying to do `git gcc-descr 716bb02b`
> > after re-running `sh ./contrib/gcc-git-customization.sh`
> 
> Ok, so can you please run:
> 
> $ bash -x ./contrib/git-descr.sh 716bb02b
> 

Ok, I've updated; output of that is now:

$ bash -x ./contrib/git-descr.sh 716bb02b
+ short=no
+ long=no
+ c=master
+ for arg in '"$@"'
+ case "$arg" in
+ c=716bb02b
+ test xno = xyes
+ test xno = xyes
++ git describe --all --abbrev=14 --match 'basepoints/gcc-[0-9]*' 716bb02b
++ sed -n 's,^\(tags/\)\?basepoints/gcc-,r,p'
+ r=
+ expr no : 'r[0-9]\+$'
+ test -n
++ git config --get gcc-config.upstream
+ o=origin
++ echo
++ sed -n 's,^r\([0-9]\+\)-[0-9]\+\(-g[0-9a-f]\+\)\?$,\1,p'
+ rr=
+ git rev-parse --verify --quiet origin/releases/gcc-
+ m=master
+ git merge-base --is-ancestor 716bb02b origin/master
+ echo
$

> What OS do you use?

macOS 11.6.4 (Big Sur)

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #20 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The first sed is failing.

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #21 from Jonathan Wakely <redi at gcc dot gnu.org> ---
We should use: sed -n 's,^tags/,,;s,^basepoints/gcc-,r,p'

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #22 from Jonathan Wakely <redi at gcc dot gnu.org> ---
\? is not allowed in a POSIX BRE, and unsupported by Solaris and BSD.

The capture group with \( and \) is not supported by /usr/bin/sed on Solaris,
but is supported by /usr/xpg4/bin but I guess we can just require users to have
their PATH in order.

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #23 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I have a patch ...

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #24 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591396.html

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #25 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:17bffa0c9f90df49bde6671816bde04008b6c5af

commit r12-7554-g17bffa0c9f90df49bde6671816bde04008b6c5af
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Mar 8 17:40:48 2022 +0000

    contrib: Fix non-portable sed commands in gcc-descr [PR102664/]

    POSIX sed does not support \? or \+ in its Basic Regular Expression
    grammar. Replace the \(tags/\)\? part of the pattern with a substitution
    to remove ^tags/ before other substitutions. Replace \([0-9]\+\) with
    \([0-9][0-9]*\) or with \([1-9][0-9]*\) in release branch numbers, where
    a leading zero does not occur.

    contrib/ChangeLog:

            PR other/102664
            * git-descr.sh: Use portable sed commands.
            * git-undescr.sh: Likewise.

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #26 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Does it work on macOS now?

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #27 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #26)
> Does it work on macOS now?

Yes, thanks! All that remains now is the original `echo -n` problem...
Actually, let me test to see if the autolinking works with the output:

$ git gcc-descr 716bb02b
r12-94-g716bb02b40ecef
$

...ok, good!

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #28 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
I think the 'echo -n' problem can be solved by changing the one instance of
that operation (in ask()) to 

printf "%s" "$question [$default]? "

But I don't have the machines that are problematic to test that on.  Could
somebody test such a change please?

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #29 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Suggested patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591455.html

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #30 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Solaris /bin/echo doesn't understand -n 


jwakely@gcc-solaris11:~/src/gcc$ ./contrib/gcc-git-customization.sh 
-n Your name [Jonathan Wakely]? 

-n Your email address (for git commits) [jwakely@redhat.com]? 

-n Local name for upstream repository [origin]? 



Richard's patch fixes it for Solaris:

Your name [Jonathan Wakely]? 
Your email address (for git commits) [jwakely@redhat.com]? 
Local name for upstream repository [origin]? 


I'd have done printf "%s [%s]?" "$question" "$default" instead, but they're
equivalent. Given that I've tested it and you're a global maintainer, I said
push it!

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #31 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #30)
> I'd have done printf "%s [%s]?" "$question" "$default" instead, but they're
> equivalent. Given that I've tested it and you're a global maintainer, I said
> push it!

s/said/say/

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #32 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #30)
> I'd have done printf "%s [%s]?" "$question" "$default" instead, but they're
> equivalent.

Oops, equivalent except for the missing space after the question mark in my
version.

There are still other issues on Solaris though:


$ PATH=/usr/xpg4/bin:$PATH ./contrib/gcc-git-customization.sh 
Your name [Jonathan Wakely]? 
Your email address (for git commits) [jwakely@redhat.com]? 
Local name for upstream repository [origin]? 
sed: illegal option -- r
Usage:  sed [-n] script [file...]
        sed [-n] [-e script]...[-f script_file]...[file...]
Account name on gcc.gnu.org (for your personal branches area) [remote_id]? redi
./contrib/gcc-git-customization.sh[16]: eval[1]: =redi: not found [No such file
or directory]

Local branch prefix for personal branches you want to share
(local branches starting <prefix>/ can be pushed directly to your
personal area on the gcc server) [me]? 

Install prepare-commit-msg git hook for 'git commit-mklog' alias [yes]? 
fatal: ambiguous argument 'hooks': unknown revision or path not in the working
tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
cp: illegal option -- git-path
cp: Insufficient arguments (1)
Usage: cp [-f] [-i] [-p] [-@] [-/] f1 f2
       cp [-f] [-i] [-p] [-@] [-/] f1 ... fn d1
       cp -r|-R [-H|-L|-P] [-f] [-i] [-p] [-@] [-/] d1 ... dn-1 dn
install: cp --git-path
/export/home/jwakely/src/gcc/contrib/prepare-commit-msg/--git-path failed 
sed: illegal option -- r
Usage:  sed [-n] script [file...]
        sed [-n] [-e script]...[-f script_file]...[file...]
Setting up tracking for personal namespace  in remotes/users/me
fatal: Invalid refspec '+refs/users//heads/*:refs/remotes/users/me/*'


I'll look into those ...

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #33 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Complete patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591468.html

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #34 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:ff060ef08cfc3e48e70071cb63449b62a86f9d6f

commit r12-7575-gff060ef08cfc3e48e70071cb63449b62a86f9d6f
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Mar 10 09:42:03 2022 +0100

    contrib: Fix up git-descr.sh regression [PR102664]

    On Wed, Mar 09, 2022 at 12:40:24PM -0500, Patrick Palka via Gcc-patches
wrote:
    > On Wed, Mar 9, 2022 at 8:54 AM Mikael Morin <morin-mikael@orange.fr>
wrote:
    > > Le 08/03/2022 à 18:58, Jonathan Wakely via Gcc-patches a écrit :
    > > > Replace \([0-9]\+\) with \([0-9][0-9]*\) or with \([1-9][0-9]*\) in
release branch numbers, where
    > > > a leading zero does not occur.
    > > >
    > > Note that you also changed some gcc-[0-9]* to gcc-[1-9]*, which is a
    > > typo/thinko I guess?  It looks like it wouldnât match gcc-10 any more
    > > for exampleâ¦
    >
    > Perhaps related to this, I noticed the following
    >   git gcc-descr ea1ce0d163ea1d63b6837144ae4be51d92630007
    > now fails with
    >   fatal: No tags can describe 'ea1ce0d163ea1d63b6837144ae4be51d92630007'.
    > instead of outputting
    >   r0-52309-gea1ce0d163ea1d

    That is because of those [0-9] to [1-9] changes which prevent
    basepoints/gcc-0 from working.  While basepoints/gcc-005 etc. are certainly
    unexpected, basepoints/gcc-0 needs to work.

    2022-03-10  Jakub Jelinek  <jakub@redhat.com>

            PR other/102664
            * git-descr.sh: Replace all [1-9] occurrences with [0-9].
            * git-undescr.sh: Likewise.

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #35 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:d563b0bff19c31eb755c026ee990bca986683f25

commit r12-7588-gd563b0bff19c31eb755c026ee990bca986683f25
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Wed Mar 9 14:53:52 2022 +0000

    contrib: Fix non-portable shell commands in gcc-git-customization.sh
[PR102664]

    Use printf instead of echo -n. Use Basic Regular Expressions instead of
    sed -r. Check for error from ancient Git versions that don't support the
    --git-path option for git-rev-parse. Remove -c flag from install
    command, as it's ignored by GNU and BSD install, but means something
    different for Solaris and AIX.

    contrib/ChangeLog:

            PR other/102664
            * gcc-git-customization.sh: Fix non-portable commands.

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #36 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Can this be closed now?

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #37 from Martin Liška <marxin at gcc dot gnu.org> ---
I guess so.

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664

--- Comment #38 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #37)
> I guess so.

Yep, I can confirm this is fixed now; thanks!