Re: [PATCH] git-prompt.sh: shorter equal upstream branch name
- From
- Richard Hansen <rhansen@bbn.com>
- Date
- Oct 7, 2014, 19:42 UTC
- Message-ID
- <54344241.60703@bbn.com>
- In-Reply-To
- <54340D63.8030507@gmail.com>
On 2014-10-07 11:57, Julien Carsique wrote:
Show 9 quoted lines
> Hi, > > Thank you both for your feedback! > I'm looking at applying your requests: > - add tests, > - variable renaming, > - use of local, > - fix multiple issues on string parsing > - avoid useless bash-isms? Did you agree on the ones I should remove?
I'm guessing the structure of your code will change somewhat when you address the other issues, so I think it may be premature to discuss specific Bashisms right now. (There aren't any particular Bashisms that I think should always be avoided -- I just want people to ponder whether a particular use of a Bashism is truly preferable to a POSIX-conformant alternative.)
Write the code in the way you think is best, and if I see a good way to convert a Bashism to POSIX I'll let you know. And feel free to ignore me -- I'm a member of the Church of POSIX Conformance while Junio is much more grounded in reality. :)
> > I'll send an updated patch asap. Tell me if I forgot something.
Your list looks complete to me. Thank you for contributing!
-Richard
Show 31 quoted lines
>
> Regards,
> Julien
>
> On 01/10/2014 19:49, Junio C Hamano wrote:
>> Richard Hansen <rhansen@bbn.com> writes:
>>
>>>> and there is no hope to "fix" them to stick to
>>>> the bare-minimum POSIX,
>>> I don't think it'd be hard to convert it to pure POSIX if there was a
>>> desire to do so.
>> Not necessarily; if you make it so slow to be usable as a prompt
>> script, that is not a "conversion". Bash-isms in the script is
>> allowed for a reason, unfortunately.
>>
>>> It would be unwise to go to great lengths to avoid Bashisms, but I think
>>> it would be smart to use POSIX syntax when it is easy to do so.
>> In general, I agree with you. People who know only bash tend to
>> overuse bash-isms where they are not necessary, leaving an
>> unreadable mess.
>>
>> For the specific purpose of Julien's "if the tail part of this
>> string matches the other string, replace that with an equal sign",
>> ${parameter/pattern/string} is a wrong bash-ism to use. But the
>> right solution to count the length of the other string and take a
>> substring of this string from its beginning would require other
>> bash-isms ${#parameter} and ${parameter:offset:length}.
>>
>> And that's fine.
>
>