Observe that my test fails because the trackdown copy of the repo
doesn't use --set-scripts-executable.

$ darcs --version
1.0.9rc1 (release candidate 1)
$ grep executable ~/.darcs/defaults
ALL set-scripts-executable
$ darcs trackdown ./transmute
Tracking down command:
./transmute
/bin/sh: ./transmute: Permission denied
Trying without the patch:
Wed Sep 19 01:27:36 EST 2007  Trent W. Buck <twb@cyber.com.au>
  * Mimic sh -x.
/bin/sh: ./transmute: Permission denied
Trying without the patch:
Mon Aug 20 06:54:36 EST 2007  Trent W. Buck <trentbuck@gmail.com>
  * Care when a child fails.
/bin/sh: ./transmute: Permission denied
Trying without the patch:
Mon Aug 20 06:52:46 EST 2007  Trent W. Buck <trentbuck@gmail.com>
  * Define FORK-AND-WAIT.
/bin/sh: ./transmute: Permission denied
Trying without the patch:
Mon Aug 20 06:49:48 EST 2007  Trent W. Buck <trentbuck@gmail.com>
  * Define WHEN, UNLESS and ASSERT.
/bin/sh: ./transmute: Permission denied
Trying without the patch:
Mon Aug 20 05:53:04 EST 2007  Trent W. Buck <trentbuck@gmail.com>
  * Implement command-line interface.
  No argument parsing yet.
Noone passed the test!

This should be a straightforward bug to fix.  Thanks for the bug report!

David

It seems this bug is still there. I'm going in.

Yay! Watch out, though.  I suspect it's not just about enabling the
flag, but figuring out how to make it chmod scripts that it undeletes
when unpulling a patch.

Plus maybe getting things nice and factored.

Yay! Watch out, though.  I suspect it's not just about enabling the
flag, but figuring out how to make it chmod scripts that it undeletes
when unpulling a patch.

Plus maybe getting things nice and factored.

Hmmm, in src/Darcs/Repository/Pristine.lhs lines 136 and 137 we find:

-- We don't need flags for now, since we don't care about
-- SetScriptsExecutable for the pristine cache.

It seems however that the bug reporter does care, for the effect of the patch
that adds the test file is stored in the pristine cache.

One thing I'm wondering about: rather than having a --set-scripts-executable
flag, how about distributing a little posthook program that walks a directory
tree and does the chmoding for you?

We could stick it in tools.darcs.net, I suppose.

On Fri, Apr 25, 2008 at 10:51:15AM -0000, Eric Kow wrote:
> One thing I'm wondering about: rather than having a
> --set-scripts-executable flag, how about distributing a little
> posthook program that walks a directory tree and does the chmoding
> for you?

Hell, the existing --set-scripts-executable switch as used by apply is
already a hack -- you might as well rip that out and replace it with
the aforementioned utility.

Incidentally, that was exactly the workaround I used when I reported
the bug; since I only had one executable and I knew its name, I just
passed 'chmod +x thingy' as the setup argument.

>  Hell, the existing --set-scripts-executable switch as used by apply is
>  already a hack -- you might as well rip that out and replace it with
>  the aforementioned utility.

Right, that's what I meant.

Because it's unclear what the semantics of --set-scripts-executable for record
can and should be (and whether --set-scripts-executable is a good idea at all),
and no one has told me, I'm unassigning this bug from me.

Did you mean 'what the semantics of --set-scripts-executable for /trackdown/
can and should be'?

If so, perhaps we can discuss this.  I get the impression that the expected
behaviour would be for all scripts in the temporary working dir created by
trackdown to be +x at all times.  For instance, if the trackdown decides it
needs to unapply a patch, it should ensure that any scripts created in the
process are executable.

Or is that too vague?

> Did you mean 'what the semantics of --set-scripts-executable for
> /trackdown/
> can and should be'?
Possibly. But the way I made it work for unhashed repositories, I enabled
--set-scripts-executable for record. That way, scripts get stored
executably in the pristine and will end up as executables in the test
working directory. This is, I presume, why the test works if you get
--set-scripts-executable.

And of course, if you want the test to work for trackdown, you also want
it to work for record.

> If so, perhaps we can discuss this.  I get the impression that the
> expected
> behaviour would be for all scripts in the temporary working dir created by
> trackdown to be +x at all times.  For instance, if the trackdown decides
> it
> needs to unapply a patch, it should ensure that any scripts created in the
> process are executable.
The only case I can see, in which a file needs to be set executable during
the trackdown, is when a patch that removes a script is unapplied. In that
case, doesn't darcs eventually call the apply function for a hunk patch
that sets the file executable if it starts with '#!' and
--set-scripts-executable is given?

>  Possibly. But the way I made it work for unhashed repositories, I enabled
>  --set-scripts-executable for record. That way, scripts get stored
>  executably in the pristine and will end up as executables in the test
>  working directory. This is, I presume, why the test works if you get
>  --set-scripts-executable.

Ooh, I don't think it would be very nice to change /anything/ about
pristine. Having --set-scripts-executable affect the test-working
directory sounds like a good thing for record and amend-record... just
not through the pristine directory.

>  And of course, if you want the test to work for trackdown, you also want
>  it to work for record.

I see.  Thanks for pointing that out.

>  The only case I can see, in which a file needs to be set executable during
>  the trackdown, is when a patch that removes a script is unapplied. In that
>  case, doesn't darcs eventually call the apply function for a hunk patch
>  that sets the file executable if it starts with '#!' and
>  --set-scripts-executable is given?

Well... we could find out by looking in the source code.  I remember
that Darcs.Patch.Apply does some detection on this.  Another way to
find out is to write a test :-)

Op 30-apr-2008, om 12:11 heeft Eric Kow het volgende geschreven:
> Ooh, I don't think it would be very nice to change /anything/ about
> pristine. Having --set-scripts-executable affect the test-working
> directory sounds like a good thing for record and amend-record... just
> not through the pristine directory.
OK, but executable files end up in the pristine already, and I construed that as
a feature, not a bug.

| Mon Jun  2 21:21:55 EST 2008  David Roundy <droundy@darcs.net>
|   * skip issue538.sh on windows, since I don't know how to run tests
|   since ./test.sh isn't accepted on windows.
|     hunk ./tests/issue538.sh 7
|     +if echo $OS | grep -i windows; then
|     +    echo I do not know how to run a test program under windows
|     +    exit 0
|     +fi
|     +

Since you already seem to be using unix commands (grep), perhaps you
could use stat(1) or find(1), both of which can examine the
executability (i.e. mode, on Unix) of files, e.g.

$ touch x y
$ chmod +x x
$ stat -c %a\ %A\ %n x y
755 -rwxr-xr-x x
644 -rw-r--r-- y
$ find -executable -type f
./x
$

This doesn't appear to be fixed:

$ darcs trackdown --set-scripts-executable /bin/true

darcs failed:  unrecognized option `--set-scripts-executable'

Regarding my previous message; that test obviously fails in 2.0.0,
because implementation took place AFTER 2.0.0 (but before the 2.0.2
release).