Denys Vlasenko <[email protected]>
Steffen Nurpmeso <[email protected]>
@Steffen :
as far as algos are concerned and from what can be observed with the "tri"
script's outputs,
it works fine ... at least with args with small names (1character preferably
though :-).
So the trouble seems to rather reside in the stage where the args are
adquired and the probably
stored with some generic token stcked to them in some stack area...
BTW, i did sthg similar to circumvent the tri-problem in my own script :
[code]
# #!# 202510131 : submitted bug report to bb's mailing list
# crtLine="$(( pnHeight<crtFNum ? crtFNum-pgStart+1 : crtFNum ))"
#
# while waiting -> old way still fails ! :
# [ "$pnHeight" -lt "$crtFNum" ] \
# && crtLine=$((crtFNum-pgStart+1)) \
# || crtLine=crtFNum
# also failed!
# #!# quick dirty fix
x=$crtFnum y=$pnHeight z=$pgStart
crtLine="$(( y<x ? x-z+1 : x ))"
[/code]
As you noticed, the same problem occurs with the "[] && ||" construct! I then
resorted to "map"
the long_var_names to single letter once (there goes the semantically and
carefully selected
names down the drain!... well still collect the output in a cute one -sigh-)
So, in short, the ternary engine works but its interface with the higher
*namespace* needs a
little brush to perform correctly end-to-end.
@Denys : what, it works?!, congrats! euh... like bash... ow.. ok
the thing is with the ari-script (the execution leaking from b to c in this
"a?b:c") we do see
bash doing a good job where bb breaks. See :
((bb 1.37 and bash 4.4+))
== busybox sh ==== 1
888
<44 -2 222>
================== 2
xx
yy
888
<44 -2 555>
----------------------------------------------
== bash ========== 1
888
<44 10 333>
================== 2
xx
yy
888
<44 10 77>
----------------------------------------------
((i admit not having pushed any further like, the way i lke, adding command
expansion in the RHS of the construct :
simple and reprocutible for the report purpose))
BUT, both bb AND bash lose consistence with the tri-script also discussed
above with Steffen. See :
((same versions as above))
+ crtFnum=1
+ pnHeight=48
+ pgStart=1
+ echo '1 48 1'
1 48 1
+ echo 0
0
+ a=1
+ b=48
+ c=1
+ echo '1 48 1'
1 48 1
+ echo 1
1
+ crtFnum=1
+ b=48
+ c=1
+ echo '1 48 1'
1 48 1
+ echo 1
1
+ crtFnum=1
+ pnHeight=48
+ pgStart=1
+ echo '1 48 1'
1 48 1
+ echo 1
1
+ crtFnum=1
+ pnHeight=48
+ pgStart=1
+ echo '1 48 1'
1 48 1
+ echo 1
1
I onoly pasted one's results since they are identical... which i don't
understand.
And what puzzles me the most, again, it's not the initial error (0) but the
fact
it becomes *correct* (1) after a few script lines.
(both scripts were attached to my 1st submission)
I would greatly appreciate if you could make a static binary of the version
you mentionned
preferably within "https://busybox.net/downloads/binaries/";. This way i can
proceed with some
more tests to confirm (and selfishly use it for my own purpose of course).
allow me, here, a little rant on :
"why do i insist on "official" static builds?"
static bins are immediatly usable (off the shelves) with no dependencies,
install and often
confusing steps before being able to do anything with the targeted app.
Sadly this kills
the joy of accessing real jewels out there and rebuke most potential users.
Do i reject sources and compilation and so on? not at all but quite the
contrary, they go
hand in hand and help each other side of the usage spectrum. with the
source you can, as a user,
fine tune the compilation to your need and platform|context.... and as a
developper, in the
language of the source of the bound ones if any, add/remove/mod its
*mechanics*.
In short Statics are ready yo use, test, deploy, share with whoever without
worrying about
their CS literacy (just like live distros vs install distros... BTW i'm on
TCL 10, been years)
official (as in found in official repositories, and even signed)?
well i can see at least a couple reasons :
- the reference when discussing bugs for instance : we'll know that the
bug is not due to some
user's local particularities (HW, compile options, other libs or even
previous versions
in $PATH...).
- Another reason : trust from all users (techies or normies :-) that
know they can go and just
grab, no malicious content (as far as history follows) ... which
does't mean there won't be
bugs and other unforseen situations (like now). But we no better
(working) alternative i'd call
this the ideal deal.
So yeah, give me the baby and i'll torture it the proper way till it screams
truth (or dare?).
Meanwhile, thank you both for your kind attention and i hope to hear good
news..
sooner than later
JClu
202510142
_______________________________________________
busybox mailing list
[email protected]
https://lists.busybox.net/mailman/listinfo/busybox
