Re: git rebase -i error message interprets \t in commit message

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes:

> David Kastrup <dak@xxxxxxx> writes:
>
>> Could not apply 16de9d2... Make tempo range empo 20~30 be input as
>> empo 20-30 instead
>
> Indeed. The source of the problem is that our "die" shell function
> interprets \t (because it uses "echo").
>
> A simple fix would be this:
>
> diff --git a/git-sh-setup.sh b/git-sh-setup.sh
> index 7a964ad..97258d5 100644
> --- a/git-sh-setup.sh
> +++ b/git-sh-setup.sh
> @@ -53,7 +53,7 @@ die () {
>  die_with_status () {
>         status=$1
>         shift
> -       echo >&2 "$*"
> +       printf >&2 "%s\n" "$*"
>         exit "$status"
>  }
>  
> It does not sound crazy as the shell function "say" right below uses the
> same printf "%s\n" "$*",

Sounds reasonable, though I don't know off-hand (not having the source
here) whether using "say" inside of die_with_status (and thus not having
two different places to maintain) might not be feasible instead.  It's
not like die_with_status is going to be called often enough to become a
performance hog.

> but I'm wondering whether this could have other bad implications
> (e.g. if there are escape sequences in the commit message, aren't we
> going to screw up the terminal?).

One person's escape sequences are another's multibyte characters.  Less
cheesy, it would seem that the above change is a strict improvement and
requires little thought to implement.

Not interpreting escape sequences is orthogonal from output
sanitization.

-- 
David Kastrup
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]