Actually set 'husky_skip_init' as readonly in ./husky.sh

[hyperupcall]

Previously, the husky.sh script would export the empty 'readonly' variable, along with 'husky_skip_init' which has a value of 1.

Now, the script sets 'husky_skip_init' to 1, and properly gives is the 'readonly' and 'exported' attributes.

[typicode]

I may be missing something but I can't seem to reproduce the issue. I tried in bash:

~ 
❯ export readonly husky_skip_init=1

~ 
❯ echo $husky_skip_init
1

[hyperupcall]

Hai,

In both cases, the value of husky_skip_init is 1, the difference is whether the variable is marked as readonly

Before the changes, a variable called readonly was spuriously created

$ export readonly husky_skip_init=1

$ declare -p readonly
declare -x readonly

$ declare -p husky_skip_init
declare -x husky_skip_init="1"

In other words, not readonly

$ export readonly husky_skip_init=1
$ husky_skip_init=2
$ # (no error)

It didn't seem to match up semantically, as in other cases variables were properly marked as readonly

So I changed the code so that husky_skip_init was actually readonly, since it seemed like that was the original intent. After the changes, we get

$ readonly husky_skip_init=1
$ export husky_skip_init

$ declare -p readonly
bash: declare: readonly: not found

$ declare -p husky_skip_init
declare -rx husky_skip_init="1"

As you can see, as a result, the husky_skip_init variable is marked as readonly (-r) and a variable called 'readonly' isn't spuriously created

$ readonly husky_skip_init=1
$ export husky_skip_init
$ husky_skip_init=2
bash: husky_skip_init: readonly variable

It doesn't make a huge difference in terms of behavior since the variable isn't used much or modified, but I'm sure for people not (or less) familiar with shell, the code is less confusing

[typicode]

I see, good catch 👍
Thanks for the very detailed steps.