Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use (( )) instead of [[ ]]? #5

Closed
dimitry-ishenko opened this issue Dec 21, 2022 · 12 comments
Closed

Use (( )) instead of [[ ]]? #5

dimitry-ishenko opened this issue Dec 21, 2022 · 12 comments

Comments

@dimitry-ishenko
Copy link
Collaborator

dimitry-ishenko commented Dec 21, 2022

(1) I see bash-utility heavily using

[[ $# -lt 2 ]] && ...

Wouldn't it be more readable to do

(( $# < 2 )) && ...

instead? (( is used for arithmetic evaluation, which is what -lt is trying to force inside [[.

(2) Also, seeing this:

[[ $# = 0 ]] && ...

rubs me the wrong way on multiple levels.

First, we are all taught that = is assignment and == is equivalence comparison. Yes, in bash they are the same when used inside [[, but = is used for assignment elsewhere in bash and IMHO this is just a bad coding practice.

Second, operator = within [[ is used for pattern matching and not arithmetic comparison. So, it should minimally be:

[[ $# -eq 0 ]] && ...

or better yet:

(( $# == 0 )) && ...

to be more readable and consistent with (1).

@dimitry-ishenko
Copy link
Collaborator Author

dimitry-ishenko commented Dec 21, 2022

I've realized I should probably take it up with bash-utility.

I don't see any activity in their repo for the past 2 years, but I've opened the same issue with them: labbots/bash-utility#1

@sgjava
Copy link
Collaborator

sgjava commented Dec 21, 2022

@dimitry-ishenko, knock yourself out if you can find a better bash library. I just didn't want to duplicate a lot of the boilerplate type stuff. I'm not sure how much bash really changes, thus maybe not a lot commits needed. On the plus side you can make all the Armbian stuff clean. I tried to go down the path of functional/procedural programming and not create God scripts or functions.

@dimitry-ishenko
Copy link
Collaborator Author

@sgjava I am not saying the library is bad. I actually like it. But there quite a few things that can be improved. Ideally they would be done upstream, but if they don't respond, I am willing to fork it and do the clean-ups.

@sgjava
Copy link
Collaborator

sgjava commented Dec 21, 2022

@dimitry-ishenko Yeah, exactly, that's why I embedded it into the project. I hate submodules since the project can change (or be deleted) and wreck your project. If you do go the submodule path just maybe create the fork under the Armbian project? I did research bash libraries out there and there aren't many. Anyways, it's all good. I'm mainly a Java, C, C++ and Python dev. I do script a lot with bash, but writing a complete project (or API) in it is more complicated than most folks think. Just missing real data types, etc. makes thing rough in my eyes.

@dimitry-ishenko
Copy link
Collaborator Author

If you do go the submodule path just maybe create the fork under the Armbian project?

IMHO this is the best approach. I don't have access to Armbian, so for now I've made my own fork here:

https://github.com/dimitry-ishenko/bash-utility

If someone could fork the upstream project in Armbian and give me write access, I can work from there. Then it can be added here as a submodule.

FWIW, I've done some clean-ups in the Array module: https://github.com/dimitry-ishenko/bash-utility/blob/master/src/array.sh and submitted PR to upstream. Will see if they respond.

@igorpecovnik
Copy link
Member

If someone could fork the upstream project in Armbian and give me write access, I can work from there.

Invitation sent.

@sgjava
Copy link
Collaborator

sgjava commented Dec 22, 2022

@dimitry-ishenko sure as long as you control the submodule. If you rely on a submodule you don't own and it's deleted then you are screwed. @igorpecovnik hooked you up with access.

@Tearran
Copy link
Member

Tearran commented Jul 17, 2023

Suggest close no fix. Unwarranted use for readability:

In Bash, (( .. )) is an arithmetic construct, while [[ .. ]] is a conditional expression. They serve different purposes and are used in different scenarios.

(( .. )) is used for arithmetic operations and comparisons. For example, you can use it to increment a variable ((i++)), or to compare two numbers ((a > b)).

On the other hand, [[ .. ]] is used for testing conditions. It is an improvement over the [ .. ] command and has several enhancements that make it a better choice if you write scripts that target Bash.

For example, it handles empty strings and strings with whitespace more intuitively, it lets you use && and || operators for boolean tests and < and > for string comparisons, it has a =~ operator for doing regular expression matches, and it lets you do pattern matching
referance;1 referance;2.

So in summary, (( .. )) is used for arithmetic operations while [[ .. ]] is used for testing conditions.

@dimitry-ishenko
Copy link
Collaborator Author

dimitry-ishenko commented Jul 18, 2023

So in summary, (( .. )) is used for arithmetic operations...

You are contradicting yourself:

(( .. )) is used for arithmetic operations and comparisons. For example, you can use it to increment a variable ((i++)), or to compare two numbers ((a > b)).

Unless you include comparison operations into arithmetic operations (which they actually are, but you are seemingly trying to differentiate them).

And, what I was pointing out was that bash-utility incorrectly uses [[ ]] to compare if the number of parameters passed to a function is less than 2 or equal to 0.

@dimitry-ishenko
Copy link
Collaborator Author

BTW I do have a mostly cleaned up version of bash-util here: https://github.com/armbian/bash-util, which was supposed to become the submodule of this repo.

Unfortunately, I have not been able to complete it (due to lack of motivation). I am not sure at this point if it should be abandoned or it could still be added as a submodule and someone could finish cleaning it up concurrently.

@Tearran
Copy link
Member

Tearran commented Jul 18, 2023

The argument was for readability. to be more readable and consistent with (1). And for readability, if this is what works for you and you would like to continue with development, I will agree with the fix. Otherwise, my convoluted point remains. It’s not something that needs fixing, it’s a preference.

@Tearran
Copy link
Member

Tearran commented Jul 18, 2023

Second, post.
Not Shure about submodules and upstream stuff, but the lack of motivation I get.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants