• Future of /usr/bin/which in Debian?

    From Boyuan Yang@21:1/5 to All on Fri Aug 27 22:50:02 2021
    Hi,

    在 2021-08-22星期日的 17:36 +0200,Andrej Shadura写道:
    Hi,

    On Thu, 19 Aug 2021, at 23:17, Boyuan Yang wrote:
    在 2021-08-18星期三的 22:59 +0200,Geert Stappers写道:
    /usr/bin/which.debianutils 0

    in postinst and so on so that FreeBSD which and GNU which and friends could
    take over.

    Please do.  Make such take over possible.
    It is what https://salsa.debian.org/debian/debianutils/-/merge_requests/6#note_242172
    is asking for.

    So we will have https://salsa.debian.org/debian/which-gnu providing a binary
    package with name "which". I will upload it to the NEW queue soon.

    I'd rather suggest the FreeBSD which, which I'm mirroring here: https://salsa.debian.org/andrewsh/freebsd-which/

    I think it's much simpler than the GNU one.

    The GNU which package is now in NEW queue: https://ftp-master.debian.org/new/gnu-which_2.21-1.html

    Having both freebsd which and gnu which in Debian archive is definitely ok. If you would like, please also upload freebsd-which onto unstable.

    Thanks,
    Boyuan Yang

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEfncpR22H1vEdkazLwpPntGGCWs4FAmEpT6oACgkQwpPntGGC Ws7OlQ/9Hr53cWOfdvhuUQk4ASMjvBQyoL2PxMZzkQrO58w2XhOiwK09kZPE95ml +e9X+IVdKpm2JaF1tlq0lDuOHurptFffqDqeqffeR7hPgd1zQ+XoIgVcHo4QQZr4 gTdajjZmNzscJLJ0Zt/3jjVAFM7gg7oyNjD/IaYfjhKH6qjsy3S4GVVeCzZ6VjcS lWWio13Ti012oPP+jNasdNQpuSVyxOxPki3G2ifcmlzx2+L/BRhthR8Nu/lnR52p Qd7rcSkUFoyXHtYt3YFNkPOkN+XrMnMz+XGzGFGTD2IPrAX+pssN3yrJPVHVDjKr zhqWG+WiewFyfobGEgy6eWiYN51DO+o773pk546Zw5HLuA1qIaNCG61HSPEZsBV7 Gu/cSct+WVvGZY/jR5LvjjbRky9O+MglThR4fpVtq5CU87GEnc/U9ggABcoRgn6/ 8NLGiouUAtkARGHji0OcrHpPqtiiABiRitsUWcQKOvRY7Yi8aAhiwOYvCQyjkdlR iDFpf64EATqfED47/mlqeXjy6aUhMd0mQU/aZwnYl7jZt+w/EWzz/SSVcMucfIiQ ydaPIvQWMS8PfpJKTPwEBoTu9wEZwEtbexOgFxnOpS+NHsTe7cDX9mTXOETlIvqA YDkfPeaM2Lw2+n+J9rcY4yCuF+1GEqtH7RgB8mQ5zwaaITbGwok=
    =uz3g
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sean Whitton@21:1/5 to Boyuan Yang on Fri Aug 27 23:00:02 2021
    Hello Boyuan,

    On Fri 27 Aug 2021 at 04:48PM -04, Boyuan Yang wrote:

    Hi,

    在 2021-08-22星期日的 17:36 +0200,Andrej Shadura写道:
    Hi,

    On Thu, 19 Aug 2021, at 23:17, Boyuan Yang wrote:
    在 2021-08-18星期三的 22:59 +0200,Geert Stappers写道:
    /usr/bin/which.debianutils 0

    in postinst and so on so that FreeBSD which and GNU which and friends >> > > > could
    take over.

    Please do.  Make such take over possible.
    It is what
    https://salsa.debian.org/debian/debianutils/-/merge_requests/6#note_242172
    is asking for.

    So we will have https://salsa.debian.org/debian/which-gnu providing a
    binary
    package with name "which". I will upload it to the NEW queue soon.

    I'd rather suggest the FreeBSD which, which I'm mirroring here:
    https://salsa.debian.org/andrewsh/freebsd-which/

    I think it's much simpler than the GNU one.

    The GNU which package is now in NEW queue: https://ftp-master.debian.org/new/gnu-which_2.21-1.html

    Having both freebsd which and gnu which in Debian archive is definitely ok. If
    you would like, please also upload freebsd-which onto unstable.

    It's okay, indeed, but please do consider NEW queue workload with things
    like this -- upload it if you're sure it's going to get used, not just
    for completeness.

    --
    Sean Whitton

    --=-=-Content-Type: application/pgp-signature; name="signature.asc"

    -----BEGIN PGP SIGNATURE-----

    iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmEpUQ8ZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQPXgD/4mKTLGOsTsIJ/Yi0u7/2Q4 4JhIuaPFeBjV97UjVHB+iseVqrKGBmYz+z/B7USauNe+qeekSfKUGPJkOqfHGwpH C//vmWBoFsYSv5IiOPv1ZV+Ggw0QLvVQoKSaximv+IiKt2lyxJw0k2S3pF3NjFGH qyHsp41WFd2dfWIr9y5UkNTRqPF8zpEk2kClZRrRhk/93icKPSLLfZkfmAbfk9P4 mLVcLVsNY2P26eOWD3ICACOGHp7dQKjNxgdQYa/tY9BaS58hWsjBux4t73i2u6iW g01hcxp70t4Q4Nc5vZ9kvAh34kNaO+QWhUkjqM32x5SGawfPtBrg3TN3MBRBEVnl C9LEzbav845zmiMimbdMblzrxJgtkXhQlVKoRILV1e5Znue730sQ7pxoBATJnJle h/g26RSFIaJ/3BOyJ9ISsxsjhZm4ndbeimsNKtDplDzUl+ILZSk63bYOTJqaIJJV I3jNFX2jccCswt+EdhFOvCufEqGd6m2JBzyua3nl/FzG6b7orkLTk0kxJUiFKJ6a GU0y5YftX38usw7IPIdPhf6dXD+KYj75Lg296uKdy1nEU6GmWYyCWcIIYuTGCFMP EE3LyoJf6l+IEIZmNPDyFBlhrDapH/79NyjJDuPQbR+PJFqDwoJiD0Z9XLLRYNzy /JPSXKBi13qaqJk9MtC5rQ==0xJ+
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Us
  • From =?UTF-8?B?eGlhbyBzaGVuZyB3ZW4o6IKW5@21:1/5 to All on Sat Aug 28 03:40:01 2021
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pSsFyvVtkVKkXy25aopeGE63NPFDRRls0
    Content-Type: multipart/mixed;
    boundary="------------21B94B857A0342CFCF91257E"
    Content-Language: en-US

    This is a multi-part message in MIME format. --------------21B94B857A0342CFCF91257E
    Content-Type: text/plain; charset=gbk; format=flowed
    Content-Transfer-Encoding: quoted-printable


    2021/8/28 4:54, Sean Whitton д:

    I'd rather suggest the FreeBSD which, which I'm mirroring here:
    https://salsa.debian.org/andrewsh/freebsd-which/

    I think it's much simpler than the GNU one.
    The GNU which package is now in NEW queue:
    https://ftp-master.debian.org/new/gnu-which_2.21-1.html

    Having both freebsd which and gnu which in Debian archive is definitely ok. If
    you would like, please also upload freebsd-which onto unstable.
    It's okay, indeed, but please do consider NEW queue workload with things
    like this -- upload it if you're sure it's going to get used, not just
    for completeness.
    If there are several different versions of which in Debian, this will
    give the user that have a chance to choice one.


    --
    Фʢ xiao sheng wen Faris Xiao
    ΢(wechat)atzlinux
    ͭ㶹 Linuxhttps://www.atzlinux.com
    Debian Linux ϵͳ
    Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com GnuPG Public Key: 0x00186602339240CB


    --------------21B94B857A0342CFCF91257E
    Content-Type: application/pgp-keys;
    name="OpenPGP_0x00186602339240CB.asc"
    Content-Transfer-Encoding: quoted-printable
    Content-Description: OpenPGP public key
    Content-Disposition: attachment;
    filename="OpenPGP_0x00186602339240CB.asc"

    -----BEGIN PGP PUBLIC KEY BLOCK-----

    xsFNBF6Om9cBEADEsG6I7N5GRxuCIspmxdSPzMUG3C6vbSa7c3uyUUJoqbdNsb15dRLoZ4qfyBNF ZEu+kkOpQNH7/o6+7Y65tILKP9I46bGKQCw5HAx4nS7je1Jf0bC41R3tg625GWtfpdAUa5xgthCG 2NhjSspWqi1WwNsZQ69bfagOzIq0ggKmWfYtJORGkijEAobnqB2wN+JDgMhvNMAFunIB6uk1rHwp Ko2vrzl+xr3vf1CFOvYS9tQh1eDzMfzseJTIMuxrUv3MfvALDKkNj2sfrPFOvLUwqszTBNPZxaBc 3EGe31lkqmWG+TlflLDyVfMuBZrxxnTHnqlKVqrCU7oLIM5agBgbCk6xJ831tw+mQ6sOO2xiypg9 ZVGOsCx3Sj2Ofp5sEOq2j0DkHChMfCQBsTDXpWpgMSWY
  • From Wookey@21:1/5 to Boyuan Yang on Sun Sep 19 18:40:02 2021
    On 2021-08-27 16:48 -0400, Boyuan Yang wrote:
    Hi,

    The GNU which package is now in NEW queue: https://ftp-master.debian.org/new/gnu-which_2.21-1.html

    Thanks for this. Missing which broke bazel (at least in tensorflow)
    and the implementation made it fiddly to replace <command> with <command+option> as recommended.

    Have a plain which back is much easier than fixing the build mess.

    I must admit that I have no idea why replacing such a longstanding
    utility is deemed necessary.

    Wookey
    --
    Principal hats: Linaro, Debian, Wookware, ARM
    http://wookware.org/

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEER4nvI8Pe/wVWh5yq+4YyUahvnkcFAmFHZf8ACgkQ+4YyUahv nkdZohAAwY9Og9dxsI+8qjvx6ejNz42J6OTyuSPtbfoXocV5WGHu/SQB/tF1kyWA fxJ/JDjOoqmDHOyFUdaeu3oUpP7K1B+67uY9hXdjfx277hy1RG1J1Tp2y4ZQ31hq euqOuAITbsjynGZB+l/bQM8LIDu/lRsqeS1kW+rgFITOpJ9Q1imXXyNBzXn7LECM +sfx3o2z9RRu3lS2Ve+960lx0WTYRBQt9EmX4OF228uMFdu3r8eF5Ic/3POrsGnN lQcw8vttGbgrmqsk5nsOhar0nfH7MQjEIxnSrn/TYgFrmaj5S5LeinqiL2kvHXcC 0ghLuKCOFAyMW0eaDYQ2tsAh3XfFkq7w19b4EC2drCVN/uUm+qpAa3lDflrfHJC/ s7nS8TF6DgEZQX5ShdJYM52M5d1utBG0CgKcGYSicXHM2fGW6Rr1KZyws5EqGFWv Mi4XHFtrcQi60Z/3uLklHZQoFjtV60Ab9m2ZjF8WGcRk1wHanL43p1B/LsIMgG5W VBPsd+0fpK+oPdf1QVr6MDaSYMA2MuRfR9sIUgDvvyNYrnRObRXCzSB8YYZvsrBQ MyHz2QQo5fdCrulyEJ3C2Ryz5gLygbvTpZLcD7EuTpl9uhT93A4H9tAA1vw8ivnT EKWeRLL77S6Z0Xe8DmCwqEwPR3ciiPm2SzSj9JXw9tlQH165xuA=
    =aEcS
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Clint Adams@21:1/5 to Wookey on Mon Sep 20 06:50:01 2021
    On Sun, Sep 19, 2021 at 05:32:04PM +0100, Wookey wrote:
    I must admit that I have no idea why replacing such a longstanding
    utility is deemed necessary.

    Maybe this riddle will help.

    Imagine that you are the product manager for Debian `which`. According
    to the hatemail in my inbox, this is the most important utility in the
    history of time, such that even printing a warning to stderr causes
    global devastation, block hints, and calls for impeachment. So, it
    makes sense for this to be a full-time job, though perhaps you manage
    another, less significant utility as well.

    You go on a Gemba walk, and discover you have several user personas
    amongst your customers:

    (a) wants GNU `which`, to have feature parity with Red Hat Enterprise Linux
    (b) wants FreeBSD `which`, to have feature parity with FreeBSD
    (c) wants nothing ever to change, and the xiafs removal from Linux 2.1.21
    to be reverted
    (d) wants there to be exactly one version of `which` (except for all the
    shell builtins) so that alternatives won't confuse and complicate things

    Wearing your customer-centricity hat, what is the optimal set of
    personas to unperson so that you can implement a solution that works
    for everyone who still matters?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan Dowland@21:1/5 to YunQiang Su on Mon Sep 20 15:40:01 2021
    On Fri, Aug 20, 2021 at 11:03:50AM +0800, YunQiang Su wrote:
    For such a simple tool, do we really need such many versions?

    At least you've asked the question. I'd love to think that there was a
    proper evaluation of BSD which versus GNU which prior to the latter
    being uploaded to NEW, and there's a compelling reason that the GNU one
    was chosen; but if so there's no evidence of that on -devel. :(


    --
    Please do not CC me for listmail.

    👱🏻 Jonathan Dowland
    jmtd@debian.org
    🔗 https://jmtd.net

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Wookey@21:1/5 to Clint Adams on Mon Sep 20 16:40:03 2021
    On 2021-09-20 04:48 +0000, Clint Adams wrote:
    On Sun, Sep 19, 2021 at 05:32:04PM +0100, Wookey wrote:
    I must admit that I have no idea why replacing such a longstanding
    utility is deemed necessary.

    Maybe this riddle will help.

    Imagine that you are the product manager for Debian `which`. According
    to the hatemail in my inbox, this is the most important utility in the history of time,

    :-)

    such that even printing a warning to stderr causes
    global devastation, block hints, and calls for impeachment.

    I do agree that it's pretty shoddy of bazel to break because a utility
    several layers down issues stderr text whilst still returning a
    success code. And yes I/someone should probably try to actually work
    out why and fix it... But there is a lot of shit code in the world,
    and only so many hours.

    You go on a Gemba walk,

    Never heard of a Gemba walk before, so I learned something today :-)

    Wearing your customer-centricity hat, what is the optimal set of
    personas to unperson so that you can implement a solution that works
    for everyone who still matters?

    I'm not fussy. Any of a,b,c or d would suit me fine. It's just e
    (issue deprecation message), which caused me trouble.

    Thanks for explaining what the actual problem is. You have my sympathy
    trying to navigate the mess.

    Wookey
    --
    Principal hats: Linaro, Debian, Wookware, ARM
    http://wookware.org/

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEER4nvI8Pe/wVWh5yq+4YyUahvnkcFAmFIm4AACgkQ+4YyUahv nkdbqA/+LL4YGwrTaC9wVxMIPNLRurY2F2Y+IylvSKQmj6DIG0dkzKaXn1Ry3PHG jGo3WiV0H49JNxTLWxkQk38W/aYy3gUztaihm1wnXDizb6FckS9Pn05P3V5B1ARV avESDIVl0UuTblOvFhOWLpbCdC12gibmuM72vJYzMT30QF8Usox15SxMjN+HmVH2 fL5MN/156oBN6tHzxNsFvJVc+q2pR+p+U30Pc5MgzbVhtddzZQTBonsxNxmte+ql 1ohxjWfEOzitJHBoZiptMN4sAYgpad4oaVQsi5wUHIvXzFtqAEEblLDPrK3tI/+p jcsZy+6cE9gdVZUVVE/yMw0sfH0AHL6Hp+pn8/+XNgvArp2Na1Ey929aq2sKHmIl MFl97S3lmDIjlC3b4W3levnUcOJGarsvfbnSsdVzED8JfJB4JsbX5weisiRJf2VA P72Y118rv6M0ffUXro4UAMPFJe1BGQd484/dEK8SI6zAXJt2R97WEqlSYlpLAZYH 1B1+RFbinh8vHJ4qNw0zPozg4gONqfynN28iXPa4g1eCkaRiCC8NZGrYR/M2yUO1 i+cEfTWc13U9aNKbVKeOD4jLPMze5zbdfFCVBDvRp3VuKKakuEeTaNKUjiOi/svo /vfJUw2u97P7a0a4K2vgP9dHON8f/ML2BLSGm8JOupAHe4ZemHo=
    =82Zg
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Stone@21:1/5 to Jonathan Dowland on Mon Sep 20 17:10:02 2021
    On Mon, Sep 20, 2021 at 02:38:06PM +0100, Jonathan Dowland wrote:
    On Fri, Aug 20, 2021 at 11:03:50AM +0800, YunQiang Su wrote:
    For such a simple tool, do we really need such many versions?

    At least you've asked the question. I'd love to think that there was a
    proper evaluation of BSD which versus GNU which prior to the latter
    being uploaded to NEW, and there's a compelling reason that the GNU one
    was chosen; but if so there's no evidence of that on -devel. :(

    It seems to install to /usr/bin/which.gnu, implying that you could
    upload /usr/bin/which.bsd if you so desire; what's the issue?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan Dowland@21:1/5 to Michael Stone on Tue Sep 21 10:10:01 2021
    On Mon, Sep 20, 2021 at 11:02:49AM -0400, Michael Stone wrote:
    It seems to install to /usr/bin/which.gnu, implying that you could
    upload /usr/bin/which.bsd if you so desire; what's the issue?

    I think we should have just one which implementation in the archive. We
    should (have) pick(ed) the best one for Debian. I believe (perhaps
    unfairly... I'd love to be proven wrong) that the GNU implementation was uploaded very quickly, without the BSD implementation being considered.
    Perhaps the GNU one is the best fit for our needs. It would have been
    nice to see that there was an evaluation.

    --
    Please do not CC me for listmail.

    👱🏻 Jonathan Dowland
    jmtd@debian.org
    🔗 https://jmtd.net

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Stone@21:1/5 to Jonathan Dowland on Tue Sep 21 22:20:02 2021
    On Tue, Sep 21, 2021 at 09:00:52AM +0100, Jonathan Dowland wrote:
    On Mon, Sep 20, 2021 at 11:02:49AM -0400, Michael Stone wrote:
    It seems to install to /usr/bin/which.gnu, implying that you could
    upload /usr/bin/which.bsd if you so desire; what's the issue?

    I think we should have just one which implementation in the archive. We >should (have) pick(ed) the best one for Debian. I believe (perhaps >unfairly... I'd love to be proven wrong) that the GNU implementation was >uploaded very quickly, without the BSD implementation being considered. >Perhaps the GNU one is the best fit for our needs. It would have been
    nice to see that there was an evaluation.

    I think it doesn't matter how many which implementations are in debian.
    If you want something with specific portable semantics, just use command
    -v. The remaining consumers of which are either programs that (ipso
    facto) don't care about semantic corner cases or are humans who want to
    use which just because, and probably have strong opinions on how it
    should behave (as, apparently, you do). We can't satisfy everybody with
    one implementation, and I see no technical reason that we'd even try to
    do so.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nicholas D Steeves@21:1/5 to Michael Stone on Tue Sep 21 23:50:01 2021
    Michael Stone <mstone@debian.org> writes:

    On Tue, Sep 21, 2021 at 09:00:52AM +0100, Jonathan Dowland wrote:
    On Mon, Sep 20, 2021 at 11:02:49AM -0400, Michael Stone wrote:
    It seems to install to /usr/bin/which.gnu, implying that you could >>>upload /usr/bin/which.bsd if you so desire; what's the issue?

    I think we should have just one which implementation in the archive. We >>should (have) pick(ed) the best one for Debian. I believe (perhaps >>unfairly... I'd love to be proven wrong) that the GNU implementation was >>uploaded very quickly, without the BSD implementation being considered. >>Perhaps the GNU one is the best fit for our needs. It would have been
    nice to see that there was an evaluation.

    I think it doesn't matter how many which implementations are in debian.
    If you want something with specific portable semantics, just use command
    -v. The remaining consumers of which are either programs that (ipso
    facto) don't care about semantic corner cases or are humans who want to
    use which just because, and probably have strong opinions on how it
    should behave (as, apparently, you do). We can't satisfy everybody with
    one implementation, and I see no technical reason that we'd even try to
    do so.

    +1 for everything above. I also think it may be more reasonable to
    prefer (by default, using the alternatives mechanism) the more LSBish
    one (in this case GNU) rather than the potentially more simple, clean,
    and full-featured one (BSD). For precedent see netcat-traditional vs netcat-openbsd, and GNU tar vs bsdtar and pax--particularly during the
    time when bsdtar was superior (iirc) to GNU tar.

    I also acknowledge that this may entrench the precedent of preferring a GNU/Linux-standard solution that may not be the technically best. For
    the record, I seem to remember using bsdtar for the period of time when
    GNU tar had some issue or another (or was it a missing feature? Maybe
    xattr, sparse file support, or acl-related?), and I also have a strong
    personal preference for netcat-openbsd.

    Thankfully we have the /etc/alternatives and Provides mechanisms to
    affirm user choice in such cases, and I think most of us will agree this
    is a totally equitable and reasonable compromise :-)

    Regards,
    Nicholas

    --=-=-Content-Type: application/pgp-signature; name="signature.asc"

    -----BEGIN PGP SIGNATURE-----

    iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmFKUZ0QHHN0ZW5AZGVi aWFuLm9yZwAKCRBaiDBHX30QYXCID/wKjg03crg1TxZz5CrAz794MK/D44ikfiow ndOS2aiG7ADHuHUazlU+BH2b6XtZI6Dh1gu6ugYtfKyq7OcPo0j+cjfDtS14Ov07 i2PMCz+0hlIVfN1L6nGoVpPaDhfgnVsIjcRyKFa7Y8/MLIdlyDC8v1g2PhNqEXf/ 6RFQ/dAiF5evfuRrpeBvo8FEcDU7fHlvsGOSC93DmoaNIQtjMuGZJftgqzCVJp6k dZtvtCdJ4S6642BgAAK7XYtL1rseGhbql9X4OMA9dURXaQCMObWWDuuPOYJEf3n1 YveaF23IT2eXZI2b2hADGt9X+BmzC6H7zf1eIYuE5ysvQdrFprChSSs4jhA8ojlZ fgWt1AEXoDk32EiTh1JB3K+FZMFyXHdZZ7PxMwTEUrt+j3igBv94rts+LQQs/fH/ 25i4do2F1zvHNM2XVVLwTG8wI9YNoOZRwGK2cWGIYxVjh9c7wQkX09pC26Z/ls4h Cg3Xv9c+fFEYdACIQH422dQqxF/Uu2jnP2JwLHyU2RJdSGuYoPZnriVMLkx/6ASf Ezy+A/1h/KhmVKoX6vVkexNjRd5w/x0MX6Hrvy1SZ7xp2Rknbl3H9mnyM+aMPlPG 35hqGLeMUulMASlAIvc+aUO1joL3l/RrGJDtjjhY1Buhyke0v2qvuXLz5eMp90uL Vs5XyrMoCA==Ixyk
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From The Wanderer@21:1/5 to Michael Stone on Wed Sep 22 05:00:01 2021
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
    On 2021-09-21 at 16:16, Michael Stone wrote:

    On Tue, Sep 21, 2021 at 09:00:52AM +0100, Jonathan Dowland wrote:

    On Mon, Sep 20, 2021 at 11:02:49AM -0400, Michael Stone wrote:

    It seems to install to /usr/bin/which.gnu, implying that you
    could upload /usr/bin/which.bsd if you so desire; what's the
    issue?

    I think we should have just one which implementation in the
    archive. We should (have) pick(ed) the best one for Debian. I
    believe (perhaps unfairly... I'd love to be proven wrong) that the
    GNU implementation was uploaded very quickly, without the BSD
    implementation being considered. Perhaps the GNU one is the best
    fit for our needs. It would have been nice to see that there was an
    evaluation.

    I think it doesn't matter how many which implementations are in
    debian. If you want something with specific portable semantics, just
    use command -v.

    I think I've seen that suggested a lot as an alternative for 'which',
    but it doesn't seem to be comparably reliable in all contexts.

    The primary issue I've run across to date is with aliases.

    For example, on my computer as I type this:

    $ which ls
    /usr/bin/ls
    $ command -v ls
    alias ls='ls -N --color=auto'
    $ $(which ls) /
    bin home lib32 media pulse srv var
    boot initrd.img lib64 mnt root sys vmlinuz
    dev initrd.img.old libx32 opt run tmp vmlinuz.old
    etc lib lost+found proc sbin usr
    $ $(command -v ls) /
    bash: alias: -N: not found
    bash: alias: /: not found

    And then 'ls' is broken in that shell session; I haven't yet found a way
    to get it working again, short of exiting and re-launching the shell.
    (Though I also haven't tried *terribly* hard.)

    This seems to demonstrate that you can't safely just use 'command -v'
    wherever you would otherwise use 'which'.

    --
    The Wanderer

    The reasonable man adapts himself to the world; the unreasonable one
    persists in trying to adapt the world to himself. Therefore all
    progress depends on the unreasonable man. -- George Bernard Shaw


    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEEJCOqsZEc2qVC44pUBKk1jTQoMmsFAmFKmgYACgkQBKk1jTQo MmtQ3A//daC+70SuRiMPH0heBwVJK6gldngukiBf0vI1kh9xxXdfrNRcHSztGMCI BKF5JFIJ71byZ4FRLGiSqmrknK3ZB5gTV84DgzjvOdUlYYgzLiXXt3B77X1G7Yd+ JIiL4fi2KlVh/rzTJN2j12UL9IigD2XMMDZmEj2QMpwQqps868/00wYH2m5OwNJH t7k8L+auMHnJPc9pLwJcxRPLMU3PfXjtEIungPEs+CUTDqv0BqUY/pJuN/FZ1hIo vvkNuOa1HluS63YjPHFUps3GNuc7a/SMx+mMabWE6MqPrp6HfdcFY2xPiW7HAz5t 0V8LKu961VHIMYKyzcaUlwEOyeHVicDQ/zb7q36ooVQwsvYIr4dD+2E7uU8CTl16 YmIbh4JAG9NzfbwnsB1ExWTjkqalucXmVRjLyzQlOcsmztBA/Q1toNfzRe1EEmPm YVBtnXH3aRFaIF5NDM2Abp3/4ydIyIU/+cuQ+VH+b413Ne0TVeCENpNFreQiNXWy FSPmGKvyzxXOZ6h1uxa0Htzh+F0kK0AP2TGjEU4573YLsLMreIOEBF6UtqXYvRxk X3fLGYwF8MAMFV+f9OtV+JK93exo0LEHtGLCUsQo1XtSarKx4YOKpVwceguJr+/R 0+WL0ZuEbIjxRQQuWBIZNOgWSy5/
  • From Russ Allbery@21:1/5 to The Wanderer on Wed Sep 22 06:50:01 2021
    The Wanderer <wanderer@fastmail.fm> writes:
    On 2021-09-21 at 16:16, Michael Stone wrote:

    I think it doesn't matter how many which implementations are in
    debian. If you want something with specific portable semantics, just
    use command -v.

    I think I've seen that suggested a lot as an alternative for 'which',
    but it doesn't seem to be comparably reliable in all contexts.

    I don't think the point is that command -v is a drop-in replacement for
    which (it definitely is not). I think the point is that command -v is a standardized, portable interface. If you want portable semantics, the standardized command is command -v, but it doesn't do quite the same thing
    in quite the same way. If you want which, you have to live with the fact
    that it's not portable and different which implementations behave in
    different ways.

    --
    Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fabrice Bauzac-Stehly@21:1/5 to The Wanderer on Wed Sep 22 21:20:02 2021
    The Wanderer <wanderer@fastmail.fm> writes:

    On 2021-09-21 at 16:16, Michael Stone wrote:

    On Tue, Sep 21, 2021 at 09:00:52AM +0100, Jonathan Dowland wrote:

    If you want something with specific portable semantics, just
    use command -v.

    I think I've seen that suggested a lot as an alternative for 'which',
    but it doesn't seem to be comparably reliable in all contexts.

    The primary issue I've run across to date is with aliases.

    I don't know if it is always the case, especially with bizarre zsh
    setups, but on my computers, aliases are not defined in shell scripts,
    only in interactive shells.

    If it's an issue, a shell script can do this beforehand:

    \unalias -a

    See https://pubs.opengroup.org/onlinepubs/009695399/utilities/command.html

    --
    Fabrice Bauzac-Stehly
    PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan Dowland@21:1/5 to Michael Stone on Mon Sep 27 18:00:02 2021
    Michael Stone wrote:
    I think it doesn't matter how many which implementations are in debian.
    If you want something with specific portable semantics, just use command
    -v. The remaining consumers of which are either programs that (ipso
    facto) don't care about semantic corner cases or are humans who want to
    use which just because, and probably have strong opinions on how it
    should behave (as, apparently, you do).

    *I* don't; in Clint's categorization¹ I fall into (d) "wants there to be exactly one version of `which` (except for all the shell builtins) so
    that alternatives won't confuse and complicate things". The point I've
    tried to make (too clumsily I guess) is the process of choosing one
    should not be shoot-from-the-hip: there should be some consideration as
    to which `which` would be the best fit for Debian. I hadn't seen any
    evidence of that, until,

    On Tue, Sep 21, 2021 at 05:41:49PM -0400, Nicholas D Steeves wrote:
    I also think it may be more reasonable to prefer (by default, using the >alternatives mechanism) the more LSBish one (in this case GNU) rather
    than the potentially more simple, clean, and full-featured one (BSD).

    ^ this is an example of exactly what I would have hoped took place to
    decide upon which `which` we provided.

    Thankfully we have the /etc/alternatives and Provides mechanisms to
    affirm user choice in such cases, and I think most of us will agree this
    is a totally equitable and reasonable compromise :-)

    Unless there's a really compelling reason for there to be more than one `which`, we could avoid the burden of alternatives entirely.


    I should get off my soapbox now.


    ¹ Message-ID: <YUgSrpfvtePSFIYn@scru.org>

    --
    Please do not CC me for listmail.

    👱🏻 Jonathan Dowland
    jmtd@debian.org
    🔗 https://jmtd.net

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)