Hi @Eshaan-byte,

Similar comment as in #716: We want to keep these files as slim as possible. Would it be possible to move this (or probably a similar hack) to ../tools/cleaning-tools.sh?

Also: No need for an issue before a PR, if the PR is anyway on the way.

Hi @MakisH, thanks for the review!

The challenge is that clean.sh sources cleaning-tools.sh via a relative path (../../tools/cleaning-tools.sh), which fails before cleaning-tools.sh even loads when called from a different directory.

A possible approach to keep clean.sh slim: change the source line to resolve from $0 instead of $PWD, and let cleaning-tools.sh handle the cd.

clean.sh (only the source line changes):
#!/usr/bin/env sh
set -e -u

. "$(dirname "$0")/../../tools/cleaning-tools.sh"

clean_openfoam .
cleaning-tools.sh (add at the top):

cd "$(cd "$(dirname "$0")" && pwd)"
This way no extra lines are added to clean.sh -- it stays the same size. Would this approach work for you?

Hi @Eshaan-byte , thanks for the suggestion ,i agree that resolving the source path using dirname "$0" fixes the issue locally.

In the final merged PR #716, i applied a similar idea but made it explicit in each script so they reliably determine their own directory before sourcing anything. This ensures all cleaning scripts are truly callable from any directory, not just when sourcing a helper file. That's the pattern that got approved -- scripts use:
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
cd "$SCRIPT_DIR"

idea was to make the files slim,
This avoids depending solely on the sourced file to set up the correct working directory and makes each script self-contained and robust across environments.
thanks you pointed next time , taking a bit more time to check the actual PR implementation helps avoid that confusion