You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Then move your home directory to a new disk such that the /path/to/my/current/working/directory/ is or should be considered to be no longer valid. This occurred due to a disk failure whereby I had to move some links around such with the net effect that readlink -f $HOME before the outage is now different from what it was prior to the previous invocation of qmk setup ... above.
Cd into the new directory where we wish to have the qmk_firmware directory to be installed into, and then again run the qmk setup ... command. Do a ls -l qmk_firmware and be surprised that it does not exist.
Analysis/speculation
After some debugging, realize that the old /path/to/my/current/working/directory/ actually still does exist but notice the readlink -f above: What I think is happening is that the qmk setup command is just reading the user.qmk_home configuration value from the ~/.config/qmk/qmk.ini file which is still stuck on the old/path/to/my/current/working/directory/ value that still does exist but exists on the old harddrive. And if my theory is correct, the defect here is this: I, the user, specified -H qmk_firmware on the qmk setup command line, yet the old value was still read from the .ini file. This is unexpected: I instead expected that the .ini file value of user.qmk_home to be overridden by the value passed to the -H option, which really means to only use the qmk_firmware as the location, which is relative to the current working directory and not the old value found in the ~/.config/qmk/qmk.ini file.
My hackaround
I hack around this via:
./runenv qmk config user.qmk_home=$$(pwd)/qmk_firmware # <-- because qmk setup ... -H completely ignores the -H option and continues to use ~/.config/qmk/qmk.ini values.
./runenv qmk setup zsa/qmk_firmware --yes -b firmware22 -H qmk_firmware
ls -ld qmk_firmware # <-- If this gives a no such file or directory error, then the defect is still extant.
Not applicable, IMO, because if my theory is correct, this is a cart-before-the-horse problem between .ini files and command line options, the latter of which should **override** the .ini values.
Is AutoHotKey / Karabiner installed
AutoHotKey (Windows)
Karabiner (macOS)
Other keyboard-related software installed
No response
Additional Context
No response
The text was updated successfully, but these errors were encountered:
Describe the Bug
Context
This is running on Xubuntu 22.04, using qmk gotten using:
I'm using the instructions found here: https://github.com/zsa/qmk_firmware/#building:~:text=head%20to%20the%20Newbs%20guide%20from which is based upon QMK, and thus I found the defect originating from QMK and not those instructions, and not specific to the
zsa/qmk_firmware
keyboard(s).Steps to reproduce
Execute
qmk setup zsa/qmk_firmware --yes -b firmware22 -H qmk_firmware
And then
.config/qmk/qmk.ini
gets written with:Then move your home directory to a new disk such that the
/path/to/my/current/working/directory/
is or should be considered to be no longer valid. This occurred due to a disk failure whereby I had to move some links around such with the net effect thatreadlink -f $HOME
before the outage is now different from what it was prior to the previous invocation ofqmk setup ...
above.Cd into the new directory where we wish to have the
qmk_firmware
directory to be installed into, and then again run theqmk setup ...
command. Do als -l qmk_firmware
and be surprised that it does not exist.Analysis/speculation
After some debugging, realize that the old
/path/to/my/current/working/directory/
actually still does exist but notice thereadlink -f
above: What I think is happening is that theqmk setup
command is just reading theuser.qmk_home
configuration value from the~/.config/qmk/qmk.ini
file which is still stuck on the old/path/to/my/current/working/directory/
value that still does exist but exists on the old harddrive. And if my theory is correct, the defect here is this: I, the user, specified-H qmk_firmware
on theqmk setup
command line, yet the old value was still read from the .ini file. This is unexpected: I instead expected that the .ini file value ofuser.qmk_home
to be overridden by the value passed to the-H
option, which really means to only use theqmk_firmware
as the location, which is relative to the current working directory and not the old value found in the~/.config/qmk/qmk.ini
file.My hackaround
I hack around this via:
Keyboard Used
zsa/qmk_firmware
Link to product page (if applicable)
https://github.com/zsa/qmk_firmware
Operating System
Xubuntu 22.04
qmk doctor Output
Is AutoHotKey / Karabiner installed
Other keyboard-related software installed
No response
Additional Context
No response
The text was updated successfully, but these errors were encountered: