Re: [PATCH] doc: filter-branch does not require re-export of vars

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

 



On Mon, May 29, 2017 at 01:27:45PM +0900, Junio C Hamano wrote:

> Samuel Lijin <sxlijin@xxxxxxxxx> writes:
> 
> >> However, I think POSIX mandates the behavior you'd expect. And the only
> >> shell I know that misbehaves in this way is Solaris /bin/sh, which we
> >> have already declared too broken to support.
> >
> > Off-topic, but where is this explicitly documented?
> 
> One link I had readily available was
> 
>   https://public-inbox.org/git/7vei5qtnc5.fsf@xxxxxxxxxxxxxxxxxxxxxxxx/
> 
> but there may be older discussions that were the actual process of
> our officially having "written its /bin/sh off as broken and
> unusable" if you dig further in the list archive.

Ah, I had taken Samuel's question as "where is the POSIX behavior
documented". :)

The link above is a good explanation of the $() problem on Solaris. It
also doesn't do ${parameter#word}. I couldn't find a specific moment of
outlawing that /bin/sh, but there are several mentions of problems with
it going back to the beginning. Here's one from 2007:

  http://public-inbox.org/git/7vabt9sasl.fsf@xxxxxxxxxxxxxxxxxxxxxxxx/

We had already given up on it by then.

I don't think there's anything in CodingGuidelines (though t/README does
call it "broken"), though it explicitly endorses $(), which rules out
Solaris /bin/sh.

I think we found in the last year or two that there are some old
versions of ksh that don't like our scripts (definitely ksh88, and maybe
ksh93?). Some light reading for the curious:

  http://public-inbox.org/git/CALR6jEhviK9KZxR6R6xzkZ5EAO-RjWj3xYah_DOSDXhEjYsT-A@xxxxxxxxxxxxxx/

  http://public-inbox.org/git/CALR6jEjWjJA0X2qXsxqObqc_yxrgX87LYf8cmJ0MmJFF6PkmTQ@xxxxxxxxxxxxxx/

  http://public-inbox.org/git/xmqqinxt3kwq.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx/

The problems are around backslash-escaping, signal exit codes, and
doubled parentheses. There are some patches, but I think we decided not
to pursue it (I couldn't find that exact decision, but it's referenced
later on).

-Peff



[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]