cancel
Showing results for 
Search instead for 
Did you mean: 

$PWD returns an empty string when called from STMCubeIDE 1.14.0

SKape
Associate II

Hello.

I found one more problem with the latest version of STM32CubeIDE 1.14.0
I am using STM32CubeIDE under Windows 7
I have the latest "git for Windows" installed, which provides me with a bash console. The directory with the bash command is added to the system path.
Before compilation, I run a bash script that obtains data from GIT and places it in the header file.
The script is run with the "bash prebuild.sh" command entered in Pre-build steps in the project properties.
The script works correctly if run directly from the bash console or the previous version of STMCubeIDE 1.13.2
If it is called from the latest version of STMCubeIDE 1.14.0, the $PWD variable or the pwd command in the script return an empty string instead of the current path.
What could be the problem with this behavior?

7 REPLIES 7
Peter BENSCH
ST Employee

I would like to point out that STM32CubeIDE 1.14.0 no longer supports Windows 7, which can also be found in the release notes RN0114, section 1.2:

Supported operating systems and architectures

  • Windows® 10 and 11, 64 bits (x64)
  • Linux®: Ubuntu® LTS 20.04 and LTS 22.04, and Fedora® 36
  • macOS® 12 (Monterey), macOS® 13 (Ventura)

Regards
/Peter

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
fronders
Senior

@Peter BENSCH Hi :)
I too have a similar problem with pre-build & post-build scripts, on Windows 10 x64 with the latest BusyBox v1.31.0.st_20231030-1215 & included make tools with CubeIDE v1.14.0 (plugin com.st.stm32cube.ide.mcu.externaltools.make.win32_2.1.100.202310302056).

It used to work okay on CubeIDE v1.13.2 which included BusyBox v1.31.0.st_20200221-0903_longpath (plugin com.st.stm32cube.ide.mcu.externaltools.make.win32_2.1.0.202305091550). 


I'm experiencing problems not only with the $PWD outputting blank line.
mv command fails with 'Result too large' in a pre-build script. 

 

Here is the script (added some prints for debugging):

 

 

#!/bin/bash -
# prebuild script

# update git version and build timestamp
versionfile="../Inc/git_version.h"
version_git=`git describe --dirty --always`
echo "git version: \"$version_git\""
echo "#define GIT_VERSION \"$version_git\"" > tempver
build_time=`date +"%Y-%b-%d %T"`
echo "build time: \"$build_time\""
echo "#define BUILD_TIME \"$build_time\"" >> tempver


echo ""
echo "PWD output: $PWD"
echo ""
echo "tempver file:"
ls -l tempver && cat tempver
echo ""
echo "versionfile:"
ls -l $versionfile && cat $versionfile
echo ""

if cmp -s tempver $versionfile
then
  rm tempver
else
  mv tempver $versionfile
fi

exit 0

 

 

 

This is the output, you can see paths to files resolve okay, and the access rights are also okay, their content is printed, but mv fails:

 

 

13:33:17 **** Incremental Build of configuration Debug for project app_test ****
make -j8 all
"../prebuild.sh"
git version: "g9cee9c1-dirty"
build time: "2023-Dec-04 13:38:09"

PWD output:

tempver file:
-rw-rw-r-- 1 alexa alexa 91 Dec 04 13:38 tempver
#define GIT_VERSION "g9cee9c1-dirty"
#define BUILD_TIME "2023-Dec-04 13:38:09"

versionfile:
-rw-rw-r-- 1 alexa alexa 79 Dec 03 11:25 ../Inc/git_version.h
#define GIT_VERSION "g9cd0444-dirty"
#define BUILD_TIME "2023-Dec-03 11:25:53"

mv: can't rename 'tempver': Result too large

make[1]: Nothing to be done for 'main-build'.

 

 

 

If I replace the busybox binaries to older ones from CubeIDE v1.13.2 everything is back to normal and mv is successful

 

13:55:37 **** Incremental Build of configuration Debug for project app_test ****
make -j8 all 
"../prebuild.sh"
git version: "g9cee9c1-dirty"
build time: "2023-Dec-04 13:55:40"

PWD output: C:/Users/alexa/Repo/app_test/Debug

tempver file:
-rw-rw-r--    1 alexa    alexa           91 Dec 04 13:55 tempver
#define GIT_VERSION "od_v0.101-5-g9cee9c1-dirty"
#define BUILD_TIME "2023-Dec-04 13:55:40"

cat versionfile:
-rw-rw-r--    1 alexa    alexa           79 Dec 03 11:25 ../Inc/git_version.h
#define GIT_VERSION "g9cd0444-dirty"
#define BUILD_TIME "2023-Dec-03 11:25:53"

... rest of the build logs (compiler etc)

 

 

awiernie
Senior II

I have the same problem after updating to STM32CubeIDE 1.14 (on Windows 11).

I have a postbuild.sh which has lines wich should get the working directory like this:

current_directory=`pwd`

This is empty. 

$pwd delivers also an empty string.

 

Ernst

I have the same problem on Windows 11, see below.

awiernie
Senior II

I have now 2 external tools subdirectories. Is it possible to select it somewhere in the IDE/or project settings in order not to have to reinstall the old STM32CubeIDE?

Rim LANDOLSI
ST Employee

Hello and welcome to the community,  

 

Thank you for your contributions, the issue is related to busybox binaries.  An internal ticket ID 167912(This is an internal tracking number and is not accessible or usable by customers) has already been submitted to escalate this issue internally to the STM32CubeIDE team.

 

Thanks,

Rim

Hello @Rim LANDOLSI,

this issue seems to be addressed in CubeIDE v1.14.1 patch and that indeed fixed the $PWD being empty and mv spitting out "Result too large" error.

 

However, after updating to v1.14.1 the mv command keeps failing but with a different error now:

echo "test" > tempobj
mv -f tempobj "test.txt"
test -f tempobj && cat tempobj || echo "no tempobj file"
test -f "test.txt" && cat "test.txt" || echo "no test.txt file"

runs okay the first time:

15:41:29 **** Incremental Build of configuration Debug for project test ****
make -j8 all 
bash ../prebuild.sh
no tempobj file
test 

arm-none-eabi-gcc ...
...

but gives an error on the next ones (because test.txt already exists):

15:42:59 **** Incremental Build of configuration Debug for project test ****
make -j8 all 
bash ../prebuild.sh
mv: can't rename 'tempobj'
test
test
 
arm-none-eabi-gcc ...
...

Using mv -f does not help either.

So far I have been able to "hack" all my mv commands with cp+rm which kinda solves the issue, so the prebuild script at least works, but this needs to be addressed and fixed