Remove the arithmetic operator on checking download status

ryaminal commented 2 years ago

In an attempt to use if/then instead of || stuff in ZSH an error was made. (( ... )) is for arithmetic and when checking the output of a command this leads to a bad floating point constant error. This, I believe, is due to zsh interpreting the function .zinit-annex-patch-dl-download-file-stdout as a float because of the leading .. See ZSH Arithmetic Evaluation for more information on this. The line of interest states:

Floating point constants are recognized by the presence of a decimal point or an exponent.

Description

Remove the (( ... )).

Motivation and Context

Example output with the (( ... ))

See the following output:

Package: fzf. Selected profile: bgn-binary+keys. Available profiles: bgn, bgn+keys, bgn-binary, bgn-binary+keys, binary, binary+keys, default, default+keys.

Downloading (pack'') junegunn/fzf… (at label: fzf…)
(Requesting `fzf-0.31.0-linux_amd64.tar.gz'…)
######################################################################## 100.0%
ziextract: Unpacking the files from: `fzf-0.31.0-linux_amd64.tar.gz'…
ziextract: Successfully extracted and assigned +x chmod to the file: `fzf'.
za-patch-dl-handler:78: bad floating point constant
[patch-dl annex]: File _fzf_completion downloaded correctly
za-patch-dl-handler:78: bad floating point constant
[patch-dl annex]: File key-bindings.zsh downloaded correctly
za-patch-dl-handler:78: bad floating point constant
[patch-dl annex]: File fzf-tmux.1 downloaded correctly
za-patch-dl-handler:78: bad floating point constant
[patch-dl annex]: File fzf.1 downloaded correctly
bin-gem-node annex: Created the fzf shim and set +x on the fzf binary

The result is that each of those files failed to download(really failed to be written to disk) and then when those files are requested later they don't exist.

Related Issue(s)

Usage examples

zinit light-mode for \
  zdharma-continuum/zinit-annex-meta-plugins \
  annexes \
  ;

zinit for \
  pack"bgn-binary+keys" fzf zdharma-continuum/null \
  ;

How Has This Been Tested?

zinit light-mode for \
  zdharma-continuum/zinit-annex-meta-plugins \
  annexes \
  ;

zinit for \
  pack"bgn-binary+keys" fzf zdharma-continuum/null \
  ;

Output of the load should have no errors. Also, when a new shell is loaded there should be no errors about not being able to find the key-bindings.zsh file.

Types of changes

[X] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

glyh commented 2 years ago

I've test this and it fixed my issues.

vladdoster commented 2 years ago

@ryaminal, thanks for fixing this.

For context about how this bug snuck in is 50% my fault ;) caused by my lack of due diligence to add Zunit tests.

For the other half and how I tried to avoid this issue (logic change in style changes), I apply formatting via the following process:

ggrep -E '^[\:\.\+\_\@]z.*[-_].*[[:space:]]*()*' ${FILE_TO_PARSE} \
| tr -d \(\) \
| awk '{print $1}' \
| xargs > TMP_FORMAT_${FILE_TO_PARSE}

It will extract a list of functions names (in the same order) which is passed to Zsh for formatting

functions -x 2 ${LIST OF FUNCTIONS} > "FORMATTED_${FILE_TO_PARSE}"

the rest of the process is cleaning up the loops, conditional statements, and reinserting comments.

So, All that to say, thanks for reporting, so I am now aware it isn't a foolproof formatter.

zdharma-continuum / zinit-annex-patch-dl