From: Alyssa Ross <hi@alyssa.is>
To: Demi Marie Obenour <demiobenour@gmail.com>
Cc: Spectrum OS Development <devel@spectrum-os.org>
Subject: Re: [PATCH v3] Generate file lists from a script
Date: Sun, 21 Sep 2025 19:07:04 +0200 [thread overview]
Message-ID: <87h5wv20qv.fsf@alyssa.is> (raw)
In-Reply-To: <e8a7ce72-7f2a-480a-b6ee-55dcc5e31bac@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5633 bytes --]
Demi Marie Obenour <demiobenour@gmail.com> writes:
>>> diff --git a/scripts/genfiles.awk b/scripts/genfiles.awk
>>> new file mode 100644
>>> index 0000000000000000000000000000000000000000..6fe327fd0a314d226dbce23854aa8f119e9c8f34
>>> --- /dev/null
>>> +++ b/scripts/genfiles.awk
>>> @@ -0,0 +1,120 @@
>>> +#!/usr/bin/env -S LC_ALL=C LANGUAGE=C awk -E
>>> +# SPDX-License-Identifier: EUPL-1.2+
>>> +# SPDX-FileCopyrightText: 2025 Demi Marie Obenour <demiobenour@gmail.com>
>>> +BEGIN {
>>> + RS = "\n";
>>> + FS = "\t";
>>> + file_count = 0;
>>> + symlink_count = 0;
>>> + rc_count = 0;
>>> + is_rc = 0;
>>> + exit_code = 0;
>>> + done = 0;
>>
>> awk variables are implicitly initialized to 0 when you try to do
>> arithmetic on an undefined variable, so no need for these.
>
> GNU Awk can lint against that. I used its lint mode because it also
> warns against non-portable constructs. Also, an undefined awk
> variable used as an array subscript is treated as the empty string,
> not 0, which could lead to confusion.
Okay, happy to leave them if you want.
>>> +
>>> +filename ~ /^image\/etc\/s6-rc\// {
>>> + if (mode != "regular") {
>>> + fail("s6-rc-compile input '" filename "' isn't a regular file");
>>> + }
>>> + rc_count += 1;
>>> + rc_files[rc_count] = filename;
>>
>> rc_files[rc_count++]
>>
>> (will make it 0-indexed though so update the loops too)
>
> I think this might break without explicit variable initialization.
It does not.
>>> + "# Generated by scripts/genfile.sh. Any changes will be overwritten.\n" \
>>> + "FILES ::=") > out_file;
>>
>> I note the change to ::=. Do you think we should do that across the
>> board in our Makefiles?
>
> POSIX specifies ::= and it has better semantics in most cases, but I don't
> know if the BSD makes implement it. ::= causes the RHS to be expanded immediately,
> so subsequent changes in variables referenced by it do not affect the LHS.
Happy to change, but would prefer we did it all at once.
>>> + for (array_index = 1; array_index <= file_count; array_index += 1) {
>>> + printf " \\\n\t%s", files[array_index] > out_file;
>>> + }
>>> + printf ("\n\n" \
>>> +"# These are separate because they need to be included, but putting\n" \
>>> +"# them as make dependencies would confuse make.\n" \
>>> +"LINKS ::=") > out_file;
>>> + for (array_index = 1; array_index <= symlink_count; array_index += 1) {
>>> + printf " \\\n\t%s", symlinks[array_index] > out_file;
>>> + }
>>> + printf "\n\nS6_RC_FILES ::=" > out_file;
>>> + for (array_index = 1; array_index <= rc_count; array_index += 1) {
>>> + printf " \\\n\t%s", rc_files[array_index] > out_file;
>>> + }
>>> + printf "\n" > out_file;
>>> + if (close(out_file)) {
>>> + print ("Cannot close output file: " ERRNO "\n") > "/dev/stderr";
>>> + exit 1;
>>> + }
>>> +}
>>> diff --git a/scripts/genfiles.sh b/scripts/genfiles.sh
>>> new file mode 100755
>>> index 0000000000000000000000000000000000000000..77a8d95e88b6851be9447698556efe4f1eab174b
>>> --- /dev/null
>>> +++ b/scripts/genfiles.sh
>>> @@ -0,0 +1,29 @@
>>> +#!/usr/bin/env -S LC_ALL=C LANGUAGE=C bash --
>>
>> env -S is not portable, and I don't think anything here needs bash
>> specifically.
>
> $'\t' doesn't work with all shells, though I believe it is either
> part of the current POSIX standard or will be added. I'll use
> /usr/bin/env bash, which breaks if the script is renamed to something
> starting with '-'.
It's in 2024. I'd prefer this was /bin/sh like our other scripts — we
already have shellcheck checking for non-portable constructs.
>>> +case $0 in
>>> +(/*) cd "${0%/*}/..";;
>>> +(*/*) cd "./${0%/*}/..";;
>>> +(*) cd ..;;
>>> +esac
>>
>> Perhaps we could use git rev-parse --show-toplevel?
>
> git ls-files doesn't have that option.
I mean we could cd "$(git rev-parse --show-toplevel)", and then be in a
consistent starting place.
>>> +for i in host/rootfs img/app vm/sys/net; do
>>> + output_file=$i/file-list.mk
>>> + {
>>> + git -C "$i" -c core.quotePath=true ls-files $'--format=%(objectmode)\t%(path)' -- image |
>>> + sort -t $'\t' -k 2
>>
>> TIL sort -t and -k! 🤯
>>
>>> + echo DONE
>>
>> Why do we need this?
>
> To avoid producing any output file if the input is truncated.
>
>>> + } |
>>> + gawk -v "out_file=$output_file.tmp" -E scripts/genfiles.awk
>>
>> Why not stdout?
>
> The output file is created by awk so that it is only created if
> nothing went wrong.
For both of these, we already have exit status to communicate if
something goes wrong. When would output get truncated without that
being an unsuccessful exit?
>>> + if [ -f "$output_file" ]; then
>>> + # Avoid changing output file if it is up to date, as that
>>> + # would cause unnecessary rebuilds.
>>> + if cmp -s -- "$output_file.tmp" "$output_file"; then
>>> + rm -- "$output_file.tmp"
>>> + continue
>>> + else
>>> + astatus=$?
>>> + if [ "$astatus" != 1 ]; then exit "$astatus"; fi
>>
>> Could avoid the need for the variable and multiple ifs. Up to you
>> whether you prefer it:
>>
>> set +e
>> cmp -s -- "$output_file.tmp" "$output_file"
>> set -e
>> case $? in
>> 0)
>> rm -- "$output_file.tmp"
>> continue
>> ;;
>> 1)
>> ;;
>> *)
>> exit $?
>> ;;
>> esac
>
> This might set $? to the return value of 'set -e' (0). Whether or
> not it actually does is at least not obvious from reading the code.
Oh good point. Let's stick with your way then.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
next prev parent reply other threads:[~2025-09-21 17:07 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-04 1:56 [PATCH 0/4] Generate file lists from a script Demi Marie Obenour
2025-09-04 1:56 ` [PATCH 1/4] Move all files for the image into a subdirectory Demi Marie Obenour
2025-09-04 1:56 ` [PATCH 2/4] Generate makefile file lists from a script Demi Marie Obenour
2025-09-08 9:59 ` Alyssa Ross
2025-09-08 18:45 ` Demi Marie Obenour
2025-09-09 14:51 ` Alyssa Ross
2025-09-04 1:56 ` [PATCH 3/4] Common make rules for building erofs images Demi Marie Obenour
2025-09-08 10:01 ` Alyssa Ross
2025-09-08 18:53 ` Demi Marie Obenour
2025-09-09 14:56 ` Alyssa Ross
2025-09-04 1:56 ` [PATCH 4/4] Use /etc/s6-rc/compiled for compiled s6-rc directory Demi Marie Obenour
2025-09-10 5:29 ` [PATCH v2 0/3] Generate file lists from a script Demi Marie Obenour
2025-09-10 5:29 ` [PATCH v2 1/3] Move all files for the image into a subdirectory Demi Marie Obenour
2025-09-10 18:58 ` Alyssa Ross
2025-09-11 12:21 ` Demi Marie Obenour
2025-09-10 5:29 ` [PATCH v2 2/3] Generate makefile file lists from a script Demi Marie Obenour
2025-09-10 5:29 ` [PATCH v2 3/3] Common make rules for building erofs images Demi Marie Obenour
2025-09-11 12:47 ` [PATCH v3 0/4] Generate file lists from a script Demi Marie Obenour
2025-09-11 12:47 ` [PATCH v3 1/4] Do not ignore errors from tar Demi Marie Obenour
2025-09-17 11:48 ` Alyssa Ross
2025-09-18 2:45 ` Demi Marie Obenour
2025-09-19 7:46 ` Alyssa Ross
2025-09-30 12:59 ` Alyssa Ross
2025-09-19 7:55 ` Alyssa Ross
2025-09-19 19:03 ` Demi Marie Obenour
2025-09-11 12:47 ` [PATCH v3 2/4] Move all files for the image into a subdirectory Demi Marie Obenour
2025-09-17 12:30 ` Alyssa Ross
2025-09-17 12:39 ` Alyssa Ross
2025-09-17 13:03 ` Alyssa Ross
2025-09-11 12:47 ` [PATCH v3 3/4] Generate makefile file lists from a script Demi Marie Obenour
2025-09-11 12:47 ` [PATCH v3 4/4] Common make rules for building erofs images Demi Marie Obenour
2025-09-21 2:23 ` [PATCH v3] Generate file lists from a script Demi Marie Obenour
2025-09-21 8:47 ` Alyssa Ross
2025-09-21 16:51 ` Demi Marie Obenour
2025-09-21 17:07 ` Alyssa Ross [this message]
2025-09-21 17:24 ` [PATCH v4] " Demi Marie Obenour
2025-09-25 11:22 ` Alyssa Ross
2025-09-26 16:31 ` [PATCH v5] " Demi Marie Obenour
2025-09-27 8:19 ` Alyssa Ross
2025-09-27 8:42 ` Demi Marie Obenour
2025-09-27 16:22 ` [PATCH v6] " Demi Marie Obenour
2025-09-29 8:12 ` Alyssa Ross
2025-09-29 17:20 ` Demi Marie Obenour
2025-09-29 17:18 ` [PATCH v7] " Demi Marie Obenour
2025-10-01 9:20 ` Alyssa Ross
2025-10-01 9:24 ` Demi Marie Obenour
2025-10-01 9:35 ` Alyssa Ross
2025-10-01 18:30 ` [PATCH v8] " Demi Marie Obenour
2025-10-02 9:46 ` Alyssa Ross
2025-10-02 17:37 ` [PATCH v9] " Demi Marie Obenour
2025-10-03 9:04 ` Alyssa Ross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h5wv20qv.fsf@alyssa.is \
--to=hi@alyssa.is \
--cc=demiobenour@gmail.com \
--cc=devel@spectrum-os.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://spectrum-os.org/git/crosvm
https://spectrum-os.org/git/doc
https://spectrum-os.org/git/mktuntap
https://spectrum-os.org/git/nixpkgs
https://spectrum-os.org/git/spectrum
https://spectrum-os.org/git/ucspi-vsock
https://spectrum-os.org/git/www
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).