Re: "nasty chmod hack" patch

[Mo DeJong <su...@bayarea.net>]

On 21 Dec 2001 12:24:30 -0600
cmpilato@collab.net wrote:

> Mo, I decided to keep the chmod a+x in Makefile.in until we have the
> ability to version the execute perm bit.  Once we can do that, we'll
> simply commit that perm prop on those scripts and then remove the
> chmod hack.  The rest of the patch was all good, though, and was left
> untouched.

There is no reason to keep the chmod hack. The reason it was in there
before was to add execute perms to a shell script, but the patch runs
a shell script using $(SHELL) instead of executing it:

runprog="$(SHELL) $$progbase"

The chmods in autogen.sh could go away once the execute perms are
under revision control, but it should not matter for Makefile.in. Also,
the source code might be on a read only media (like a CD) so running
a chmod on the shell scripts at "make check" time would produce an error.

cheers
Mo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: "nasty chmod hack" patch

[Roman Neuhauser <ne...@mobil.cz>]

> To: Mo DeJong <su...@bayarea.net>
> Cc: subversion <de...@subversion.tigris.org>
> From: Karl Fogel <kf...@newton.ch.collab.net>
> Date: 26 Dec 2001 13:38:21 -0600
> Subject:  Re: "nasty chmod hack" patch
> 
> Mo DeJong <su...@bayarea.net> writes:
> > There is no reason to keep the chmod hack. The reason it was in there
> > before was to add execute perms to a shell script, but the patch runs
> > a shell script using $(SHELL) instead of executing it:
> > 
> > runprog="$(SHELL) $$progbase"
> 
> There is still a reason, Mo -- a lot of people run those tests
> directly from the command line, especially when they've written a new
> test or fixed an old test.  In general, it's always useful to have
> runnable programs be +x, for this sort of reason.

    You can still do "sh test.sh" instead of "./test.sh", no?
 
> > The chmods in autogen.sh could go away once the execute perms are
> > under revision control, but it should not matter for Makefile.in. Also,
> > the source code might be on a read only media (like a CD) so running
> > a chmod on the shell scripts at "make check" time would produce an error.
> 
> Um, let's deal with that problem when it comes up.

-- 
FreeBSD 4.4-STABLE
3:01PM up 1 day, 1:39, 8 users, load averages: 0.10, 0.03, 0.01

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: "nasty chmod hack" patch

[Karl Fogel <kf...@newton.ch.collab.net>]

Mo DeJong <su...@bayarea.net> writes:
> There is no reason to keep the chmod hack. The reason it was in there
> before was to add execute perms to a shell script, but the patch runs
> a shell script using $(SHELL) instead of executing it:
> 
> runprog="$(SHELL) $$progbase"

There is still a reason, Mo -- a lot of people run those tests
directly from the command line, especially when they've written a new
test or fixed an old test.  In general, it's always useful to have
runnable programs be +x, for this sort of reason.

> The chmods in autogen.sh could go away once the execute perms are
> under revision control, but it should not matter for Makefile.in. Also,
> the source code might be on a read only media (like a CD) so running
> a chmod on the shell scripts at "make check" time would produce an error.

Um, let's deal with that problem when it comes up.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org