get_docopts.sh downloads 32-bit build instead of 64-bit on macOS Catalina

[aerz]

Hi.

I'm trying to use docopts on a side project, so I've cloned the repo and executed get_docopts.sh to download the build. Unfortunately it downloads the 32-bit build.

I noticed arch command is used in the script, which returns me i386. This mismatch happens because arch doesn't work in the same way on macOS as it's mentioned here: https://stackoverflow.com/questions/12763296/os-x-arch-command-incorrect

Could be fixed checking uname -m command and comparing with ARCH variable when macOS is detected.

[Sylvain303]

hi @aerz

Thanks for your debug, I will merge this code and adapt the get_docopts.sh and test accordingly.

[Sylvain303]

Hi @aerz

Thanks reporting this issue. I corrected it and add some test for it.

I also released a new version v0.6.3-rc2, which only change a single feature in docopts.sh helper.

But I took this opportunity to apply many internal changes which was overdue.
That's why I've been so long for a single line of code. 😉

I'm curious in what project are you using docopts?
How did you discover this tool?

The get_docopts.sh should now work as expected on macos, and is passing travis test on macos.

Regards,
Sylvain.

[aerz]

Hi @Sylvain303

Sorry for taking so long to respond.
I appreciate the fix, you did it really fast. 😋 I suggested a quick fix but it was a dirty way, so no problem about you didn't take it.

I'm using docopts in a dotfiles wrapper to get the help message and parse arguments easily. It needs more work but you can take a look here.

And I discover docopts because other devs are using it in their dotfiles (python implementation) and I found it really useful as well.

I'll update to the new version. Thanks again! 😁

[Sylvain303]

Hi @aerz

Your code:

docs::extract_help() {
  local -r file="$1"
  grep "^##?" "$file" | cut -c 5-
}

https://github.com/aerz/dotfiles/blob/183b043982b2ff0b4627e1400bd6baf4b1330e52/scripts/_core/docs.sh#L1-L4

doctopts.sh have a similar function docopt_get_help_string():

docopts/docopts.sh

Lines 34 to 75 in 791ff6e

	docopt_get_help_string() {
	local myfname=$1
	# filter the first block starting at a "# Usage:" and ending at an empty line
	# one level of comment markup is removed.
	awk '
	BEGIN { u=0; l=0 }
	# we catch the first Usage: match
	/^# Usage:/ {
	if(u == 0)
	{
	u=1
	}
	}
	# match all lines. (Usage: is also matched)
	{
	if(u == 1) {
	# append to an array
	usage[l]=$0
	l++
	}
	}
	# empty line
	/^$/ {
	if(u == 1)
	{
	# stop parsing when empty line found
	u=2
	}
	}
	# display result and format output
	END {
	for(i=0; i<l; i++) {
	# remove comment
	sub("^# {0,1}", "", usage[i])
	print usage[i]
	}
	}
	' < "$myfname"
	}

which is the code I changed in the version 0.6.3-rc2. I changed sed for awk to filter only the first bloc of code.

You can test it that way by script or interactively:

# it works docopts.sh if in the $PATH
source docopts.sh
docopt_get_help_string my_file.sh

I noticed:

https://raw.githubusercontent.com/aerz/dotfiles/master/install is a 404 in your README.md I guess
you want installer (+ER at the end).

You can close this issue if it works as expected.

[aerz]

Hi @Sylvain303,

Thanks for spend some time revising my code. I'll make some changes soon to use the docopts helpers. 🙂

I would like to suggest one thing for README file. I've tested docopts in my Raspbery Pi in which I've installed Raspbian. Raspbian comes with mawk by default and some many tests fails, this is the output:

 ✓ extract_markup
 ✓ parse_input
 ✓ to_filename
 ✓ markdown_extract_link
 ✓ strpos
 ✓ get_usage
 ✗ find_end_content
   (in test file ./build_doc.bats, line 89)
     `[[ $output -eq 10 ]]' failed
 ✓ include
 ✓ bats bug fail to printf -v var
 ✓ eval_wrapper
 ✗ build_sed_cmd
   (in test file ./build_doc.bats, line 141)
     `[[ $output == $expect ]]' failed
 ✓ extract_markup free character
 ✓ docopt_auto_parse testing internal behavior
 ✓ docopt_auto_parse -G for globals
 ✓ docopt_auto_parse functional testing associative array
 ✓ docopt_auto_parse -G functional testing globals variables
 ✓ no source
 ✓ global eval
 ✓ docopts error
 ✓ --no-declare
 ✓ docopt_get_help_string
 ✗ docopt_get_help_string with Options (this test may fail if bats fix their issue #224)
   (in test file ./docopts.bats, line 65)
     `[[ "${lines[1]}" =~ $regexp ]]' failed
 ✗ docopt_get_help_string with with 2 Usage:
   (in test file ./docopts.bats, line 102)
     `c=$(grep -c '^Usage:' <<< "$output")' failed
 ✓ docopt_get_values
 ✓ docopt_get_eval_array
 ✓ docopt_get_raw_value
 ✓ docopt_print_ARGS
 ✓ docopt_print_ARGS -G
 ✓ docopt_get_version_string from $0
 ✓ bash strict mode docopt_print_ARGS
 ✓ download binary with get_docopts.sh
 ✓ get_docopts.sh use another repository
 - arch 64bits detection on macos (skipped: only on macos, this OS is: linux-gnueabihf)

33 tests, 4 failures, 1 skipped

I noticed the problem is because there are many implementations around awk (mawk, nawk, gawk, awk) and if I install gawk, the tests works. So, maybe it would be useful to add gawk in GNU/Linux distros is required to run docopts. I didn't use awk too much and it wasn't obvious for me. I can do a PR if you don't want to spend time.

I see you're working in #22 to cover this, but it would add value to users who use other distros, I guess.

Back to the issue, get_docopts.sh script works fine on the latest release and the issue is fixed. 🥳

Regards!