cpackget fails to list packs while csolution succeeds about cpackget HOT 5 CLOSED

@fred-r as a temporary workaround could you please set the CMSIS_PACK_ROOT variable:

export CMSIS_PACK_ROOT=c:\\CMSIS_PACKS

from cpackget.

Works indeed, thanks !

frq09468@LMECWL0888 MINGW64 /c/Packs
$ export CMSIS_PACK_ROOT=c:\\CMSIS_PACKS

frq09468@LMECWL0888 MINGW64 /c/Packs
$ cpackget pack list
I: Using pack root: "c:\CMSIS_PACKS"
I: Listing installed packs
I: ARM.CMSIS-Driver.2.6.1
I: ARM.CMSIS.5.7.0
I: ARM.CMSIS.5.8.0
I: ARM.mbedTLS.1.7.0
I: ARM.PSA.1.0.0
I: Keil.ARM_Compiler.1.6.3
I: Keil.MDK-Middleware.7.12.0
I: Keil.MDK-Middleware.7.13.0
I: Keil.NUCLEO-L552ZE-Q_BSP.1.2.0
I: Keil.STM32F4xx_DFP.2.15.0
I: Keil.STM32H7xx_DFP.2.8.0
I: Keil.STM32L4xx_DFP.2.6.1
I: Keil.STM32L552E-EV_BSP.1.1.0
I: Keil.STM32L562E-DK_BSP.1.3.0
I: Keil.STM32L5xx_DFP.1.4.0
I: Keil.STM32L5xx_TFM-PF.1.1.0
I: Keil.STM32NUCLEO_BSP.1.8.0
I: Keil.STM32U5xx_DFP.1.1.0
I: STMicroelectronics.board_resources_B-U585I-IOT02A.0.0.1
I: STMicroelectronics.Example_HAL_GPIO_Toggle.0.0.1-alpha1
I: STMicroelectronics.STM32U5xx_DFP.0.1.0-alpha1
I: STMicroelectronics.STM32U5xx_Drivers.0.0.1-alpha1
I: STMicroelectronics.STM32U5xx_Drivers.0.1.0-alpha1

from cpackget.

@fred-r, Thanks for opening the issue!
Which terminal/bash are you using?

from cpackget.

Hi Charles,

I use MinGW64 (installed with git bash).

Thanks & Regards,
Fred

from cpackget.

By default, CMSIS_PACK_ROOT environment variable is defined in a Windows environment as C:\SOME_PATH. Both bash and cmd work fine with that approach.

In git-bash/mingw, if the user tries to export CMSIS_PACK_ROOT=C:\SOME_PATH or --pack-root/-R C:\SOME_PATH, bash automatically removes the backwards slash \ because it is considered to be a escape character, so it becomes C:SOME_PATH, which is a valid directory name. It's wrong, but valid.

I wrongly assumed that this would throw an error when cpackget tried to check if it existed. The colon : character is not allowed in directory names on Windows. But in reality, that does not fail in neither bash nor cmd:

• in bash, this becomes a valid name C:SOME_PATH which Windows later translates it to the unicode character 61498 which is valid.
• in cmd, this becomes SOME_PATH (C: is removed) only, which is still valid.

To fix that, users should either escape all backwards slashes C:\\SOME_PATH\\SUB_DIRor wrap it around single/double quotes cpackget -R "C:\SOME_PATH".

Another finding is that bash paths formatted as /c/SOME_PATH are always translated to C:/SOME_PATH with the forward slash before passing it to cpackget. And this is where things get confusing, because when cpackget lists installed packs, and they all start with C:\SOME_PATH. This means that cpackget will never receive paths in /c/SOME_PATH format. It seems this is just a visualization feature of bash.

By using the correct approach to set the path, cpackget works just fine.

So I created this patch to fix cases where paths like C:/SOME_PATH are sent to cpackget. The following paths are now cleared before being used by cpackget:

• C:/SOME-PATH becomes C:\SOME_PATH
• C:////SOME_PATH becomes C:\SOME_PATH
• C:\\\\SOME_PATH becomes C:\SOME_PATH
• C:/SOME_PATH\SUBDIR becomes C:\SOME_PATH\SUBDIR, and so on

from cpackget.