git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] t9100: fix breakage when SHELL_PATH is not /bin/sh

From
Jeff King <peff@peff.net>
Date
Feb 8, 2016, 16:37 UTC
Message-ID
<20160208163700.GA22929@sigill.intra.peff.net>
In-Reply-To
<CAA19uiRSu_6Os3b498obSNec7b2uiYv20SZ=y93CkjsWqhqHzA@mail.gmail.com>
On Mon, Feb 08, 2016 at 05:27:30PM +0100, Michael J Gruber wrote:
Show 13 quoted lines
> > I think this just re-breaks things on Windows. That first setup test
> > used "chmod +x" (which is brought back by your patch), without having
> > the POSIXPERM prerequisite.
> >
> > We probably do not want to mark the whole setup test as POSIXPERM, as
> > that would effectively break all of the other tests on Windows. The rest
> > of the tests need to be able to work whether or not the "chmod +x" was
> > run. It may be simpler to just break the executable-bit tests, including
> > setup, out to their own section of the script.
> >
> The commit message does not explain that part of the patch at all - to me
> it looks as if the direct "echo" and "chmod +x" is simply replaced
> by calling a function which does just that, or more exactly, not quite:

Ah, right. I figured that systems that don't handle `chmod +x` would omit it from write_script(). But it looks like we don't. I guess the logic is that on Windows "chmod +x" doesn't _complain_, it's simply a noop for adding the file to the index (because we unset core.filemode).

So in that sense, Windows is fine with that setup either way.

I wondered why it would not later fail the same sha1 check, since "git add" would not respect the executable bit on such a system. But the answer is that we do not "git add" the result; we import it using svn, and then convert that to a git tree.

Show 8 quoted lines
> > That being said, t9100 seems to pass for me, even at bcb11f1. Can you
> > show us the breakage you are seeing?
> 
> SHELL_PATH=/bin/dash (in config.mak)
> 
> As I explained in my commit message, the problem arises when SHELL_PATH is
> not "/bin/sh" and, consequently,
> the generated "exec.sh" results in a blob with a different sha1.

Oh, of course. I forgot that my SHELL_PATH is in fact /bin/sh. Sorry for being thick.

Assuming your patch works on Windows (and from the logic above, I think it should be the case?), then I think it's a good solution.

-Peff
Previous: Michael J GruberNext: Johannes Schindelin
Message 4 of 13 in “t9100: fix breakage when SHELL_PATH is not /bin/sh”
  1. t9100: fix breakage when SHELL_PATH is not /bin/shMichael J Gruber, Feb 7, 2016
  2. Jeff KingFeb 8, 2016
  3. Michael J GruberFeb 8, 2016
  4. Jeff KingFeb 8, 2016
  5. Johannes SchindelinFeb 8, 2016
  6. Jeff KingFeb 8, 2016
  7. Junio C HamanoFeb 8, 2016
  8. Jeff KingFeb 8, 2016
  9. Johannes SchindelinFeb 9, 2016
  10. Junio C HamanoFeb 9, 2016
  11. Johannes SchindelinFeb 8, 2016
  12. Junio C HamanoFeb 8, 2016
  13. Johannes SchindelinFeb 9, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.