Skip to content

Bash ${VAR} source: track literal assignments to avoid a wrong-directory false positive #2172

Closed

Description

@safishamsi

Follow-up to #2079 / #2139. That fix resolves source "${VAR}/lib/x.sh" by stripping the leading expansion and resolving the literal suffix against the script's own directory (the BENCH_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" idiom). When the variable does NOT equal the script dir and a same-named decoy exists under the script dir, it binds to the wrong file.

Verified false positive: scripts/deploy.sh with ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)" sourcing "${ROOT}/lib/utils.sh" (real target <root>/lib/utils.sh) emits imports_from -> <root>/scripts/lib/utils.sh (the decoy under the script dir). It is bounded by the is_file() gate and flagged INFERRED, but it is a wrong edge to a real node.

Fix direction: track top-level literal assignments plus the dirname "${BASH_SOURCE[0]}" idiom (with optional /.. suffixes) for the leading variable and use that base; keep the script-dir guess only when the variable is untracked.

Activity

  1. safishamsi commented on Jul 26, 2026

    @safishamsi
    MemberAuthor

    Fixed in v0.9.27 (#2193, thanks @Souptik96). A source "${VAR}/lib.sh" with a tracked assignment (or the dirname BASH_SOURCE idiom) resolves against the variable's real dir instead of guessing the script's own. https://github.com/Graphify-Labs/graphify/releases/tag/v0.9.27

  2. added a commit that references this issue on Jul 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions