On 9/19/25 12:47, Alyssa Ross wrote: > Demi Marie Obenour writes: > >> Use builtin string manipulation instead. >> >> Signed-off-by: Demi Marie Obenour >> --- >> scripts/make-erofs.sh | 14 +++++++++++++- >> 1 file changed, 13 insertions(+), 1 deletion(-) >> >> diff --git a/scripts/make-erofs.sh b/scripts/make-erofs.sh >> index cf942972910c76e1835dc5b0084c2d04bf084a9d..93cb3245f409b24c24be05e9307a1b2e12c867fe 100755 >> --- a/scripts/make-erofs.sh >> +++ b/scripts/make-erofs.sh >> @@ -78,7 +78,19 @@ while read -r arg1; do >> >> check_path "$arg1" "$arg2" >> >> - parent=$(dirname "$arg2") >> + # The below simple version of dirname(1) can only handle >> + # a subset of all paths, but this subset includes all of >> + # the paths that check_path doesn't reject. > > Are any of the paths it would mishandle paths that would actually be > likely to show up? I feel like we don't really need to worry about > people putting silly things in the Makefile, especially since that's > going to be generated going forward, and in the case of Nix store paths > we know those will always be the store directory, a slash, and then a > single component. I don't really want to be overly defensive, > especially since we're not in other places in the build system — as a > consequence of using make, which doesn't handle spaces well, for > example. I'll drop the validation in the future. Nix store paths and the generated makefile paths should both be correct by construction. -- Sincerely, Demi Marie Obenour (she/her/hers)