Johannes Schindelin writes:
> Besides, I am pretty certain that there is a test in t9100 that *does*
> test the executable bit, properly requiring POSIXPERM.
>
> So I still would be in favor of using write_script: 1) our *intention* is
> to write a script, even if we do not currently execute it,
Hi Junio,
On Mon, 8 Feb 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > write_script is a semantically unambiguous way to specify what we *want*.
> > And it would allow us to handle chmod specifically for Windows *in one
> > place only*.
>
> Correct. write_script, for the inte
Hi Peff (and other interested parties),
On Mon, 8 Feb 2016, Jeff King wrote:
> On Mon, Feb 08, 2016 at 11:43:19AM -0800, Junio C Hamano wrote:
>
> > The version in 'master' that does
> >
> > echo "#!/bin/sh" >exec.sh &&
> > chmod +x exec.sh &&
> >
> > should be
Johannes Schindelin writes:
> write_script is a semantically unambiguous way to specify what we *want*.
> And it would allow us to handle chmod specifically for Windows *in one
> place only*.
Correct. write_script, for the intended target of the helper, is a
way to write a script that can later
Hi Peff,
On Mon, 8 Feb 2016, Jeff King wrote:
> On Mon, Feb 08, 2016 at 08:31:54PM +0100, Johannes Schindelin wrote:
>
> > On Mon, 8 Feb 2016, Jeff King wrote:
> >
> > > Assuming your patch works on Windows
> >
> > If it re-introduces that chmod +x, it won't.
> >
> > Please note that my *orig
On Mon, Feb 08, 2016 at 11:43:19AM -0800, Junio C Hamano wrote:
> > But then what is write_script buying us?
>
> The correct way to write a script for a specific interpreter is to
> give a second parameter to write_script, i.e.
>
> write_script exec.sh /bin/sh
> and the answer to
Jeff King writes:
> I'm confused why it matters. write_script() unconditionally calls "chmod
> +x", doesn't it?
Yeah, that was exactly my thought, too. Sorry for not noticing that
this depended the "interpreter" exactly be /bin/sh, though (it is
not even executed).
> I just double-checked its
On Mon, Feb 08, 2016 at 08:31:54PM +0100, Johannes Schindelin wrote:
> On Mon, 8 Feb 2016, Jeff King wrote:
>
> > Assuming your patch works on Windows
>
> If it re-introduces that chmod +x, it won't.
>
> Please note that my *original* patch actually only guarded the chmod +x,
> but Junio sugges
Hi,
On Mon, 8 Feb 2016, Jeff King wrote:
> Assuming your patch works on Windows
If it re-introduces that chmod +x, it won't.
Please note that my *original* patch actually only guarded the chmod +x,
but Junio suggested switching to write_script and since it passed the test
suite here, I though i
On Mon, Feb 08, 2016 at 05:27:30PM +0100, Michael J Gruber wrote:
> > 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 set
[warning: experimenting with forwarding to and replying from gmail...]
2016-02-08 14:50 GMT+01:00 Jeff King :
> On Sun, Feb 07, 2016 at 08:11:37PM +0100, Michael J Gruber wrote:
>
>> bcb11f1 (mingw: mark t9100's test cases with appropriate prereqs, 2016-01-27)
>> replaced "/bin/sh" in exec.sh by th
On Sun, Feb 07, 2016 at 08:11:37PM +0100, Michael J Gruber wrote:
> bcb11f1 (mingw: mark t9100's test cases with appropriate prereqs, 2016-01-27)
> replaced "/bin/sh" in exec.sh by the shell specified in SHELL_PATH, but
> that breaks the subtest which checks for a specific checksum of a tree
> con
12 matches
Mail list logo
