{"thread":{"id":"63340","subject":"[PATCH 0/2] meson: prefer '/bin/sh' over PATH lookup","startedAt":"2025-04-24T13:38:25Z","lastAt":"2025-05-05T06:08:57Z","messageCount":31,"participants":["Patrick Steinhardt","Junio C Hamano","Justin Tobler","Eli Schwartz","Toon Claes","brian m. carlson"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"516671","messageId":"20250424-pks-meson-posix-shell-v1-0-45e06ee4b6ad@pks.im","threadId":"63340","inReplyTo":null,"subject":"[PATCH 0/2] meson: prefer '/bin/sh' over PATH lookup","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-04-24T13:38:13Z","receivedAt":"2025-04-24T13:38:25Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Hi,\n\nat GitLab, we recently got a couple of bug reports about Git not being\nable to find its shell anymore. The root cause is that with Meson we\nhave started to look up the shell via PATH, which may exist on the build\nhost, but not on the target host. We have worked around this issue with\na cross file:\n\n    $ cat >cross.ini <<-EOF\n    [binaries]\n    sh = '/bin/sh'\n    EOF\n    $ meson setup build --cross-file=./cross.ini\n\nBut this made me remember the report from Peter [1] that Debian also\nfaced this issue. So I decided to address the issue in Meson directly by\npreferring `/bin/sh` over a PATH-based lookup.\n\nThanks!\n\nPatrick\n\n[1]: <20250209133027.64a865aa@gmx.net>\n\n---\nPatrick Steinhardt (2):\n      meson: report detected runtime executable paths\n      meson: prefer POSIX-specified shell path\n\n meson.build | 8 +++++++-\n 1 file changed, 7 insertions(+), 1 deletion(-)\n\n\n---\nbase-commit: a2955b34f48265d240ab8c7deb0a929ec2d65fd0\nchange-id: 20250424-pks-meson-posix-shell-4969161025c5\n\n"},{"id":"516672","messageId":"20250424-pks-meson-posix-shell-v1-2-45e06ee4b6ad@pks.im","threadId":"63340","inReplyTo":"20250424-pks-meson-posix-shell-v1-0-45e06ee4b6ad@pks.im","subject":"[PATCH 2/2] meson: prefer POSIX-specified shell path","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-04-24T13:38:15Z","receivedAt":"2025-04-24T13:38:26Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Meson detects the path of the target shell via `find_program(\"sh\")`,\nwhich essentially does a lookup via `PATH`. This may easily lead to a\nsubtly-broken Git distribution when the build host has its shell in a\nnon-standard location that the target host doesn't know about.\n\nFix the issue by appending \"/bin\" to the custom program path, which\ncauses us to prefer \"/bin/sh\" over a `PATH` lookup. As this location is\nspecified by POSIX this should make us pick a better default shell path\non all POSIX-compliant systems.\n\nNote that we intentionally append, not prepend, to the custom program\npath. This is because the program path can be configured by the user via\nthe `-Dsane_tool_path=` build option, which should take precedence over\nany defaults we pick for the user.\n\nSigned-off-by: Patrick Steinhardt <ps@pks.im>\n---\n meson.build | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/meson.build b/meson.build\nindex 8f04534c7ff..1db768380bd 100644\n--- a/meson.build\n+++ b/meson.build\n@@ -236,7 +236,7 @@ sed = find_program('sed', dirs: program_path, native: true)\n shell = find_program('sh', dirs: program_path, native: true)\n tar = find_program('tar', dirs: program_path, native: true)\n \n-target_shell = find_program('sh', dirs: program_path, native: false)\n+target_shell = find_program('sh', dirs: program_path + [ '/bin' ], native: false)\n \n # Sanity-check that programs required for the build exist.\n foreach tool : ['cat', 'cut', 'grep', 'sort', 'tr', 'uname']\n\n-- \n2.49.0.901.g37484f566f.dirty\n\n"},{"id":"516673","messageId":"20250424-pks-meson-posix-shell-v1-1-45e06ee4b6ad@pks.im","threadId":"63340","inReplyTo":"20250424-pks-meson-posix-shell-v1-0-45e06ee4b6ad@pks.im","subject":"[PATCH 1/2] meson: report detected runtime executable paths","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-04-24T13:38:14Z","receivedAt":"2025-04-24T13:38:26Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Git needs to know about a couple of executable paths to pick at runtime.\nThis includes the system shell, but may also optionally include the Perl\nand Python interpreters. Meson detects the location of these paths\nautomatically via `find_program()`, which does a lookup via the `PATH`\nenvironment variable. As such, it may not be immediately obvious to the\ndeveloper which paths have been autodetected.\n\nImprove this by exposing runtime executable paths at setup time.\n\nSigned-off-by: Patrick Steinhardt <ps@pks.im>\n---\n meson.build | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/meson.build b/meson.build\nindex c47cb79af08..8f04534c7ff 100644\n--- a/meson.build\n+++ b/meson.build\n@@ -2080,3 +2080,9 @@ summary({\n   'sha256': sha256_backend,\n   'zlib': zlib_backend,\n }, section: 'Backends')\n+\n+summary({\n+  'perl': target_perl.found() ? target_perl.full_path() : 'none',\n+  'python': target_python.found() ? target_python.full_path() : 'none',\n+  'shell': target_shell.full_path(),\n+}, section: 'Runtime executable paths')\n\n-- \n2.49.0.901.g37484f566f.dirty\n\n"},{"id":"516683","messageId":"xmqq7c39v2gh.fsf@gitster.g","threadId":"63340","inReplyTo":"20250424-pks-meson-posix-shell-v1-0-45e06ee4b6ad@pks.im","subject":"Re: [PATCH 0/2] meson: prefer '/bin/sh' over PATH lookup","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-04-24T18:28:30Z","receivedAt":"2025-04-24T18:28:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> at GitLab, we recently got a couple of bug reports about Git not being\n> able to find its shell anymore. The root cause is that with Meson we\n> have started to look up the shell via PATH, which may exist on the build\n> host, but not on the target host. We have worked around this issue with\n> a cross file:\n>\n>     $ cat >cross.ini <<-EOF\n>     [binaries]\n>     sh = '/bin/sh'\n>     EOF\n>     $ meson setup build --cross-file=./cross.ini\n>\n> But this made me remember the report from Peter [1] that Debian also\n> faced this issue. So I decided to address the issue in Meson directly by\n> preferring `/bin/sh` over a PATH-based lookup.\n\nPerhaps use the same SHELL_PATH environment Makefile based build\nhas used for ages?  That way, those who are dipping their toes and\npossibly migrating to Meson based build eventually would know what\nthey want to twaek, no?\n"},{"id":"516687","messageId":"m2egcx4i2nezlwlyioofnz4srjgbyhb4dkyrpi5crnt5uwuvy3@a7tbji5lrnvn","threadId":"63340","inReplyTo":"20250424-pks-meson-posix-shell-v1-2-45e06ee4b6ad@pks.im","subject":"Re: [PATCH 2/2] meson: prefer POSIX-specified shell path","fromName":"Justin Tobler","fromEmail":"jltobler@gmail.com","sentAt":"2025-04-24T20:18:29Z","receivedAt":"2025-04-24T20:22:38Z","isPatch":true,"sender":{"key":"jltobler@gmail.com","avatar":"https://avatars.githubusercontent.com/u/53454972?v=4"},"body":"On 25/04/24 03:38PM, Patrick Steinhardt wrote:\n> Meson detects the path of the target shell via `find_program(\"sh\")`,\n> which essentially does a lookup via `PATH`. This may easily lead to a\n> subtly-broken Git distribution when the build host has its shell in a\n> non-standard location that the target host doesn't know about.\n\nOk, so we run into this issue if the shell path picked up from the build\nhost's $PATH doesn't exist on the target host. Makes sense.\n\n> Fix the issue by appending \"/bin\" to the custom program path, which\n> causes us to prefer \"/bin/sh\" over a `PATH` lookup. As this location is\n> specified by POSIX this should make us pick a better default shell path\n> on all POSIX-compliant systems.\n\nSo if the build host has \"/bin/sh\", but the target host doesn't we would\nstill have an issue, but that is still probably a better default. I\nguess now $PATH would only be used as the fallback if the build host is\neven most non-standard.\n\n> Note that we intentionally append, not prepend, to the custom program\n> path. This is because the program path can be configured by the user via\n> the `-Dsane_tool_path=` build option, which should take precedence over\n> any defaults we pick for the user.\n\nIIUC, then the order precedence is \"program_path\", \"/bin\", and finally\n$PATH. That makes sense.\n\n> Signed-off-by: Patrick Steinhardt <ps@pks.im>\n> ---\n>  meson.build | 2 +-\n>  1 file changed, 1 insertion(+), 1 deletion(-)\n> \n> diff --git a/meson.build b/meson.build\n> index 8f04534c7ff..1db768380bd 100644\n> --- a/meson.build\n> +++ b/meson.build\n> @@ -236,7 +236,7 @@ sed = find_program('sed', dirs: program_path, native: true)\n>  shell = find_program('sh', dirs: program_path, native: true)\n>  tar = find_program('tar', dirs: program_path, native: true)\n>  \n> -target_shell = find_program('sh', dirs: program_path, native: false)\n> +target_shell = find_program('sh', dirs: program_path + [ '/bin' ], native: false)\n\nIt might be nice to leave a comment explaining the ordering intent.\n\n>  # Sanity-check that programs required for the build exist.\n>  foreach tool : ['cat', 'cut', 'grep', 'sort', 'tr', 'uname']\n\n-Justin\n"},{"id":"516712","messageId":"43e86c8f-904b-4572-b84d-009c203fda11@gentoo.org","threadId":"63340","inReplyTo":"20250424-pks-meson-posix-shell-v1-1-45e06ee4b6ad@pks.im","subject":"Re: [PATCH 1/2] meson: report detected runtime executable paths","fromName":"Eli Schwartz","fromEmail":"eschwartz@gentoo.org","sentAt":"2025-04-25T00:45:44Z","receivedAt":"2025-04-25T00:45:48Z","isPatch":true,"sender":{"key":"eschwartz@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/6551424?v=4"},"body":"On 4/24/25 9:38 AM, Patrick Steinhardt wrote:\n> Git needs to know about a couple of executable paths to pick at runtime.\n> This includes the system shell, but may also optionally include the Perl\n> and Python interpreters. Meson detects the location of these paths\n> automatically via `find_program()`, which does a lookup via the `PATH`\n> environment variable. As such, it may not be immediately obvious to the\n> developer which paths have been autodetected.\n> \n> Improve this by exposing runtime executable paths at setup time.\n> \n> Signed-off-by: Patrick Steinhardt <ps@pks.im>\n> ---\n>  meson.build | 6 ++++++\n>  1 file changed, 6 insertions(+)\n> \n> diff --git a/meson.build b/meson.build\n> index c47cb79af08..8f04534c7ff 100644\n> --- a/meson.build\n> +++ b/meson.build\n> @@ -2080,3 +2080,9 @@ summary({\n>    'sha256': sha256_backend,\n>    'zlib': zlib_backend,\n>  }, section: 'Backends')\n> +\n> +summary({\n> +  'perl': target_perl.found() ? target_perl.full_path() : 'none',\n> +  'python': target_python.found() ? target_python.full_path() : 'none',\n> +  'shell': target_shell.full_path(),\n> +}, section: 'Runtime executable paths')\n\nsummary({\n  'perl': target_perl,\n  'python': target_python,\n  'shell': target_shell,\n}, section: 'Runtime executable paths')\n\n\nNo need to check if they are found. Meson will print the full_path()\nalready, if it is found, and if it is not found, it will print \"NO\" in\nits standard color code (red) for things-that-are-missing.\n\n\n\n\n-- \nEli Schwartz\n"},{"id":"516717","messageId":"aAsbwvtKTiZFRnXM@pks.im","threadId":"63340","inReplyTo":"43e86c8f-904b-4572-b84d-009c203fda11@gentoo.org","subject":"Re: [PATCH 1/2] meson: report detected runtime executable paths","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-04-25T05:21:06Z","receivedAt":"2025-04-25T05:21:15Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Thu, Apr 24, 2025 at 08:45:44PM -0400, Eli Schwartz wrote:\n> On 4/24/25 9:38 AM, Patrick Steinhardt wrote:\n> > diff --git a/meson.build b/meson.build\n> > index c47cb79af08..8f04534c7ff 100644\n> > --- a/meson.build\n> > +++ b/meson.build\n> > @@ -2080,3 +2080,9 @@ summary({\n> >    'sha256': sha256_backend,\n> >    'zlib': zlib_backend,\n> >  }, section: 'Backends')\n> > +\n> > +summary({\n> > +  'perl': target_perl.found() ? target_perl.full_path() : 'none',\n> > +  'python': target_python.found() ? target_python.full_path() : 'none',\n> > +  'shell': target_shell.full_path(),\n> > +}, section: 'Runtime executable paths')\n> \n> summary({\n>   'perl': target_perl,\n>   'python': target_python,\n>   'shell': target_shell,\n> }, section: 'Runtime executable paths')\n> \n> \n> No need to check if they are found. Meson will print the full_path()\n> already, if it is found, and if it is not found, it will print \"NO\" in\n> its standard color code (red) for things-that-are-missing.\n\nOh, that's much nicer indeed. Thanks!\n\nPatrick\n"},{"id":"516718","messageId":"aAsb1UCPZyiMcqy2@pks.im","threadId":"63340","inReplyTo":"xmqq7c39v2gh.fsf@gitster.g","subject":"Re: [PATCH 0/2] meson: prefer '/bin/sh' over PATH lookup","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-04-25T05:21:25Z","receivedAt":"2025-04-25T05:21:29Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Thu, Apr 24, 2025 at 11:28:30AM -0700, Junio C Hamano wrote:\n> Patrick Steinhardt <ps@pks.im> writes:\n> \n> > at GitLab, we recently got a couple of bug reports about Git not being\n> > able to find its shell anymore. The root cause is that with Meson we\n> > have started to look up the shell via PATH, which may exist on the build\n> > host, but not on the target host. We have worked around this issue with\n> > a cross file:\n> >\n> >     $ cat >cross.ini <<-EOF\n> >     [binaries]\n> >     sh = '/bin/sh'\n> >     EOF\n> >     $ meson setup build --cross-file=./cross.ini\n> >\n> > But this made me remember the report from Peter [1] that Debian also\n> > faced this issue. So I decided to address the issue in Meson directly by\n> > preferring `/bin/sh` over a PATH-based lookup.\n> \n> Perhaps use the same SHELL_PATH environment Makefile based build\n> has used for ages?  That way, those who are dipping their toes and\n> possibly migrating to Meson based build eventually would know what\n> they want to twaek, no?\n\nYeah, that's basically what we do with this patch series now. How\nexactly this is wired up is different compared to our Makefile so that\nusers can use Meson features to override this, e.g native files. But the\nend result is the same on all POSIX-compliant systems that have\n'/bin/sh'.\n\nPatrick\n"},{"id":"516719","messageId":"aAsb2SEbxatCw9Zs@pks.im","threadId":"63340","inReplyTo":"m2egcx4i2nezlwlyioofnz4srjgbyhb4dkyrpi5crnt5uwuvy3@a7tbji5lrnvn","subject":"Re: [PATCH 2/2] meson: prefer POSIX-specified shell path","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-04-25T05:21:29Z","receivedAt":"2025-04-25T05:21:32Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Thu, Apr 24, 2025 at 03:18:29PM -0500, Justin Tobler wrote:\n> On 25/04/24 03:38PM, Patrick Steinhardt wrote:\n> > diff --git a/meson.build b/meson.build\n> > index 8f04534c7ff..1db768380bd 100644\n> > --- a/meson.build\n> > +++ b/meson.build\n> > @@ -236,7 +236,7 @@ sed = find_program('sed', dirs: program_path, native: true)\n> >  shell = find_program('sh', dirs: program_path, native: true)\n> >  tar = find_program('tar', dirs: program_path, native: true)\n> >  \n> > -target_shell = find_program('sh', dirs: program_path, native: false)\n> > +target_shell = find_program('sh', dirs: program_path + [ '/bin' ], native: false)\n> \n> It might be nice to leave a comment explaining the ordering intent.\n\nWill do.\n\nPatrick\n"},{"id":"516728","messageId":"20250425-pks-meson-posix-shell-v2-0-fddc6123511b@pks.im","threadId":"63340","inReplyTo":"20250424-pks-meson-posix-shell-v1-0-45e06ee4b6ad@pks.im","subject":"[PATCH v2 0/2] meson: prefer '/bin/sh' over PATH lookup","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-04-25T05:47:43Z","receivedAt":"2025-04-25T05:47:49Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Hi,\n\nat GitLab, we recently got a couple of bug reports about Git not being\nable to find its shell anymore. The root cause is that with Meson we\nhave started to look up the shell via PATH, which may exist on the build\nhost, but not on the target host. We have worked around this issue with\na cross file:\n\n    $ cat >cross.ini <<-EOF\n    [binaries]\n    sh = '/bin/sh'\n    EOF\n    $ meson setup build --cross-file=./cross.ini\n\nBut this made me remember the report from Peter [1] that Debian also\nfaced this issue. So I decided to address the issue in Meson directly by\npreferring `/bin/sh` over a PATH-based lookup.\n\nChanges in v2:\n  - Simplify how we generate the summary.\n  - Add a comment to explain ordering of the program path.\n  - Link to v1: https://lore.kernel.org/r/20250424-pks-meson-posix-shell-v1-0-45e06ee4b6ad@pks.im\n\nThanks!\n\nPatrick\n\n[1]: <20250209133027.64a865aa@gmx.net>\n\n---\nPatrick Steinhardt (2):\n      meson: report detected runtime executable paths\n      meson: prefer POSIX-specified shell path\n\n meson.build | 11 ++++++++++-\n 1 file changed, 10 insertions(+), 1 deletion(-)\n\nRange-diff versus v1:\n\n1:  cdb4db30677 ! 1:  b606f3ffe2e meson: report detected runtime executable paths\n    @@ meson.build: summary({\n      }, section: 'Backends')\n     +\n     +summary({\n    -+  'perl': target_perl.found() ? target_perl.full_path() : 'none',\n    -+  'python': target_python.found() ? target_python.full_path() : 'none',\n    -+  'shell': target_shell.full_path(),\n    ++  'perl': target_perl,\n    ++  'python': target_python,\n    ++  'shell': target_shell,\n     +}, section: 'Runtime executable paths')\n2:  d439c859fbb ! 2:  3804c32b879 meson: prefer POSIX-specified shell path\n    @@ meson.build: sed = find_program('sed', dirs: program_path, native: true)\n      tar = find_program('tar', dirs: program_path, native: true)\n      \n     -target_shell = find_program('sh', dirs: program_path, native: false)\n    ++# Detect the target shell that is used by Git at runtime. Note that we prefer\n    ++# '/bin/sh' over a PATH-based lookup given that '/bin/sh' is the location\n    ++# specified by POSIX. This lookup can be overridden via `program_path`.\n     +target_shell = find_program('sh', dirs: program_path + [ '/bin' ], native: false)\n      \n      # Sanity-check that programs required for the build exist.\n\n---\nbase-commit: a2955b34f48265d240ab8c7deb0a929ec2d65fd0\nchange-id: 20250424-pks-meson-posix-shell-4969161025c5\n\n"},{"id":"516729","messageId":"20250425-pks-meson-posix-shell-v2-1-fddc6123511b@pks.im","threadId":"63340","inReplyTo":"20250425-pks-meson-posix-shell-v2-0-fddc6123511b@pks.im","subject":"[PATCH v2 1/2] meson: report detected runtime executable paths","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-04-25T05:47:44Z","receivedAt":"2025-04-25T05:47:51Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Git needs to know about a couple of executable paths to pick at runtime.\nThis includes the system shell, but may also optionally include the Perl\nand Python interpreters. Meson detects the location of these paths\nautomatically via `find_program()`, which does a lookup via the `PATH`\nenvironment variable. As such, it may not be immediately obvious to the\ndeveloper which paths have been autodetected.\n\nImprove this by exposing runtime executable paths at setup time.\n\nSigned-off-by: Patrick Steinhardt <ps@pks.im>\n---\n meson.build | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/meson.build b/meson.build\nindex c47cb79af08..a180c66ee69 100644\n--- a/meson.build\n+++ b/meson.build\n@@ -2080,3 +2080,9 @@ summary({\n   'sha256': sha256_backend,\n   'zlib': zlib_backend,\n }, section: 'Backends')\n+\n+summary({\n+  'perl': target_perl,\n+  'python': target_python,\n+  'shell': target_shell,\n+}, section: 'Runtime executable paths')\n\n-- \n2.49.0.967.g6a0df3ecc3.dirty\n\n"},{"id":"516730","messageId":"20250425-pks-meson-posix-shell-v2-2-fddc6123511b@pks.im","threadId":"63340","inReplyTo":"20250425-pks-meson-posix-shell-v2-0-fddc6123511b@pks.im","subject":"[PATCH v2 2/2] meson: prefer POSIX-specified shell path","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-04-25T05:47:45Z","receivedAt":"2025-04-25T05:47:51Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Meson detects the path of the target shell via `find_program(\"sh\")`,\nwhich essentially does a lookup via `PATH`. This may easily lead to a\nsubtly-broken Git distribution when the build host has its shell in a\nnon-standard location that the target host doesn't know about.\n\nFix the issue by appending \"/bin\" to the custom program path, which\ncauses us to prefer \"/bin/sh\" over a `PATH` lookup. As this location is\nspecified by POSIX this should make us pick a better default shell path\non all POSIX-compliant systems.\n\nNote that we intentionally append, not prepend, to the custom program\npath. This is because the program path can be configured by the user via\nthe `-Dsane_tool_path=` build option, which should take precedence over\nany defaults we pick for the user.\n\nSigned-off-by: Patrick Steinhardt <ps@pks.im>\n---\n meson.build | 5 ++++-\n 1 file changed, 4 insertions(+), 1 deletion(-)\n\ndiff --git a/meson.build b/meson.build\nindex a180c66ee69..c0d0982b00f 100644\n--- a/meson.build\n+++ b/meson.build\n@@ -236,7 +236,10 @@ sed = find_program('sed', dirs: program_path, native: true)\n shell = find_program('sh', dirs: program_path, native: true)\n tar = find_program('tar', dirs: program_path, native: true)\n \n-target_shell = find_program('sh', dirs: program_path, native: false)\n+# Detect the target shell that is used by Git at runtime. Note that we prefer\n+# '/bin/sh' over a PATH-based lookup given that '/bin/sh' is the location\n+# specified by POSIX. This lookup can be overridden via `program_path`.\n+target_shell = find_program('sh', dirs: program_path + [ '/bin' ], native: false)\n \n # Sanity-check that programs required for the build exist.\n foreach tool : ['cat', 'cut', 'grep', 'sort', 'tr', 'uname']\n\n-- \n2.49.0.967.g6a0df3ecc3.dirty\n\n"},{"id":"516773","messageId":"877c38fxy7.fsf@iotcl.com","threadId":"63340","inReplyTo":"20250425-pks-meson-posix-shell-v2-1-fddc6123511b@pks.im","subject":"Re: [PATCH v2 1/2] meson: report detected runtime executable paths","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2025-04-25T08:27:12Z","receivedAt":"2025-04-25T08:27:27Z","isPatch":true,"sender":{"key":"toon@iotcl.com","avatar":"https://avatars.githubusercontent.com/u/121621?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> Git needs to know about a couple of executable paths to pick at runtime.\n> This includes the system shell, but may also optionally include the Perl\n> and Python interpreters. Meson detects the location of these paths\n> automatically via `find_program()`, which does a lookup via the `PATH`\n> environment variable. As such, it may not be immediately obvious to the\n> developer which paths have been autodetected.\n>\n> Improve this by exposing runtime executable paths at setup time.\n>\n> Signed-off-by: Patrick Steinhardt <ps@pks.im>\n> ---\n>  meson.build | 6 ++++++\n>  1 file changed, 6 insertions(+)\n>\n> diff --git a/meson.build b/meson.build\n> index c47cb79af08..a180c66ee69 100644\n> --- a/meson.build\n> +++ b/meson.build\n> @@ -2080,3 +2080,9 @@ summary({\n>    'sha256': sha256_backend,\n>    'zlib': zlib_backend,\n>  }, section: 'Backends')\n> +\n> +summary({\n> +  'perl': target_perl,\n> +  'python': target_python,\n> +  'shell': target_shell,\n> +}, section: 'Runtime executable paths')\n\nI appreciate this change. Without [PATCH 2/2] applied I'm getting:\n\n  Runtime executable paths\n    perl         : /usr/bin/perl\n    python       : /usr/bin/python3\n    shell        : /usr/bin/sh\n\nAnd with [PATHCH 2/2] I'm getting:\n\n  Runtime executable paths\n    perl         : /usr/bin/perl\n    python       : /usr/bin/python3\n    shell        : /bin/sh\n\nAs expected. :+1:\n\n--\nToon\n"},{"id":"516775","messageId":"874iycfxl6.fsf@iotcl.com","threadId":"63340","inReplyTo":"20250425-pks-meson-posix-shell-v2-2-fddc6123511b@pks.im","subject":"Re: [PATCH v2 2/2] meson: prefer POSIX-specified shell path","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2025-04-25T08:35:01Z","receivedAt":"2025-04-25T08:35:12Z","isPatch":true,"sender":{"key":"toon@iotcl.com","avatar":"https://avatars.githubusercontent.com/u/121621?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> Meson detects the path of the target shell via `find_program(\"sh\")`,\n> which essentially does a lookup via `PATH`. This may easily lead to a\n> subtly-broken Git distribution when the build host has its shell in a\n> non-standard location that the target host doesn't know about.\n>\n> Fix the issue by appending \"/bin\" to the custom program path, which\n> causes us to prefer \"/bin/sh\" over a `PATH` lookup. As this location is\n> specified by POSIX this should make us pick a better default shell path\n> on all POSIX-compliant systems.\n>\n> Note that we intentionally append, not prepend, to the custom program\n> path. This is because the program path can be configured by the user via\n> the `-Dsane_tool_path=` build option, which should take precedence over\n> any defaults we pick for the user.\n>\n> Signed-off-by: Patrick Steinhardt <ps@pks.im>\n> ---\n>  meson.build | 5 ++++-\n>  1 file changed, 4 insertions(+), 1 deletion(-)\n>\n> diff --git a/meson.build b/meson.build\n> index a180c66ee69..c0d0982b00f 100644\n> --- a/meson.build\n> +++ b/meson.build\n> @@ -236,7 +236,10 @@ sed = find_program('sed', dirs: program_path, native: true)\n>  shell = find_program('sh', dirs: program_path, native: true)\n>  tar = find_program('tar', dirs: program_path, native: true)\n>  \n> -target_shell = find_program('sh', dirs: program_path, native: false)\n> +# Detect the target shell that is used by Git at runtime. Note that we prefer\n> +# '/bin/sh' over a PATH-based lookup given that '/bin/sh' is the location\n> +# specified by POSIX. This lookup can be overridden via `program_path`.\n> +target_shell = find_program('sh', dirs: program_path + [ '/bin' ], native: false)\n\nIt was not instantly obvious to me, but this is what the docs[1] say\nabout the use of `dirs` in `find_program()`:\n\n   extra list of absolute paths where to look for program names\n\nSo the function *first* looks in `dirs` *before* it looks in $PATH. I\nwasn't fully aware what `program_path` contained, but I assumed it had\nto contain the dirs in $PATH. But it seems $PATH is searched if the\nprogram is not found in `dirs`.\n\nSo I agree with these changes.\n\n[1]: https://mesonbuild.com/Reference-manual_functions.html#find_program\n\n--\nToon\n"},{"id":"516786","messageId":"aAtopiMkJpF2RdjG@tapette.crustytoothpaste.net","threadId":"63340","inReplyTo":"20250425-pks-meson-posix-shell-v2-2-fddc6123511b@pks.im","subject":"Re: [PATCH v2 2/2] meson: prefer POSIX-specified shell path","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-04-25T10:49:10Z","receivedAt":"2025-04-25T10:49:18Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-04-25 at 05:47:45, Patrick Steinhardt wrote:\n> Meson detects the path of the target shell via `find_program(\"sh\")`,\n> which essentially does a lookup via `PATH`. This may easily lead to a\n> subtly-broken Git distribution when the build host has its shell in a\n> non-standard location that the target host doesn't know about.\n> \n> Fix the issue by appending \"/bin\" to the custom program path, which\n> causes us to prefer \"/bin/sh\" over a `PATH` lookup. As this location is\n> specified by POSIX this should make us pick a better default shell path\n> on all POSIX-compliant systems.\n\nCan you provide a citation for that?  I don't see that in the POSIX\n1003.1-2024 directory structure document[0].  More specifically, I think\nthere are some proprietary Unix systems where `/bin/sh` is the original\nBourne shell and is not POSIX compliant and some other path is the\nPOSIX-compliant `sh`.\n\nI'll also point out that we require more than POSIX compliance in that\nwe require `local`, so even if `/bin/sh` is POSIX compliant, that\ndoesn't mean that it's suitable for Git.  `/bin/sh` meets our needs on\nall the Linux distros I'm aware of, plus the BSDs, but if it were AT&T\nksh, that would not meet our needs since it doesn't support `local`,\neven though it's POSIX compliant.\n\n[0] https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap10.html\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"516787","messageId":"871ptgfpr0.fsf@iotcl.com","threadId":"63340","inReplyTo":"20250425-pks-meson-posix-shell-v2-0-fddc6123511b@pks.im","subject":"Re: [PATCH v2 0/2] meson: prefer '/bin/sh' over PATH lookup","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2025-04-25T11:24:19Z","receivedAt":"2025-04-25T11:24:32Z","isPatch":true,"sender":{"key":"toon@iotcl.com","avatar":"https://avatars.githubusercontent.com/u/121621?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> Hi,\n>\n> at GitLab, we recently got a couple of bug reports about Git not being\n> able to find its shell anymore. The root cause is that with Meson we\n> have started to look up the shell via PATH, which may exist on the build\n> host, but not on the target host. We have worked around this issue with\n> a cross file:\n>\n>     $ cat >cross.ini <<-EOF\n>     [binaries]\n>     sh = '/bin/sh'\n>     EOF\n>     $ meson setup build --cross-file=./cross.ini\n>\n> But this made me remember the report from Peter [1] that Debian also\n> faced this issue. So I decided to address the issue in Meson directly by\n> preferring `/bin/sh` over a PATH-based lookup.\n>\n> Changes in v2:\n>   - Simplify how we generate the summary.\n>   - Add a comment to explain ordering of the program path.\n>   - Link to v1: https://lore.kernel.org/r/20250424-pks-meson-posix-shell-v1-0-45e06ee4b6ad@pks.im\n>\n> Thanks!\n>\n> Patrick\n\nReviewed and looks good to me. It behaves as explained, although I don't\nknow how to easily test the original error we've been seeing.\n\n-- \nToon\n"},{"id":"516791","messageId":"aAt3Yc1NVZxsvSVX@pks.im","threadId":"63340","inReplyTo":"aAtopiMkJpF2RdjG@tapette.crustytoothpaste.net","subject":"Re: [PATCH v2 2/2] meson: prefer POSIX-specified shell path","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-04-25T11:52:01Z","receivedAt":"2025-04-25T11:52:06Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Fri, Apr 25, 2025 at 10:49:10AM +0000, brian m. carlson wrote:\n> On 2025-04-25 at 05:47:45, Patrick Steinhardt wrote:\n> > Meson detects the path of the target shell via `find_program(\"sh\")`,\n> > which essentially does a lookup via `PATH`. This may easily lead to a\n> > subtly-broken Git distribution when the build host has its shell in a\n> > non-standard location that the target host doesn't know about.\n> > \n> > Fix the issue by appending \"/bin\" to the custom program path, which\n> > causes us to prefer \"/bin/sh\" over a `PATH` lookup. As this location is\n> > specified by POSIX this should make us pick a better default shell path\n> > on all POSIX-compliant systems.\n> \n> Can you provide a citation for that?  I don't see that in the POSIX\n> 1003.1-2024 directory structure document[0].  More specifically, I think\n> there are some proprietary Unix systems where `/bin/sh` is the original\n> Bourne shell and is not POSIX compliant and some other path is the\n> POSIX-compliant `sh`.\n\nHrmpf, you're right. I feel like I relearn this piece of trivia every\ncouple years. POSIX is quite specific here:\n\n    Applications should note that the standard PATH to the shell cannot\n    be assumed to be either /bin/sh or /usr/bin/sh, and should be\n    determined by interrogation of the PATH returned by getconf PATH ,\n    ensuring that the returned pathname is an absolute pathname and not\n    a shell built-in.\n\nAnyway, given the following...\n\n> I'll also point out that we require more than POSIX compliance in that\n> we require `local`, so even if `/bin/sh` is POSIX compliant, that\n> doesn't mean that it's suitable for Git.  `/bin/sh` meets our needs on\n> all the Linux distros I'm aware of, plus the BSDs, but if it were AT&T\n> ksh, that would not meet our needs since it doesn't support `local`,\n> even though it's POSIX compliant.\n\n... prefering \"/bin/sh\" is still the right thing to do as it tends to\nwork on most systems supported by us, even though it's non-POSIX. But in\nany case, the commit message needs to be adjusted.\n\nThanks!\n\nPatrick\n"},{"id":"516800","messageId":"20250425-pks-meson-posix-shell-v3-0-01607a2e9334@pks.im","threadId":"63340","inReplyTo":"20250424-pks-meson-posix-shell-v1-0-45e06ee4b6ad@pks.im","subject":"[PATCH v3 0/2] meson: prefer '/bin/sh' over PATH lookup","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-04-25T14:11:27Z","receivedAt":"2025-04-25T14:11:33Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Hi,\n\nat GitLab, we recently got a couple of bug reports about Git not being\nable to find its shell anymore. The root cause is that with Meson we\nhave started to look up the shell via PATH, which may exist on the build\nhost, but not on the target host. We have worked around this issue with\na cross file:\n\n    $ cat >cross.ini <<-EOF\n    [binaries]\n    sh = '/bin/sh'\n    EOF\n    $ meson setup build --cross-file=./cross.ini\n\nBut this made me remember the report from Peter [1] that Debian also\nfaced this issue. So I decided to address the issue in Meson directly by\npreferring `/bin/sh` over a PATH-based lookup.\n\nChanges in v2:\n  - Simplify how we generate the summary.\n  - Add a comment to explain ordering of the program path.\n  - Link to v1: https://lore.kernel.org/r/20250424-pks-meson-posix-shell-v1-0-45e06ee4b6ad@pks.im\n\nChanges in v3:\n  - Stop claiming that \"/bin/sh\" is a POSIX-compliant path.\n  - Link to v2: https://lore.kernel.org/r/20250425-pks-meson-posix-shell-v2-0-fddc6123511b@pks.im\n\nThanks!\n\nPatrick\n\n[1]: <20250209133027.64a865aa@gmx.net>\n\n---\nPatrick Steinhardt (2):\n      meson: report detected runtime executable paths\n      meson: prefer shell at \"/bin/sh\"\n\n meson.build | 12 +++++++++++-\n 1 file changed, 11 insertions(+), 1 deletion(-)\n\nRange-diff versus v2:\n\n1:  e749055ac00 = 1:  750aa492d76 meson: report detected runtime executable paths\n2:  159a05d3533 ! 2:  d6417ba5ff6 meson: prefer POSIX-specified shell path\n    @@ Metadata\n     Author: Patrick Steinhardt <ps@pks.im>\n     \n      ## Commit message ##\n    -    meson: prefer POSIX-specified shell path\n    +    meson: prefer shell at \"/bin/sh\"\n     \n         Meson detects the path of the target shell via `find_program(\"sh\")`,\n         which essentially does a lookup via `PATH`. This may easily lead to a\n         subtly-broken Git distribution when the build host has its shell in a\n    -    non-standard location that the target host doesn't know about.\n    +    location that the target host doesn't know about.\n     \n         Fix the issue by appending \"/bin\" to the custom program path, which\n    -    causes us to prefer \"/bin/sh\" over a `PATH` lookup. As this location is\n    -    specified by POSIX this should make us pick a better default shell path\n    -    on all POSIX-compliant systems.\n    +    causes us to prefer \"/bin/sh\" over a `PATH`-based lookup. While\n    +    \"/bin/sh\" isn't standardized, this path tends to work alright on Linux\n    +    and BSD distributions. Furthermore, \"/bin/sh\" is also the path we pick\n    +    in our Makefile by default, which further demonstrates that this shell\n    +    fulfills our needs.\n     \n         Note that we intentionally append, not prepend, to the custom program\n         path. This is because the program path can be configured by the user via\n    @@ meson.build: sed = find_program('sed', dirs: program_path, native: true)\n      \n     -target_shell = find_program('sh', dirs: program_path, native: false)\n     +# Detect the target shell that is used by Git at runtime. Note that we prefer\n    -+# '/bin/sh' over a PATH-based lookup given that '/bin/sh' is the location\n    -+# specified by POSIX. This lookup can be overridden via `program_path`.\n    ++# \"/bin/sh\" over a PATH-based lookup, which provides a working shell on most\n    ++# supported systems. This path is also the default shell path used by our\n    ++# Makefile. This lookup can be overridden via `program_path`.\n     +target_shell = find_program('sh', dirs: program_path + [ '/bin' ], native: false)\n      \n      # Sanity-check that programs required for the build exist.\n\n---\nbase-commit: a2955b34f48265d240ab8c7deb0a929ec2d65fd0\nchange-id: 20250424-pks-meson-posix-shell-4969161025c5\n\n"},{"id":"516801","messageId":"20250425-pks-meson-posix-shell-v3-1-01607a2e9334@pks.im","threadId":"63340","inReplyTo":"20250425-pks-meson-posix-shell-v3-0-01607a2e9334@pks.im","subject":"[PATCH v3 1/2] meson: report detected runtime executable paths","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-04-25T14:11:28Z","receivedAt":"2025-04-25T14:11:34Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Git needs to know about a couple of executable paths to pick at runtime.\nThis includes the system shell, but may also optionally include the Perl\nand Python interpreters. Meson detects the location of these paths\nautomatically via `find_program()`, which does a lookup via the `PATH`\nenvironment variable. As such, it may not be immediately obvious to the\ndeveloper which paths have been autodetected.\n\nImprove this by exposing runtime executable paths at setup time.\n\nSigned-off-by: Patrick Steinhardt <ps@pks.im>\n---\n meson.build | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/meson.build b/meson.build\nindex c47cb79af08..a180c66ee69 100644\n--- a/meson.build\n+++ b/meson.build\n@@ -2080,3 +2080,9 @@ summary({\n   'sha256': sha256_backend,\n   'zlib': zlib_backend,\n }, section: 'Backends')\n+\n+summary({\n+  'perl': target_perl,\n+  'python': target_python,\n+  'shell': target_shell,\n+}, section: 'Runtime executable paths')\n\n-- \n2.49.0.901.g37484f566f.dirty\n\n"},{"id":"516802","messageId":"20250425-pks-meson-posix-shell-v3-2-01607a2e9334@pks.im","threadId":"63340","inReplyTo":"20250425-pks-meson-posix-shell-v3-0-01607a2e9334@pks.im","subject":"[PATCH v3 2/2] meson: prefer shell at \"/bin/sh\"","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-04-25T14:11:29Z","receivedAt":"2025-04-25T14:11:36Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Meson detects the path of the target shell via `find_program(\"sh\")`,\nwhich essentially does a lookup via `PATH`. This may easily lead to a\nsubtly-broken Git distribution when the build host has its shell in a\nlocation that the target host doesn't know about.\n\nFix the issue by appending \"/bin\" to the custom program path, which\ncauses us to prefer \"/bin/sh\" over a `PATH`-based lookup. While\n\"/bin/sh\" isn't standardized, this path tends to work alright on Linux\nand BSD distributions. Furthermore, \"/bin/sh\" is also the path we pick\nin our Makefile by default, which further demonstrates that this shell\nfulfills our needs.\n\nNote that we intentionally append, not prepend, to the custom program\npath. This is because the program path can be configured by the user via\nthe `-Dsane_tool_path=` build option, which should take precedence over\nany defaults we pick for the user.\n\nSigned-off-by: Patrick Steinhardt <ps@pks.im>\n---\n meson.build | 6 +++++-\n 1 file changed, 5 insertions(+), 1 deletion(-)\n\ndiff --git a/meson.build b/meson.build\nindex a180c66ee69..6a90310a2ca 100644\n--- a/meson.build\n+++ b/meson.build\n@@ -236,7 +236,11 @@ sed = find_program('sed', dirs: program_path, native: true)\n shell = find_program('sh', dirs: program_path, native: true)\n tar = find_program('tar', dirs: program_path, native: true)\n \n-target_shell = find_program('sh', dirs: program_path, native: false)\n+# Detect the target shell that is used by Git at runtime. Note that we prefer\n+# \"/bin/sh\" over a PATH-based lookup, which provides a working shell on most\n+# supported systems. This path is also the default shell path used by our\n+# Makefile. This lookup can be overridden via `program_path`.\n+target_shell = find_program('sh', dirs: program_path + [ '/bin' ], native: false)\n \n # Sanity-check that programs required for the build exist.\n foreach tool : ['cat', 'cut', 'grep', 'sort', 'tr', 'uname']\n\n-- \n2.49.0.901.g37484f566f.dirty\n\n"},{"id":"516817","messageId":"xmqq7c38urma.fsf@gitster.g","threadId":"63340","inReplyTo":"aAsbwvtKTiZFRnXM@pks.im","subject":"Re: [PATCH 1/2] meson: report detected runtime executable paths","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-04-25T16:34:53Z","receivedAt":"2025-04-25T16:34:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> On Thu, Apr 24, 2025 at 08:45:44PM -0400, Eli Schwartz wrote:\n>> On 4/24/25 9:38 AM, Patrick Steinhardt wrote:\n>> > diff --git a/meson.build b/meson.build\n>> > index c47cb79af08..8f04534c7ff 100644\n>> > --- a/meson.build\n>> > +++ b/meson.build\n>> > @@ -2080,3 +2080,9 @@ summary({\n>> >    'sha256': sha256_backend,\n>> >    'zlib': zlib_backend,\n>> >  }, section: 'Backends')\n>> > +\n>> > +summary({\n>> > +  'perl': target_perl.found() ? target_perl.full_path() : 'none',\n>> > +  'python': target_python.found() ? target_python.full_path() : 'none',\n>> > +  'shell': target_shell.full_path(),\n>> > +}, section: 'Runtime executable paths')\n>> \n>> summary({\n>>   'perl': target_perl,\n>>   'python': target_python,\n>>   'shell': target_shell,\n>> }, section: 'Runtime executable paths')\n>> \n>> \n>> No need to check if they are found. Meson will print the full_path()\n>> already, if it is found, and if it is not found, it will print \"NO\" in\n>> its standard color code (red) for things-that-are-missing.\n>\n> Oh, that's much nicer indeed. Thanks!\n\nThat is a lot more pleasant to the eyes.\n\nThanks for working well together.\n\n\n"},{"id":"516819","messageId":"xmqqy0votbns.fsf@gitster.g","threadId":"63340","inReplyTo":"20250425-pks-meson-posix-shell-v3-2-01607a2e9334@pks.im","subject":"Re: [PATCH v3 2/2] meson: prefer shell at \"/bin/sh\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-04-25T17:04:55Z","receivedAt":"2025-04-25T17:04:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> Meson detects the path of the target shell via `find_program(\"sh\")`,\n> which essentially does a lookup via `PATH`. This may easily lead to a\n> subtly-broken Git distribution when the build host has its shell in a\n> location that the target host doesn't know about.\n>\n> Fix the issue by appending \"/bin\" to the custom program path, which\n> causes us to prefer \"/bin/sh\" over a `PATH`-based lookup. While\n> \"/bin/sh\" isn't standardized, this path tends to work alright on Linux\n> and BSD distributions. Furthermore, \"/bin/sh\" is also the path we pick\n> in our Makefile by default, which further demonstrates that this shell\n> fulfills our needs.\n>\n> Note that we intentionally append, not prepend, to the custom program\n> path. This is because the program path can be configured by the user via\n> the `-Dsane_tool_path=` build option, which should take precedence over\n> any defaults we pick for the user.\n>\n> Signed-off-by: Patrick Steinhardt <ps@pks.im>\n> ---\n>  meson.build | 6 +++++-\n>  1 file changed, 5 insertions(+), 1 deletion(-)\n\nLooking good.\n\n> diff --git a/meson.build b/meson.build\n> index a180c66ee69..6a90310a2ca 100644\n> --- a/meson.build\n> +++ b/meson.build\n> @@ -236,7 +236,11 @@ sed = find_program('sed', dirs: program_path, native: true)\n>  shell = find_program('sh', dirs: program_path, native: true)\n>  tar = find_program('tar', dirs: program_path, native: true)\n>  \n> -target_shell = find_program('sh', dirs: program_path, native: false)\n> +# Detect the target shell that is used by Git at runtime. Note that we prefer\n> +# \"/bin/sh\" over a PATH-based lookup, which provides a working shell on most\n> +# supported systems. This path is also the default shell path used by our\n> +# Makefile. This lookup can be overridden via `program_path`.\n> +target_shell = find_program('sh', dirs: program_path + [ '/bin' ], native: false)\n\nI wonder if we should be a bit more friendly to beginners (either\n'meson' beginner or a newcomer to the project who are not yet\nfamiliar with how our meson.build files are written), than saying\n\"via 'program_path'\" by referring to \"-Dsane_tool_path=\", possibly\neven with an example.\n\nNow I am showing my ignorance, but does this support folks whose\nshell are not spelled \"sh\" (like \"/usr/local/bin/dash\"), and more\nimportantly, if it does not, shouldn't we be using a mechanism that\ndoes?  I think -Dsane_tool_path=/usr/local/bin would help with the\nleading directory path, but I suspect that find_program() does not\nhelp specifying \"dash\" to be used as our target_shell (or host\nshell), or \"perl5\" as our perl.\n\nOf course, this \"my sh is called dash\" can be left totally outside\nof the topic of these two patches.\n\nThanks.\n"},{"id":"516822","messageId":"06e57780-9f59-4166-81d3-9cd0c1c66b7e@gentoo.org","threadId":"63340","inReplyTo":"xmqqy0votbns.fsf@gitster.g","subject":"Re: [PATCH v3 2/2] meson: prefer shell at \"/bin/sh\"","fromName":"Eli Schwartz","fromEmail":"eschwartz@gentoo.org","sentAt":"2025-04-25T18:07:18Z","receivedAt":"2025-04-25T18:07:23Z","isPatch":true,"sender":{"key":"eschwartz@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/6551424?v=4"},"body":"On 4/25/25 1:04 PM, Junio C Hamano wrote:\n> Now I am showing my ignorance, but does this support folks whose\n> shell are not spelled \"sh\" (like \"/usr/local/bin/dash\"), and more\n> importantly, if it does not, shouldn't we be using a mechanism that\n> does?  I think -Dsane_tool_path=/usr/local/bin would help with the\n> leading directory path, but I suspect that find_program() does not\n> help specifying \"dash\" to be used as our target_shell (or host\n> shell), or \"perl5\" as our perl.\n> \n> Of course, this \"my sh is called dash\" can be left totally outside\n> of the topic of these two patches.\n\n\nPOSIX does not require a specific absolute file path for \"sh\", but it\ndoes mandate that you have a shell and its name is \"sh\", whichever\ndirectory it may be found in.\n\nThere is (most of the time) not actually a program called \"sh\". Various\ndifferent programs may provide a symlink \"sh\", pointing to their own shell:\n\n- GNU Bash (bash)\n- Korn Shell (ksh93)\n- Policy-compliant Ordinary Shell (Debian `posh`)\n- Almquist Shell (ash)\n- Debian Almquist Shell (dash)\n- busybox\n- MirBSD Korn Shell (mksh)\n\n(Commercial Unixes will tend to have a unique \"sh\" program without an\nactual name, just called \"$UNIX sh\".)\n\nYou can call them by either name, but the general rule is that when\nrunning an interactive command prompt you probably have your specific\nfavorite whereas when running a script you just need something that\ncomplies with the POSIX spec. It's common to install dash as the /bin/sh\nbecause it is faster than GNU Bash due to supporting much less.\n\nThere cannot be anyone who has a sh that is not spelled \"sh\", there are\nonly people who have multiple options, one of which has been assigned to\nthe name \"sh\".\n\nIf it is desirable for Git to allow people to experiment with different\nshells for the git internal scripts, that is one thing (though I don't\nthink it's particularly useful). But there's no need to worry about\npeople that don't have an \"sh\". They have to.\n\nEven on Solaris where /bin/sh is a non-POSIX shell that cannot run our\nscripts, that is a backwards compatibility requirement and they expect\nyou to add /usr/xpg4/bin to the front of $PATH for applications that use\nPOSIX, while leaving the \"broken forever\" version in /bin to be used by\nlegacy pre-1990s applications that may still exist and haven't been\nupdated in well over 30 years and counting. The \"sh\" in $PATH at\n/usr/xpg4/bin/sh is a POSIX-compliant shell. It even has the `local`\nvendor extension.\n\n\n-- \nEli Schwartz\n"},{"id":"516826","messageId":"xmqqcyd0t6qx.fsf@gitster.g","threadId":"63340","inReplyTo":"06e57780-9f59-4166-81d3-9cd0c1c66b7e@gentoo.org","subject":"Re: [PATCH v3 2/2] meson: prefer shell at \"/bin/sh\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-04-25T18:51:02Z","receivedAt":"2025-04-25T18:51:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eli Schwartz <eschwartz@gentoo.org> writes:\n\n> On 4/25/25 1:04 PM, Junio C Hamano wrote:\n>> Now I am showing my ignorance, but does this support folks whose\n>> shell are not spelled \"sh\" (like \"/usr/local/bin/dash\"), and more\n>> importantly, if it does not, shouldn't we be using a mechanism that\n>> does?  I think -Dsane_tool_path=/usr/local/bin would help with the\n>> leading directory path, but I suspect that find_program() does not\n>> help specifying \"dash\" to be used as our target_shell (or host\n>> shell), or \"perl5\" as our perl.\n>> \n>> Of course, this \"my sh is called dash\" can be left totally outside\n>> of the topic of these two patches.\n>\n>\n> POSIX does not require a specific absolute file path for \"sh\", but it\n> does mandate that you have a shell and its name is \"sh\", whichever\n> directory it may be found in.\n> ...\n> There is (most of the time) not actually a program called \"sh\". Various\n> different programs may provide a symlink \"sh\", pointing to their own shell:\n\nExactly.  And with many systems being personal these days, /bin/sh\nmay point at a shell that is better for interactive use (like\n\"bash\"), while the user may prefer another (like \"dash\") scripted\nuse that is not pointed by that single /bin/sh symbolic link.\n\nIn any case, we live in real world where things are not strictly\nPOSIX.  Our Makefile does support with SHELL_PATH \"sh\", \"dash\", and\n\"bash\" just fine.  Why shouldn't I wish for feature parity in a new\nbuild framework that aims to at least compete and become an\nalternative?\n\n"},{"id":"516840","messageId":"aAvsT1o6wIGGCEui@tapette.crustytoothpaste.net","threadId":"63340","inReplyTo":"06e57780-9f59-4166-81d3-9cd0c1c66b7e@gentoo.org","subject":"Re: [PATCH v3 2/2] meson: prefer shell at \"/bin/sh\"","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-04-25T20:10:55Z","receivedAt":"2025-04-25T20:10:57Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-04-25 at 18:07:18, Eli Schwartz wrote:\n> On 4/25/25 1:04 PM, Junio C Hamano wrote:\n> > Now I am showing my ignorance, but does this support folks whose\n> > shell are not spelled \"sh\" (like \"/usr/local/bin/dash\"), and more\n> > importantly, if it does not, shouldn't we be using a mechanism that\n> > does?  I think -Dsane_tool_path=/usr/local/bin would help with the\n> > leading directory path, but I suspect that find_program() does not\n> > help specifying \"dash\" to be used as our target_shell (or host\n> > shell), or \"perl5\" as our perl.\n> > \n> > Of course, this \"my sh is called dash\" can be left totally outside\n> > of the topic of these two patches.\n> \n> \n> POSIX does not require a specific absolute file path for \"sh\", but it\n> does mandate that you have a shell and its name is \"sh\", whichever\n> directory it may be found in.\n> \n> There is (most of the time) not actually a program called \"sh\". Various\n> different programs may provide a symlink \"sh\", pointing to their own shell:\n> \n> - GNU Bash (bash)\n> - Korn Shell (ksh93)\n> - Policy-compliant Ordinary Shell (Debian `posh`)\n> - Almquist Shell (ash)\n> - Debian Almquist Shell (dash)\n> - busybox\n> - MirBSD Korn Shell (mksh)\n\nAll of what you said here is true, but I will point out that AT&T ksh\n(ksh93 and also ksh88) doesn't support `local`.  All of the others do,\nas do other pdksh derivatives (like OpenBSD's sh and ksh[0]).\n\nI believe on NonStop that `sh` is AT&T ksh, so there is no program or\nsymlink named `sh` on the system which meets our needs.  The customary\noption there is to use bash instead.\n\nAdditionally, Debian allows zsh as `/bin/sh`, since it meets their\nrequirements, but older versions do not run all elements of a pipeline\nin a subshell, which, while allowed by POSIX as an extension,\npractically breaks our code (and lots of other code as well).  (New\nversions contain a patch I sent that fixes this behaviour when in `sh`\nmode.)  As a result, a user compiling their own Git might need to\nspecify something that is not `sh` on such a system.\n\nAnd Junio points out correctly that some systems have Perl as `perl5`,\nnot `perl`.  (Mostly in environments that once had or still have Perl\n4.)\n\nSo all that to say that we do need to be able to specify an arbitrary\npath to a binary in order for things to work on some systems.\n\n[0] Which are the same thing.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"516841","messageId":"aAvszaVi1TGxP56N@tapette.crustytoothpaste.net","threadId":"63340","inReplyTo":"20250425-pks-meson-posix-shell-v3-2-01607a2e9334@pks.im","subject":"Re: [PATCH v3 2/2] meson: prefer shell at \"/bin/sh\"","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-04-25T20:13:01Z","receivedAt":"2025-04-25T20:13:03Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-04-25 at 14:11:29, Patrick Steinhardt wrote:\n> Meson detects the path of the target shell via `find_program(\"sh\")`,\n> which essentially does a lookup via `PATH`. This may easily lead to a\n> subtly-broken Git distribution when the build host has its shell in a\n> location that the target host doesn't know about.\n> \n> Fix the issue by appending \"/bin\" to the custom program path, which\n> causes us to prefer \"/bin/sh\" over a `PATH`-based lookup. While\n> \"/bin/sh\" isn't standardized, this path tends to work alright on Linux\n> and BSD distributions. Furthermore, \"/bin/sh\" is also the path we pick\n> in our Makefile by default, which further demonstrates that this shell\n> fulfills our needs.\n\nI think this description is much better, thanks.  I agree that choosing\n`/bin/sh` is the right thing to do on Linux and the BSDs, even on\nusr-merged systems (where `/bin` is always a symlink to `/usr/bin`).\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"516844","messageId":"27b77b6b-d696-4837-89fe-b359ce481083@gentoo.org","threadId":"63340","inReplyTo":"xmqqcyd0t6qx.fsf@gitster.g","subject":"Re: [PATCH v3 2/2] meson: prefer shell at \"/bin/sh\"","fromName":"Eli Schwartz","fromEmail":"eschwartz@gentoo.org","sentAt":"2025-04-25T22:21:13Z","receivedAt":"2025-04-25T22:21:17Z","isPatch":true,"sender":{"key":"eschwartz@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/6551424?v=4"},"body":"On 4/25/25 2:51 PM, Junio C Hamano wrote:\n> Eli Schwartz <eschwartz@gentoo.org> writes:\n>> POSIX does not require a specific absolute file path for \"sh\", but it\n>> does mandate that you have a shell and its name is \"sh\", whichever\n>> directory it may be found in.\n>> ...\n>> There is (most of the time) not actually a program called \"sh\". Various\n>> different programs may provide a symlink \"sh\", pointing to their own shell:\n> \n> Exactly.  And with many systems being personal these days, /bin/sh\n> may point at a shell that is better for interactive use (like\n> \"bash\"), while the user may prefer another (like \"dash\") scripted\n> use that is not pointed by that single /bin/sh symbolic link.\n\n\nI would argue 100% of interactive bash users, are running \"bash\" to get\nit. They are not running \"sh\" and then rewriting all scripts in /usr/bin\nfrom\n\n#!/bin/sh\n\nto\n\n#!/usr/bin/dash\n\nfor the speedup.\n\nThe point is that if users set the \"non-interactive scripts\" command\n/bin/sh to GNU bash, they are fine with that being used everywhere (and\nit will in fact run all Git's scripts well).\n\n\n> In any case, we live in real world where things are not strictly\n> POSIX.  Our Makefile does support with SHELL_PATH \"sh\", \"dash\", and\n> \"bash\" just fine.  Why shouldn't I wish for feature parity in a new\n> build framework that aims to at least compete and become an\n> alternative?\n\n\nBut it's a very fair point that it's possible to need more than just\nPOSIX. Meson can override program lookup:\n\n$ cat paths.ini\n\n[binaries]\nsh = '/usr/bin/bash'\n\n$ meson setup builddirbash/ --native-file=paths.ini\n[...]\n  Runtime executable paths\n    perl        : /usr/bin/perl\n    python      : /usr/bin/python3\n    shell       : /usr/bin/bash\n\n\nA dedicated build option might be more discoverable, but it's certainly\npossible to override this today. Autodetecting the right one can be\ntricky...\n\n\n-- \nEli Schwartz\n"},{"id":"516845","messageId":"9182bbb9-fdfa-4abe-abae-4ecfd5c0f449@gentoo.org","threadId":"63340","inReplyTo":"aAvsT1o6wIGGCEui@tapette.crustytoothpaste.net","subject":"Re: [PATCH v3 2/2] meson: prefer shell at \"/bin/sh\"","fromName":"Eli Schwartz","fromEmail":"eschwartz@gentoo.org","sentAt":"2025-04-25T22:25:25Z","receivedAt":"2025-04-25T22:25:28Z","isPatch":true,"sender":{"key":"eschwartz@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/6551424?v=4"},"body":"On 4/25/25 4:10 PM, brian m. carlson wrote:\n> All of what you said here is true, but I will point out that AT&T ksh\n> (ksh93 and also ksh88) doesn't support `local`.  All of the others do,\n> as do other pdksh derivatives (like OpenBSD's sh and ksh[0]).\n\n\nRight, though I seem to recall e.g. all the BSDs use a pdksh variant at\nleast.\n\n\n> I believe on NonStop that `sh` is AT&T ksh, so there is no program or\n> symlink named `sh` on the system which meets our needs.  The customary\n> option there is to use bash instead.\n\n\nAha. :(\n\n\n> Additionally, Debian allows zsh as `/bin/sh`, since it meets their\n> requirements, but older versions do not run all elements of a pipeline\n> in a subshell, which, while allowed by POSIX as an extension,\n> practically breaks our code (and lots of other code as well).  (New\n> versions contain a patch I sent that fixes this behaviour when in `sh`\n> mode.)  As a result, a user compiling their own Git might need to\n> specify something that is not `sh` on such a system.\n\n\nNobody should be using zsh as /bin/sh at all, since it is not a POSIX\nshell to begin with. e.g. Gentoo does not permit it. I think Debian\nshould treat this as a conformance bug and fix it by removing zsh\nsupport for /bin/sh until upstream zsh makes a serious effort to conform\nto POSIX (i.e. never)...\n\n\n> And Junio points out correctly that some systems have Perl as `perl5`,\n> not `perl`.  (Mostly in environments that once had or still have Perl\n> 4.)\n\n\nYup. Same applies for overriding via a machine specification file as I\nreplied regarding \"sh\".\n\n\n\n> So all that to say that we do need to be able to specify an arbitrary\n> path to a binary in order for things to work on some systems.\n> \n> [0] Which are the same thing.\n\n\n-- \nEli Schwartz\n"},{"id":"517131","messageId":"xmqqjz6yu30o.fsf@gitster.g","threadId":"63340","inReplyTo":"20250425-pks-meson-posix-shell-v3-0-01607a2e9334@pks.im","subject":"Re: [PATCH v3 0/2] meson: prefer '/bin/sh' over PATH lookup","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-05-02T21:16:39Z","receivedAt":"2025-05-02T21:16:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> But this made me remember the report from Peter [1] that Debian also\n> faced this issue. So I decided to address the issue in Meson directly by\n> preferring `/bin/sh` over a PATH-based lookup.\n>\n> Changes in v2:\n>   - Simplify how we generate the summary.\n>   - Add a comment to explain ordering of the program path.\n>   - Link to v1: https://lore.kernel.org/r/20250424-pks-meson-posix-shell-v1-0-45e06ee4b6ad@pks.im\n>\n> Changes in v3:\n>   - Stop claiming that \"/bin/sh\" is a POSIX-compliant path.\n>   - Link to v2: https://lore.kernel.org/r/20250425-pks-meson-posix-shell-v2-0-fddc6123511b@pks.im\n\nSo the discussion seems to have died out.  Have we decided that\nunlike Makefile-based approach, it is too cumbersome to teach the\nMeson based approach to allow user-specified commands that have\ndifferent basename to stand in for the command we expect in the\nbuild based on Meson [*], and what the v3 iteration of this series\ndoes is a good place to stop?\n\n\n\n\n[Footnote]\n\n * It is trivial to say \"make SHELL_PATH=/bin/dash\", but we do not\n   add support for anything like 'meson -dSHELL_PATH=/bin/dash', and\n   we only allow the search path for fixed-name commands to be\n   configured and tell our developers that they have to write an\n   extra file paths.ini just to be able to do so.\n"},{"id":"517136","messageId":"c5486e20-dbae-4ec2-bc19-d5dc537a8399@gentoo.org","threadId":"63340","inReplyTo":"xmqqjz6yu30o.fsf@gitster.g","subject":"Re: [PATCH v3 0/2] meson: prefer '/bin/sh' over PATH lookup","fromName":"Eli Schwartz","fromEmail":"eschwartz@gentoo.org","sentAt":"2025-05-02T22:37:45Z","receivedAt":"2025-05-02T22:37:48Z","isPatch":true,"sender":{"key":"eschwartz@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/6551424?v=4"},"body":"On 5/2/25 5:16 PM, Junio C Hamano wrote:\n> So the discussion seems to have died out.  Have we decided that\n> unlike Makefile-based approach, it is too cumbersome to teach the\n> Meson based approach to allow user-specified commands that have\n> different basename to stand in for the command we expect in the\n> build based on Meson [*], and what the v3 iteration of this series\n> does is a good place to stop?\n\n\nI don't have any objections to teaching git's own meson.build to do\nthis, and I don't think it would be particularly cumbersome. But as I'm\nnot the person who would use it, really, I was hoping others would state\ntheir preferences.\n\n...\n\nOne possibility would be if meson itself was adapted to support setting\nsimple \"machine description\" settings via the command line. I seem to\nrecall someone had proposed at one point on the meson ticket tracker, to\nsupport e.g.\n\n```\nmeson setup -Dbinaries.cc=gcc -Dbinaries.sh=/bin/dash\n```\nbut I cannot recall what came of the discussion. I'll try to find the\nrelevant ticket after the weekend (going offline right around now).\n\n\n\n> [Footnote]\n> \n>  * It is trivial to say \"make SHELL_PATH=/bin/dash\", but we do not\n>    add support for anything like 'meson -dSHELL_PATH=/bin/dash', and\n>    we only allow the search path for fixed-name commands to be\n>    configured and tell our developers that they have to write an\n>    extra file paths.ini just to be able to do so.\n\n\n-- \nEli Schwartz\n"},{"id":"517198","messageId":"aBhV9SNm5G-g-sRh@pks.im","threadId":"63340","inReplyTo":"c5486e20-dbae-4ec2-bc19-d5dc537a8399@gentoo.org","subject":"Re: [PATCH v3 0/2] meson: prefer '/bin/sh' over PATH lookup","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-05-05T06:08:53Z","receivedAt":"2025-05-05T06:08:57Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Fri, May 02, 2025 at 06:37:45PM -0400, Eli Schwartz wrote:\n> On 5/2/25 5:16 PM, Junio C Hamano wrote:\n> > So the discussion seems to have died out.  Have we decided that\n> > unlike Makefile-based approach, it is too cumbersome to teach the\n> > Meson based approach to allow user-specified commands that have\n> > different basename to stand in for the command we expect in the\n> > build based on Meson [*], and what the v3 iteration of this series\n> > does is a good place to stop?\n> \n> \n> I don't have any objections to teaching git's own meson.build to do\n> this, and I don't think it would be particularly cumbersome. But as I'm\n> not the person who would use it, really, I was hoping others would state\n> their preferences.\n\nIt wouldn't be hard to do indeed. But I think that the proposed patch\nshould be good enough for now as it does what we want in basically every\nusecase I can think of, and it does allow the user to tweak as required.\n\nSo I'd propose to go with the proposed pragmatic approach and then\niterate in the future if we ever see that it continues to be a problem.\n\n> One possibility would be if meson itself was adapted to support setting\n> simple \"machine description\" settings via the command line. I seem to\n> recall someone had proposed at one point on the meson ticket tracker, to\n> support e.g.\n> \n> ```\n> meson setup -Dbinaries.cc=gcc -Dbinaries.sh=/bin/dash\n> ```\n> but I cannot recall what came of the discussion. I'll try to find the\n> relevant ticket after the weekend (going offline right around now).\n\nThat would be nice to have indeed.\n\nThanks!\n\nPatrick\n"}]}