You are not logged in.
==> Starting pkgver()...
==> ERROR: A failure occurred in pkgver().
Aborting...
pkgver() {
cd mesa
read -r _ver <VERSION
echo ${_ver/-/_}.$(git rev-list --count HEAD).$(git rev-parse --short HEAD)
}
The above code works fine when using on mesa main but fails on some branches
User reported that _ver=$(<VERSION) instead of read does work.
Running file on the VERSION files from main & 23.2 branche
$ file mesa/VERSION
mesa/VERSION: ASCII text
$ file mesa-23.2/VERSION
mesa-23.2/VERSION: ASCII text, with no line terminators
$
It looks like read chokes on input without a line terminator.
Two questions :
Can the read statement be adapted to accept input without a line terminator ?
Could/should makepkg give more info about the error ?
Last edited by Lone_Wolf (2023-09-15 09:01:00)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Can the read statement be adapted to accept input without a line terminator ?
Fairly sure that is a no.
Could/should makepkg give more info about the error ?
I'm not sure what more makepkg can do beyond detecting the error.
Offline
User reported that _ver=$(<VERSION) instead of read does work.
Side question: Is there a reason to use read over this?
Offline
Did you test that yourself?
printf foo > foo
file foo
bash -c "read -r FOO < foo; echo $FOO"
Online
Lone_Wolf wrote:User reported that _ver=$(<VERSION) instead of read does work.
Side question: Is there a reason to use read over this?
Read was one of the suggestions in my 2016 thread .
It has worked without issues (and still does) for mesa trunk since then.
How reliable is $(<VERSION) and does it start extra processes ?
Lone_Wolf wrote:Could/should makepkg give more info about the error ?
I'm not sure what more makepkg can do beyond detecting the error.
A linenr where things fail would help.
pkgver() {
cd mesa
local _ver
_ver=$(<VERSION)
echo ${_ver/-/_}.$(git rev-list --count HEAD).$(git rev-parse --short HEAD)
read -r _ver <VERSION
}
That variant gives exactly the same error.
@Seth
The read command doesn't crash that way, but the echo screws up the pkgver.
(VERSION content is 23.2.0-rc3 )
==> Starting pkgver()...
==> ERROR: pkgver is not allowed to contain colons, forward slashes, hyphens or whitespace.
==> ERROR: pkgver() generated an invalid version:
.174314.ad234040e51
Last edited by Lone_Wolf (2023-09-12 18:30:27)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
I don't think that Trilby is subscribed to this threa (yet ) and I don't buy that the missing newline breaks the read.
User reported that _ver=$(<VERSION) instead of read does work.
Did you test that yourself?
This smells more like the local bash got replaced by some fish (or maybe dash) - even "bash --posix" doesn't struggle to read a file w/o newline into a variable as expected here.
Online
This smells more like the local bash got replaced by some fish (or maybe dash) - even "bash --posix" doesn't struggle to read a file w/o newline into a variable as expected here.
I don't think so. I can reproduce with "bash--posix" or "sh"; `read` exists with 1 when the file does not end with a new line, but the variable still gets set (I have no idea why, I'm no bash expert)
$ echo -n 1.2.3 > VERSION
$ read -r _ver < VERSION
$ echo $?
1
$ echo $_ver
1.2.3
I guess `_ver=$(<VERSION)` or maybe 'read ... || true` should™ work?
Last edited by a821 (2023-09-12 13:03:07)
Offline
Technically if you want to ignore error returns from the read command, this would do:
read -r _ver <VERSION ||:
But that would also ignore failures resulting from bigger issues (e.g., no VERSION file).
(Also wondering, does a parrot in a hat really look that much like a semi-dog-like creature in a circle?)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Ah, I actually didn't test the return (and read --help also points out the return value)
"read -r _ver < VERSION || true" will work (assuming errexit is in place)
Edit:
read -r _ver < VERSION || [ -n "_ver" ]
Also we don't know what animal I am…
Last edited by seth (2023-09-12 13:17:25)
Online
(Seths avatar looks more like a bird then Trilbys. or possibly heat + lack of sleep caused it)
Maybe using the value of the exitcode from read to determine whether to continue or abort is a good idea ?
read -r _ver < VERSION || [ $? -le 1 ]
Last edited by Lone_Wolf (2023-09-12 18:49:13)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Lone_Wolf, what exactly is that supposed to do? If "read" returns a non-zero value, test whether that value is less than one (aka negative) and otherwise return another non-zero value? That would invert the logical value of the return value if and only if it was a negative error code, but "read" returns a postive 1 on failure - so your "or" clause changes nothing.
EDIT: oops you used -le, so when read returns exactly 1, then this would work. But that doesn't really make sense. Does "read" return 1 only for this specific error? I doubt it.
And I think the set animal is a honey badger.
Last edited by Trilby (2023-09-12 19:19:26)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
You'll get 1 if the file isn't there, it's probably better to do a plausibility check on the resulting variable.
Online
Wrong assumption by me, 1 is indeed used for more then just "no newline in file" .
[ -n "_ver" ] does look better.
Edit
User who reported the issue confirmed the code works fine now for the branch they use.
Thanks for all input, marking as solved.
Last edited by Lone_Wolf (2023-09-15 09:03:06)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline