Re: [PATCH 6/8] git-prompt: add fallback for shells without $'...'

[avih <avihpit@xxxxxxxxx>]

 On Thursday, July 25, 2024 at 02:27:29 PM GMT+3, avih <avihpit@xxxxxxxxx> wrote:
>
> So mainly as a general solution, but also applicable to this patch,
> below is my best generalized solution so far, so that scripts don't
> have to reinvent the wheel with this "string strip dance" above,
> but I'm not too happy with it, mainly due to the gotcha that single
> quotes in the value break the world (escape the "eval").

Pardon the noise.

To summarize the options to replace $'...' portably, like:

    __git_SOH=$'\1' __git_STX=$'\2' __git_ESC=$'\33'
    __git_LF=$'\n' __git_CRLF=$'\r\n'

The current patch has this, which is not fun and not scalable:

   __git_CRLF=$(printf "\r\n\1\2\33")  # CR LF SOH STX ESC
   __git_ESC=${__git_CRLF#????}; __git_CRLF=${__git_CRLF%?}
   __git_STX=${__git_CRLF#???};  __git_CRLF=${__git_CRLF%?}
   __git_SOH=${__git_CRLF#??};   __git_CRLF=${__git_CRLF%?}
   __git_LF=${__git_CRLF#?}

If performance is not important, this works (with care about \n):

   __git_LF=$(printf "\nx"); __git_LF=${__git_LF%x}
   __git_STX=$(printf '\1')
   ...

A previous message suggested this, which has a beautiful API,
but it requires an additional non-tiny function, and it also
hides a great risk of escaping "eval":

    assign_as_fmt () {
        # hides the usage of "eval"
        ...
    }

    assign_as_fmt \
        __git_SOH='\1' __git_STX='\2' __git_ESC='\33' \
        __git_LF='\n' __git_CRLF='\r\n'

But then I figured there's another option, which is reasonably
readable, scalable, small without additional functions, but still
requires some care, though the risk is not hidden and easy to avoid:

It's basically what the function does, but without a function:
(double quotes required only if it ends in \n, or for uniformity)

    # doubel-check to ensure the printf output is valid shell input
    eval "$(printf '
        __git_SOH="\1" __git_STX="\2" __git_ESC="\33"
        __git_LF="\n" __git_CRLF="\r\n"
    ')"

I think it strikes the best balance between the options, both
for this patch, and possibly also as a general recomendation.

So unless there are objections or better suggestions, this is
what I currently prefer for this patch.