Re: [PATCH] git-prompt.sh: shorter equal upstream branch name

On 2014-10-07 11:57, Julien Carsique wrote:

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

Regards,
Julien

On 01/10/2014 19:49, Junio C Hamano wrote:

quoted

Richard Hansen [off-list ref] writes:

quoted

quoted

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.

quoted

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.