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

Tab completion support for additional archives for 'borg delete' #5655

Merged
merged 2 commits into from
Jan 31, 2021

Conversation

SanskritFritz
Copy link
Contributor

Bash and Fish tab completions now too support more than just one archive provided for 'borg delete'.

Bash and Fish tab completions now too support more than just one
archive provided for 'borg delete'.
@ThomasWaldmann
Copy link
Member

can anybody familiar with completions review this please?

@SanskritFritz
Copy link
Contributor Author

@oxiedi maybe?

@oxiedi
Copy link
Contributor

oxiedi commented Jan 28, 2021

I know almost nothing about Bash's completion system and Fish, thus I can only review code in bash.

# If there is a space before the "::" it means that no repository name was typed,
# so probably $BORG_REPO was set and we can still list the archives.
local repository_name=`expr match "${COMP_LINE}" "\(.*\)::"`
repository_name=${repository_name##* }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need to call an external command and hide its return code in order to do some matching. Can be replaced with local repository_name="${COMP_LINE%%::*}". It would be better to match against the second positional argument, but I don't how to do it using bash-completion.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice one, thanks for that!

local typed_word=""
local please_list_the_archives=false
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's common to use arithmetic expressions as booleans:

local -i list_archives=0

It's unusual to use articles in variable names. Also, the please part doens't seem to serve any purpose. Plain list_archives maybe?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I just tried to be funny 😄 On the other hand I did come up with list_archives first, but it seemed not to express the boolean nature of the variable and it was too similar to archive_list which is a list indeed.

# so probably $BORG_REPO is set.
repository_name=""
fi
if [[ $please_list_the_archives = true ]] ; then
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you are going to use an arithmetic expression as boolean, than it can be done like thie:

if (( $list_archives )); then

If not, then one equal sign is inconsistent with the previous conditions (should be ==).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My goodness, that's a bug for sure, thanks for catching it. I'll fix this and also think about what you said of booleans.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not a bug, just a minor inconsistency.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I thought it would behave like in C as it becomes an assignment instead of comparison.

@oxiedi
Copy link
Contributor

oxiedi commented Jan 28, 2021

I've manually tested it and with a few assumptions (repository should have the :: suffix, spaces as word separators), it works as expected.

@ThomasWaldmann
Copy link
Member

just tell me when this / the other PR is ready to merge.

@SanskritFritz
Copy link
Contributor Author

It is now ready, maybe @oxiedi can check it again?

@SanskritFritz
Copy link
Contributor Author

just tell me when this / the other PR is ready to merge.

@ThomasWaldmann I think it's ready.

@ThomasWaldmann ThomasWaldmann merged commit 9ecdf19 into borgbackup:1.1-maint Jan 31, 2021
@ThomasWaldmann
Copy link
Member

Thanks!

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

Successfully merging this pull request may close these issues.

3 participants