All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: Petr Vorel <petr.vorel@gmail.com>
Cc: buildroot@buildroot.org
Subject: Re: [Buildroot] [RFC PATCH 0/2] use `command -v' instead of `which'
Date: Thu, 30 Sep 2021 22:41:23 +0200	[thread overview]
Message-ID: <20210930204123.GQ1504958@scaer> (raw)
In-Reply-To: <YVYbAxgEomvMo5IQ@pevik>

Petr, All,

On 2021-09-30 22:16 +0200, Petr Vorel spake thusly:
> > Petr, Arnout, All,
> > On 2021-09-26 23:32 +0200, Arnout Vandecappelle spake thusly:
> > > On 21/09/2021 22:51, Petr Vorel wrote:
> > > >I've tested the patchset on dash as the default shell. But it certainly
> > > >deserve more people to have look and test.
> > >  Well, as the commit message says: it's POSIX so it should be supported by
> > > everything. which has a much smaller chance of being supported.
> > This is causing quite some issues.
> 
> > First, 'command -v' does not behave the same way 'which' used to, when
> > passed more than one parameter, because some shells are not compliant to
> > POSIX (this might be a bug, but nonetheless it affects the most widely
> > used shell out there, bash) [0].
> Yes, there has been a proposal, how to fix this.

The problem I see with that proposal, is that it catters for a few
variables only. We might not even notice until much later that something
else is borken in some weird ways... And we were lucky that Markus did
the investigation and was able to find the actual root cause.

> > Second, this is causing a lot of error messages:
> >     $ make defconfig
> >     [...]
> >     $ make help
> >     make[1]: command: Command not found
> >     [...]
> New error. But I was not able to reproduce it on x86_64 on current master
> (5916cc5011). What am I missing to reproduce it?

I'm on a bog-down standard Ubuntu 20.04, prety up-to-date. My /bin/sh is
bash.

> > The original commit reports that 'which' is broken in Debian, but I was
> > not able to reproduce in Bullseye, where 'which' still works as expected
> > and does not emit any extra warning.
> Yes, the waring is in debianutils 5.x, which is still in Debian unstable (not
> even in the testing) [1].
> 
> > So, we are trying to fix something that is broken on a development
> > version of Debian, but that still works in all known released
> > distributions.
> 'command -v' and 'type' has been here quite long time as well.

I am not denying this. I'm just saying that we are trading a working
situation in all released distributions and a failure in Debian
unstable, for a failure in a quite a lot, in not most, of the previously
working cases.

> > I usually am quite in favour of sticking to POSIX tools, but which has
> > been ubiquitous in the past 30 years or so, and I would consider that
> > Debian's which *is* broken for reporting such deprecation warnings.
> 
> > So, I suggest that we do revert this patch, and work on a better
> > transition away from which, if at all. One very quick solution would be
> > to bundle our own which in Buildroot and then we'd have a quick way out
> > of that Debian's mess...
> Sure, if it causes problems which are not easily fixed, I'm not against
> reverting it. But I don't think that problem is that complex, that we'd need to
> compile which.

which is a shell script in Debian; we need not compile it at all. Let's
just grab the latest working which that did not have that warning:

    $ file /usr/bin/which
    /usr/bin/which: POSIX shell script, ASCII text executable

> But I apologize for causing troubles.

Do not apologise, this is not needed. The trouble (as you say) is
standard development issues that will eventually be resolved, one way or
another, no worries. ;-)

Thank you! :-)

Regards,
Yann E. MORIN.

> Kind regards,
> Petr
> 
> > Anyway, I'd vote "revert".
> 
> > Regards,
> > Yann E. MORIN.
> 
> > [0] https://lore.kernel.org/buildroot/YVTIghzHs82uFBIe@pevik/T/#m95c17eb8374e4e3dd6eee700d397aa12cca0739e
> [1] https://tracker.debian.org/pkg/debianutils

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2021-09-30 20:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-21 20:51 [Buildroot] [RFC PATCH 0/2] use `command -v' instead of `which' Petr Vorel
2021-09-21 20:51 ` [Buildroot] [RFC PATCH 1/2] make: support: " Petr Vorel
2021-09-21 20:51 ` [Buildroot] [RFC PATCH 2/2] support/dependencies: don't check for `which' Petr Vorel
2021-09-26 21:32 ` [Buildroot] [RFC PATCH 0/2] use `command -v' instead of `which' Arnout Vandecappelle
2021-09-30 20:04   ` Yann E. MORIN
2021-09-30 20:16     ` Petr Vorel
2021-09-30 20:41       ` Yann E. MORIN [this message]
2021-10-01 18:03       ` Yann E. MORIN
2021-10-02 19:22         ` Petr Vorel
2021-10-03  9:49           ` Arnout Vandecappelle
2021-10-03 18:05             ` Petr Vorel
2021-10-09 10:01             ` Peter Korsgaard
2021-10-10 21:12               ` Petr Vorel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210930204123.GQ1504958@scaer \
    --to=yann.morin.1998@free.fr \
    --cc=buildroot@buildroot.org \
    --cc=petr.vorel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.