[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#67241: [PATCH] guix-install.sh: Add message about Info reader.
From: |
Simon Tournier |
Subject: |
bug#67241: [PATCH] guix-install.sh: Add message about Info reader. |
Date: |
Mon, 06 Jan 2025 18:37:23 +0100 |
Hi Maxim,
On Thu, 19 Dec 2024 at 16:58, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
> Hm. I agree duplication is not nice. Probably a naming issue ;-)
Arf, as we know: « There are only two hard things in Computer Science:
cache invalidation and naming things. » :-)
> According to git blame these lines were also authored by you 4 years
> ago, ha!
Ah, you got me! ;-) Bah I am consistent.
> It checks the exit status instead of the captured string output. While
> it's not that bad in that case, in general I find checking for the exit
> status a much more reliable and clean option.
Thanks for explaining. I will re-send that way. However, I still think
that’s the same from some Bash point of view…
>> Both $() and "" used in tandem makes the test sound, from my
>> understanding.
>
> Hm. Is [ "something" ] true and [ "" ] false? Apparently it is, but
> I'd argue that's not very clear, especially when there are explicit test
> operations to check for an non-empty or empty string (test -n and test
> -z).
…and welcome to weird Bash. ;-) Maybe I have misread, from my
understanding, this:
if [ "$(type -P foo)" ]
is equivalent to:
if test -n $(type -P foo)
and also equivalent to:
if type -P foo >/dev/null
And I know nothing about internals; maybe some type conversion are
avoided with the latter and some cycles are saved?
Well, it appears to me a matter of taste. :-) I find the former easier
to parse than the latter. But I also fine with the latter; let do that.
Cheers,
simon
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#67241: [PATCH] guix-install.sh: Add message about Info reader.,
Simon Tournier <=