From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 65A08158232 for ; Tue, 10 Dec 2024 19:33:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 90C72E0844; Tue, 10 Dec 2024 19:33:31 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id DB65EE080E for ; Tue, 10 Dec 2024 19:33:30 +0000 (UTC) Message-ID: <9c178e9d-5f22-4e2f-952a-5bfb9eb87b65@gentoo.org> Date: Tue, 10 Dec 2024 14:33:26 -0500 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [gentoo-dev] [PATCH] profiles/default/linux: export cache variables for sed and friends To: gentoo-dev@lists.gentoo.org References: <4bfc3e7b67c2a1398c8efa9700b66fe9ac0f2736.1733352922.git.sam@gentoo.org> Content-Language: en-US From: Eli Schwartz Autocrypt: addr=eschwartz@gentoo.org; keydata= xjMEZmeRNBYJKwYBBAHaRw8BAQdAYNZ7pUDWhx1i2f3p6L2ZLu4FcY18UoeGC04Gq/khqwfN I0VsaSBTY2h3YXJ0eiA8ZXNjaHdhcnR6QGdlbnRvby5vcmc+wpYEExYKAD4WIQTvUdMIsc4j CIi+DYTqQj6ToWND8QUCZoRL+gIbAwUJBKKGAAULCQgHAwUVCgkICwUWAgMBAAIeBQIXgAAK CRDqQj6ToWND8aB5AP9r4kB691nNtNwKkdRiOdl7/k6WYzokvHvDamXxRJ0I+gEAjZqR5V8y mfR3fy2Z+r2Joeqdt3CIv5IwPs64spBvigLOOARmZ5E0EgorBgEEAZdVAQUBAQdATT46Z06b 1X9xjXFCYFxmq/Tj3tSEKZInDWTpoHQp4l8DAQgHwn4EGBYKACYWIQTvUdMIsc4jCIi+DYTq Qj6ToWND8QUCZmeRNAIbDAUJBKKGAAAKCRDqQj6ToWND8a2RAP40KPfbfoiZAJW5boFmFJ3G TUBDJRh9CWHyaPqq2PN+0wD/R07oLzfnJUN209mzi9TuTuHjeZybysyqXSw4MAxkMAY= In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------6B21Zm0LoWarT9Z3Jefe05fd" X-Archives-Salt: 35b1f6f8-22f4-403d-bfb5-a7874a758147 X-Archives-Hash: ade7dc66dc362261f34ac1bfbda02dbb This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------6B21Zm0LoWarT9Z3Jefe05fd Content-Type: multipart/mixed; boundary="------------54NNbbnKuPiqWj0mD0RrOMrF"; protected-headers="v1" From: Eli Schwartz To: gentoo-dev@lists.gentoo.org Message-ID: <9c178e9d-5f22-4e2f-952a-5bfb9eb87b65@gentoo.org> Subject: Re: [gentoo-dev] [PATCH] profiles/default/linux: export cache variables for sed and friends References: <4bfc3e7b67c2a1398c8efa9700b66fe9ac0f2736.1733352922.git.sam@gentoo.org> In-Reply-To: --------------54NNbbnKuPiqWj0mD0RrOMrF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/10/24 1:31 PM, Michael Orlitzky wrote: > On 2024-12-10 00:54:11, Eli Schwartz wrote: >> >> What circumstances other than a shebang might break without a full pat= h? >=20 > When PATH is not reliable, like inside a cron job. Or arguments to exec= ve(). execve doesn't make any sense to me as an argument. I don't think I've ever in my life either seen or heard of software that did a configure-time check for the full abspath of a file in order to solve the fact that execve doesn't search on PATH. They simply used execvpe instead. There may be other reasons for doing such a configure-time check, but "PATH is not reliable" is not one of them... Inside cron doesn't make a ton of sense to me either. A cron job will use a basic system PATH including these utilities already, and it frequently surprises people that the PATH set up in their ~/.bashrc isn't applied -- things like /opt/barware/bin and $HOME/.local/bin. Hardcoding the path to /bin/grep won't help in the slightest here, but hardcoding the path to a script installed in a non-default location would help. The script is then going to run with a basic PATH=3D/bin:/usr/bin and any core system utilities (such as grep, sed, dd= ) will be found but custom user scripts in the same directory as the configured crontab script will *not* be found. In both cases, there's nothing to gain from ensuring that autoconf sees full paths. For the execve case it's possible to write a proof of concept demonstrating the issue, but writing a PoC to demonstrate that people can write incorrect code doesn't prove that people *do* write incorrect code so the logic is circular. --=20 Eli Schwartz --------------54NNbbnKuPiqWj0mD0RrOMrF-- --------------6B21Zm0LoWarT9Z3Jefe05fd Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCZ1iXhgUDAAAAAAAKCRCEp9ErcA0vV4h1 AP9DLh13L5eA5pvXrEkRaLVv+AeU0VSrzAcGnCYtKRmMXgD/bvyHXhkNZ51pOVJ4Im3eab8QTl7l hCro1/24aUC4HgA= =I+9e -----END PGP SIGNATURE----- --------------6B21Zm0LoWarT9Z3Jefe05fd--