From patchwork Thu Nov 9 07:09:52 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick Steinhardt X-Patchwork-Id: 13450682 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9B258DDDA for ; Thu, 9 Nov 2023 07:09:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pks.im header.i=@pks.im header.b="SKO8/8Y1"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="L2pBAYWa" Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB1E6272C for ; Wed, 8 Nov 2023 23:09:55 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 533175C0358; Thu, 9 Nov 2023 02:09:55 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 09 Nov 2023 02:09:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pks.im; h=cc:cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1699513795; x=1699600195; bh=M8 h8czmMrVFMQ+BEdP4XFAN/x98Aex9MteY03N0xlvM=; b=SKO8/8Y1mqwmORR/ti 9LjkKS9L6Obto43pD34pOy/lssE6rjdCclxQBfucemF6Ha9Q7LmL+tcVNoJk76yg 5hIGISWeYP2Wo/8qj5fLq6cCPK8HTLsR0RI9jhTJ8u3dAHi3SPTyTVMF6uDjnXrs xGYvCkgAcchYsTM3Wcss3F1fakiHUUWTm1BSoDM/j2o292C9a+UE+aUfsDGbeYmb VOUVfe89vfk2OZrEKWmv/IrVzLPT2Ir8E88oHSSBwLpJjmdWl9uNRSvq33tM6FPr I6U8gffs9n4YJVah6pe3oL0qVN65l2nbGalZxRz8FcxplAFPPqfJgPVOzK55Ai48 s75g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1699513795; x=1699600195; bh=M8h8czmMrVFMQ +BEdP4XFAN/x98Aex9MteY03N0xlvM=; b=L2pBAYWavY4K7penhOuH5gSiVtY/l A0AkyibndCgVk9kwrn4ms0M/c49vGgvKdR2mx8XQk23HImTyqTVZ3/WeBC74eLTU zoHiuLiU+lMFpU9/CcAYt3s7/OdYOCSoRzk+CaNvF6OYcUKol7dl2FwkmS3tmUt3 VEVqFdbzAhAQnpRpUfvKQ7dUtqkKq4O/rUnVqsR4kG35/Yrpm77zwBn+wJbJX3Mj 92Rf8PCJ40x2iOCcXWXjF8euEbFwVgdTFQ/78nsj7zuMOzaMxOj2lnrShA5WkyBz 5tBwLDTx1SLcDgzpHElVEUoGJZjwr+zfD1NPC88D+oe6YHSuzRXnrADXw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddvtddguddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvfevuffkfhggtggujgesgh dtreertddtvdenucfhrhhomheprfgrthhrihgtkhcuufhtvghinhhhrghrughtuceophhs sehpkhhsrdhimheqnecuggftrfgrthhtvghrnhepvdehteeggfevueevhedtleelveeigf efieduiefgvdfffeegvdeitefgteevveeunecuffhomhgrihhnpehhthhtphgurdhshhen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpshesph hkshdrihhm X-ME-Proxy: Feedback-ID: i197146af:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 9 Nov 2023 02:09:54 -0500 (EST) Received: by vm-mail (OpenSMTPD) with ESMTPSA id ef8046f5 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 9 Nov 2023 07:09:27 +0000 (UTC) Date: Thu, 9 Nov 2023 08:09:52 +0100 From: Patrick Steinhardt To: git@vger.kernel.org Cc: Jeff King , Junio C Hamano Subject: [PATCH v3 1/3] t/lib-httpd: dynamically detect httpd and modules path Message-ID: References: Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: In order to set up the Apache httpd server, we need to locate both the httpd binary and its default module path. This is done with a hardcoded list of locations that we scan. While this works okayish with distros that more-or-less follow the Filesystem Hierarchy Standard, it falls apart on others like NixOS that don't. While it is possible to specify these paths via `LIB_HTTPD_PATH` and `LIB_HTTPD_MODULE_PATH`, it is not a nice experience for the developer to figure out how to set those up. And in fact we can do better by dynamically detecting both httpd and its module path at runtime: - The httpd binary can be located via PATH. - The module directory can (in many cases) be derived via the `HTTPD_ROOT` compile-time variable. Amend the code to do so. The new runtime-detected paths will only be used in case none of the hardcoded paths are usable. Signed-off-by: Patrick Steinhardt --- t/lib-httpd.sh | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/t/lib-httpd.sh b/t/lib-httpd.sh index 5fe3c8ab69d..6ab8f273a3a 100644 --- a/t/lib-httpd.sh +++ b/t/lib-httpd.sh @@ -55,21 +55,30 @@ fi HTTPD_PARA="" -for DEFAULT_HTTPD_PATH in '/usr/sbin/httpd' '/usr/sbin/apache2' +for DEFAULT_HTTPD_PATH in '/usr/sbin/httpd' \ + '/usr/sbin/apache2' \ + "$(command -v httpd)" \ + "$(command -v apache2)" do - if test -x "$DEFAULT_HTTPD_PATH" + if test -n "$DEFAULT_HTTPD_PATH" -a -x "$DEFAULT_HTTPD_PATH" then break fi done +if test -x "$DEFAULT_HTTPD_PATH" +then + DETECTED_HTTPD_ROOT="$("$DEFAULT_HTTPD_PATH" -V | sed -n 's/^ -D HTTPD_ROOT="\(.*\)"$/\1/p')" +fi + for DEFAULT_HTTPD_MODULE_PATH in '/usr/libexec/apache2' \ '/usr/lib/apache2/modules' \ '/usr/lib64/httpd/modules' \ '/usr/lib/httpd/modules' \ - '/usr/libexec/httpd' + '/usr/libexec/httpd' \ + "${DETECTED_HTTPD_ROOT:+${DETECTED_HTTPD_ROOT}/modules}" do - if test -d "$DEFAULT_HTTPD_MODULE_PATH" + if test -n "$DEFAULT_HTTPD_MODULE_PATH" -a -d "$DEFAULT_HTTPD_MODULE_PATH" then break fi From patchwork Thu Nov 9 07:09:56 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick Steinhardt X-Patchwork-Id: 13450683 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 50D1ADF6A for ; Thu, 9 Nov 2023 07:10:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pks.im header.i=@pks.im header.b="b+DNJo3C"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="IEgGNkRO" Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DF869211D for ; Wed, 8 Nov 2023 23:09:59 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 560AB5C01E1; Thu, 9 Nov 2023 02:09:59 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 09 Nov 2023 02:09:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pks.im; h=cc:cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1699513799; x=1699600199; bh=7i UB4LD0Egj0oYF5BX8i9B/D7m1WEovjLQoLhzaCSH8=; b=b+DNJo3CQ0XaM+WZas ZQVt9PfUDeMd2ufUWYDfKu14sZAplF13wkNzSRTqn6wLEnO44hXdFOj3quV03yQm Q0LCWNLjciYNJceAiWfZLlGGo9EsTNZOZgQnDYrTisEbX9hD6TmwO+s0BowTGGC3 o/5cc+MbvTc7TqNPntcAtyoXsYvFAn0u4tHWp6yc3o0iVu2qQ+kj8UheODnrJA5h ZGQ5J2o3rxT5pESzIESeXJTIfdCKSX2isv8UN2YTlPIYSC0JrZ72WA2W6psPBTqJ wOqYbGaLCBDi0HMj9p42hJ4h6d9QHNriRua23UjzdOUNah+CZp5m8woXEpcPiF5k FUEA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1699513799; x=1699600199; bh=7iUB4LD0Egj0o YF5BX8i9B/D7m1WEovjLQoLhzaCSH8=; b=IEgGNkROMbxzFmaLKYg2BaR4B5/Mc +O4K7yT1GbkmbBq6GLR4LRyyNCTHHd7WNTiyUrFw6Qph+WydhmjMzBahGdFG4rfu Gtzi3Lrgwy2j+zdHtQJkHWvRhf6t5Rptb3tfK9veHfXk80GpxuhnEFZaOmbQaPGp V+9f8TpFfW/ej022Uo0O+rgolnoCQiFskQNlnFa9lXY38Mowc+V8WRm5rGN/FjRC zCWy7JNDVaqklmaIYVNStJ6hot/dSEYvURL3ivFH+JcJaXkrJYOBmHwlIeDID67f xE8akXbBIZpTCudDHZrk7mVlrehFEk9yBGnb1UKva3cW0ebTeB82zLhnA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddvtddguddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvfevuffkfhggtggujgesgh dtreertddtvdenucfhrhhomheprfgrthhrihgtkhcuufhtvghinhhhrghrughtuceophhs sehpkhhsrdhimheqnecuggftrfgrthhtvghrnhepffekuddvgeekvdffjeffieeuuedtvd ejgeeujedugefftdfghfeuteeivdetieevnecuffhomhgrihhnpegrphgrtghhvgdrohhr ghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpsh esphhkshdrihhm X-ME-Proxy: Feedback-ID: i197146af:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 9 Nov 2023 02:09:58 -0500 (EST) Received: by vm-mail (OpenSMTPD) with ESMTPSA id a83fba48 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 9 Nov 2023 07:09:31 +0000 (UTC) Date: Thu, 9 Nov 2023 08:09:56 +0100 From: Patrick Steinhardt To: git@vger.kernel.org Cc: Jeff King , Junio C Hamano Subject: [PATCH v3 2/3] t/lib-httpd: stop using legacy crypt(3) for authentication Message-ID: <3dce76da477852e5e6964ea20cad2bfe2788a96f.1699513524.git.ps@pks.im> References: Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: When setting up httpd for our tests, we also install a passwd and proxy-passwd file that contain the test user's credentials. These credentials currently use crypt(3) as the password encryption schema. This schema can be considered deprecated nowadays as it is not safe anymore. Quoting Apache httpd's documentation [1]: > Unix only. Uses the traditional Unix crypt(3) function with a > randomly-generated 32-bit salt (only 12 bits used) and the first 8 > characters of the password. Insecure. This is starting to cause issues in modern Linux distributions. glibc has deprecated its libcrypt library that used to provide crypt(3) in favor of the libxcrypt library. This newer replacement provides a compile time switch to disable insecure password encryption schemata, which causes crypt(3) to always return `EINVAL`. The end result is that httpd tests that exercise authentication will fail on distros that use libxcrypt without these insecure encryption schematas. Regenerate the passwd files to instead use the default password encryption schema, which is md5. While it feels kind of funny that an MD5-based encryption schema should be more secure than anything else, it is the current default and supported by all platforms. Furthermore, it really doesn't matter all that much given that these files are only used for testing purposes anyway. [1]: https://httpd.apache.org/docs/2.4/misc/password_encryptions.html Signed-off-by: Patrick Steinhardt --- t/lib-httpd/passwd | 2 +- t/lib-httpd/proxy-passwd | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/t/lib-httpd/passwd b/t/lib-httpd/passwd index 99a34d64874..d9c122f3482 100644 --- a/t/lib-httpd/passwd +++ b/t/lib-httpd/passwd @@ -1 +1 @@ -user@host:xb4E8pqD81KQs +user@host:$apr1$LGPmCZWj$9vxEwj5Z5GzQLBMxp3mCx1 diff --git a/t/lib-httpd/proxy-passwd b/t/lib-httpd/proxy-passwd index 77c25138e07..2ad7705d9a3 100644 --- a/t/lib-httpd/proxy-passwd +++ b/t/lib-httpd/proxy-passwd @@ -1 +1 @@ -proxuser:2x7tAukjAED5M +proxuser:$apr1$RxS6MLkD$DYsqQdflheq4GPNxzJpx5. From patchwork Thu Nov 9 07:10:01 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick Steinhardt X-Patchwork-Id: 13450684 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 82D7AFC11 for ; Thu, 9 Nov 2023 07:10:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pks.im header.i=@pks.im header.b="afZeYYFy"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="S3i4YNQl" Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0BADA211D for ; Wed, 8 Nov 2023 23:10:04 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.nyi.internal (Postfix) with ESMTP id 6499D5C02B0; Thu, 9 Nov 2023 02:10:04 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 09 Nov 2023 02:10:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pks.im; h=cc:cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1699513804; x=1699600204; bh=03 HUJ2E3pPYRi+zAhg2WIJc7LtC7AQy0iFUvlWLdtxw=; b=afZeYYFybLJgZKEkW1 bC71cZyvjI+5c5xJ14I8KoDkEswFwzoaXZteOUdinIwdltExRo6FJyd1ge3IAMUG 4sAKZ6GqiZv1zdbSmTLIMI+YcT0Fq5WYWi0aEcDh0mVvwWCK5Gd+cjp3+zSujNFt UZ2RF+IZYsLgnHUafFNYkbPiJ9GKWgt364Wc19GO05L5LHUVXuGfTq57rVlDHNxi 58JeGJY4MOXGdmF1WOLhUaxuIjvI5B59npnmkk7xF/SeYeB1guB2VqiZp1OwGxri QEzBEkXmhFKP+zN67klVLIdHtglqmOgH6AoWFYQLb55sgmTWcARNU6til1KOEt7E XfFQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1699513804; x=1699600204; bh=03HUJ2E3pPYRi +zAhg2WIJc7LtC7AQy0iFUvlWLdtxw=; b=S3i4YNQly/4W2gU97wOlnvc/xScfj LS+2KxQ6h+RkHVtSYJupYDZ4pyqdHZVmFg1XZxPWTx8EnqMFVagutW4Gri8DVHTb TqbM3tPntzBPyabLoVbjXjWGDftjATUGuRDrGcvQ17Q5F2mGHOmnjFACP4mGajls 16LBnTSLrGJ2YoABxRC+cNvDeNG4QHGafci4gjpLwSnCv3WgIDW7iadsFo+ZKjK7 zHRfV9v012k/3/lyUSe32dwSFQJa83dn7DExwcs1p5VW+pM1OLz6QehSr3BXvBZ9 Z/2g9ZLVShlWXEAOr0olHTNALgrZENg9ZWBAPTC4v+eGAP6r5m0MzWjQg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddvtddguddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvfevuffkfhggtggujgesgh dtreertddtvdenucfhrhhomheprfgrthhrihgtkhcuufhtvghinhhhrghrughtuceophhs sehpkhhsrdhimheqnecuggftrfgrthhtvghrnhepueektdevtdffveeljeetgfehheeige ekleduvdeffeeghefgledttdehjeelffetnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepphhssehpkhhsrdhimh X-ME-Proxy: Feedback-ID: i197146af:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 9 Nov 2023 02:10:03 -0500 (EST) Received: by vm-mail (OpenSMTPD) with ESMTPSA id 8c18fcdb (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 9 Nov 2023 07:09:36 +0000 (UTC) Date: Thu, 9 Nov 2023 08:10:01 +0100 From: Patrick Steinhardt To: git@vger.kernel.org Cc: Jeff King , Junio C Hamano Subject: [PATCH v3 3/3] t9164: fix inability to find basename(1) in Subversion hooks Message-ID: <6891e2541552073c6827d81d2b761252f253bea2.1699513524.git.ps@pks.im> References: Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Hooks executed by Subversion are spawned with an empty environment. By default, not even variables like PATH will be propagated to them. In order to ensure that we're still able to find required executables, we thus write the current PATH variable into the hook script itself and then re-export it in t9164. This happens too late in the script though, as we already tried to execute the basename(1) utility before exporting the PATH variable. This tends to work on most platforms as the fallback value of PATH for Bash (see `getconf PATH`) is likely to contain this binary. But on more exotic platforms like NixOS this is not the case, and thus the test fails. While we could work around this issue by simply setting PATH earlier, it feels fragile to inject a user-controlled value into the script and have the shell interpret it. Instead, we can refactor the hook setup to write a `hooks-env` file that configures PATH for us. Like this, Subversion will know to set up the environment as expected for all hooks. Signed-off-by: Patrick Steinhardt --- t/t9164-git-svn-dcommit-concurrent.sh | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/t/t9164-git-svn-dcommit-concurrent.sh b/t/t9164-git-svn-dcommit-concurrent.sh index c8e6c0733f4..d1dec89c3b7 100755 --- a/t/t9164-git-svn-dcommit-concurrent.sh +++ b/t/t9164-git-svn-dcommit-concurrent.sh @@ -46,6 +46,14 @@ setup_hook() "passed to setup_hook" >&2 ; return 1; } echo "cnt=$skip_revs" > "$hook_type-counter" rm -f "$rawsvnrepo/hooks/"*-commit # drop previous hooks + + # Subversion hooks run with an empty environment by default. We thus + # need to propagate PATH so that we can find executables. + cat >"$rawsvnrepo/conf/hooks-env" <<-EOF + [default] + PATH = ${PATH} + EOF + hook="$rawsvnrepo/hooks/$hook_type" cat > "$hook" <<- 'EOF1' #!/bin/sh @@ -63,7 +71,6 @@ EOF1 if [ "$hook_type" = "pre-commit" ]; then echo "echo 'commit disallowed' >&2; exit 1" >>"$hook" else - echo "PATH=\"$PATH\"; export PATH" >>"$hook" echo "svnconf=\"$svnconf\"" >>"$hook" cat >>"$hook" <<- 'EOF2' cd work-auto-commits.svn