Catcrafts/fingerprintd
Watch
2
0
Fork
You've already forked fingerprintd
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
fingerprintd/packaging/fpenrol.sh

64 lines
2.7 KiB
Shell
Raw Normal View History

Threshold at 1.5x doubles the tap rate; add coverage-guided enrolment The threshold change is the first thing to move accuracy. Labelled protocol, enrolled quick taps: 4 of 10, against 2 of 10 for every previous build. Seven of fifteen presses now get two or more frames where none did before, and the landing frames the old threshold discarded turn up in the transcript at 207, 213, 242 and 284. Wrong finger still 0 of 5. It also explains the latency asymmetry Jorijn noticed. A match ends the loop the moment it happens, mean 1317 ms. A no-match waits for the finger to lift, mean 2190 ms, because a later frame in the same press may still match -- and they do, at frames 3, 5 and 8. That is the press rule working, not a fault. What the same run says about the template is worse than the loop ever was. One press produced eight frames at full contact, 362 to 367, and every one rejected; another produced six. Roughly one frame in seven matches, against the 47 to 75 percent the journal records for the template the research harness enrolled. The first template here was ten quick taps in about one position, so the algorithm was handed ten near-duplicate images of one spot. fpenrol.sh enrols with a different contact position per ACCEPTED sample -- centre, left, right, tip, joint, rolled either way -- driven by fprintd-enroll's own per-stage output rather than by counting presses. Enrol as a SECOND finger so both templates coexist and the comparison holds the loop constant; the trustlet reports which fid matched, and the daemon's map turns that back into a name.
2026-09-03 00:20:34 +02:00
#!/bin/sh
# fpenrol.sh -- enrol a finger with COVERAGE guidance.
#
# fpenrol.sh [finger_name] default right-middle-finger
#
# The first template on this device was enrolled from ten quick taps in
# roughly one position, and it matches roughly one frame in seven -- against
# 47-75% for the template the research harness enrolled. The algorithm was
# given ten near-duplicate images of one spot, so it recognises that spot and
Adopt stock's enrolment-quality config: 20 samples, and thresholds that refuse a bad one Jorijn asked whether the sample count is ours to control and whether more samples would help. It is -- and the config dump says something more useful. Stock enrols with 20 samples, not the 10 we had guessed, but it also sets six keys we were leaving entirely to the trustlet's built-in defaults: min_enrolling_coverage_threshold 70 min_enrolling_quality_threshold 20 enroll_overlap_min_area 60 enroll_overlap_max_area 80 enable_duplicated_finger_checking on max_extral_enroll_low_quality 16 Those defaults accept anything, which is how ten quick taps in one position became a stored template. The overlap bounds are the mechanism that matters: a sample must overlap the previous one by 60 to 80 percent -- more means the finger did not move, less means a gap -- so the algorithm now refuses the same-spot sample instead of storing it. Sample count alone would have stored twenty near-duplicates rather than ten. Deliberately left out: min_identify_quality_threshold and min_identify_coverage_threshold. Those gate matching rather than enrolment and would reject exactly the landing frames the 1.5x detection threshold exists to catch. One group of variables at a time. fpenrol.sh grows to twenty positions, and its rejection message now says to move rather than to press harder, because the enforcement and the guidance finally agree on what a rejected sample means.
2026-09-03 00:26:14 +02:00
# little else. It accepted them because our config set none of stock's
# enrolment-quality keys and the trustlet's own defaults accept anything;
# those keys are now set, so the algorithm enforces the spread too.
Threshold at 1.5x doubles the tap rate; add coverage-guided enrolment The threshold change is the first thing to move accuracy. Labelled protocol, enrolled quick taps: 4 of 10, against 2 of 10 for every previous build. Seven of fifteen presses now get two or more frames where none did before, and the landing frames the old threshold discarded turn up in the transcript at 207, 213, 242 and 284. Wrong finger still 0 of 5. It also explains the latency asymmetry Jorijn noticed. A match ends the loop the moment it happens, mean 1317 ms. A no-match waits for the finger to lift, mean 2190 ms, because a later frame in the same press may still match -- and they do, at frames 3, 5 and 8. That is the press rule working, not a fault. What the same run says about the template is worse than the loop ever was. One press produced eight frames at full contact, 362 to 367, and every one rejected; another produced six. Roughly one frame in seven matches, against the 47 to 75 percent the journal records for the template the research harness enrolled. The first template here was ten quick taps in about one position, so the algorithm was handed ten near-duplicate images of one spot. fpenrol.sh enrols with a different contact position per ACCEPTED sample -- centre, left, right, tip, joint, rolled either way -- driven by fprintd-enroll's own per-stage output rather than by counting presses. Enrol as a SECOND finger so both templates coexist and the comparison holds the loop constant; the trustlet reports which fid matched, and the daemon's map turns that back into a name.
2026-09-03 00:20:34 +02:00
#
# This walks a different contact position per accepted sample. It reads
# fprintd-enroll's per-stage output and prompts the next position as each
# stage passes, so the guidance tracks what the trustlet ACCEPTED rather than
# how many times you pressed.
F=${1:-right-middle-finger}
i=1
Adopt stock's enrolment-quality config: 20 samples, and thresholds that refuse a bad one Jorijn asked whether the sample count is ours to control and whether more samples would help. It is -- and the config dump says something more useful. Stock enrols with 20 samples, not the 10 we had guessed, but it also sets six keys we were leaving entirely to the trustlet's built-in defaults: min_enrolling_coverage_threshold 70 min_enrolling_quality_threshold 20 enroll_overlap_min_area 60 enroll_overlap_max_area 80 enable_duplicated_finger_checking on max_extral_enroll_low_quality 16 Those defaults accept anything, which is how ten quick taps in one position became a stored template. The overlap bounds are the mechanism that matters: a sample must overlap the previous one by 60 to 80 percent -- more means the finger did not move, less means a gap -- so the algorithm now refuses the same-spot sample instead of storing it. Sample count alone would have stored twenty near-duplicates rather than ten. Deliberately left out: min_identify_quality_threshold and min_identify_coverage_threshold. Those gate matching rather than enrolment and would reject exactly the landing frames the 1.5x detection threshold exists to catch. One group of variables at a time. fpenrol.sh grows to twenty positions, and its rejection message now says to move rather than to press harder, because the enforcement and the guidance finally agree on what a rejected sample means.
2026-09-03 00:26:14 +02:00
# Twenty positions, stock's sample count. The config now enforces stock's
# coverage and overlap thresholds, so a sample that does not move enough from
# the last one is REFUSED by the algorithm rather than stored -- the guidance
# and the enforcement finally agree.
Threshold at 1.5x doubles the tap rate; add coverage-guided enrolment The threshold change is the first thing to move accuracy. Labelled protocol, enrolled quick taps: 4 of 10, against 2 of 10 for every previous build. Seven of fifteen presses now get two or more frames where none did before, and the landing frames the old threshold discarded turn up in the transcript at 207, 213, 242 and 284. Wrong finger still 0 of 5. It also explains the latency asymmetry Jorijn noticed. A match ends the loop the moment it happens, mean 1317 ms. A no-match waits for the finger to lift, mean 2190 ms, because a later frame in the same press may still match -- and they do, at frames 3, 5 and 8. That is the press rule working, not a fault. What the same run says about the template is worse than the loop ever was. One press produced eight frames at full contact, 362 to 367, and every one rejected; another produced six. Roughly one frame in seven matches, against the 47 to 75 percent the journal records for the template the research harness enrolled. The first template here was ten quick taps in about one position, so the algorithm was handed ten near-duplicate images of one spot. fpenrol.sh enrols with a different contact position per ACCEPTED sample -- centre, left, right, tip, joint, rolled either way -- driven by fprintd-enroll's own per-stage output rather than by counting presses. Enrol as a SECOND finger so both templates coexist and the comparison holds the loop constant; the trustlet reports which fid matched, and the daemon's map turns that back into a name.
2026-09-03 00:20:34 +02:00
set -- "centre of the pad" \
"slightly LEFT of centre" \
"slightly RIGHT of centre" \
"higher up, toward the TIP" \
"lower down, toward the JOINT" \
Adopt stock's enrolment-quality config: 20 samples, and thresholds that refuse a bad one Jorijn asked whether the sample count is ours to control and whether more samples would help. It is -- and the config dump says something more useful. Stock enrols with 20 samples, not the 10 we had guessed, but it also sets six keys we were leaving entirely to the trustlet's built-in defaults: min_enrolling_coverage_threshold 70 min_enrolling_quality_threshold 20 enroll_overlap_min_area 60 enroll_overlap_max_area 80 enable_duplicated_finger_checking on max_extral_enroll_low_quality 16 Those defaults accept anything, which is how ten quick taps in one position became a stored template. The overlap bounds are the mechanism that matters: a sample must overlap the previous one by 60 to 80 percent -- more means the finger did not move, less means a gap -- so the algorithm now refuses the same-spot sample instead of storing it. Sample count alone would have stored twenty near-duplicates rather than ten. Deliberately left out: min_identify_quality_threshold and min_identify_coverage_threshold. Those gate matching rather than enrolment and would reject exactly the landing frames the 1.5x detection threshold exists to catch. One group of variables at a time. fpenrol.sh grows to twenty positions, and its rejection message now says to move rather than to press harder, because the enforcement and the guidance finally agree on what a rejected sample means.
2026-09-03 00:26:14 +02:00
"centre, rolled LEFT" \
"centre, rolled RIGHT" \
Threshold at 1.5x doubles the tap rate; add coverage-guided enrolment The threshold change is the first thing to move accuracy. Labelled protocol, enrolled quick taps: 4 of 10, against 2 of 10 for every previous build. Seven of fifteen presses now get two or more frames where none did before, and the landing frames the old threshold discarded turn up in the transcript at 207, 213, 242 and 284. Wrong finger still 0 of 5. It also explains the latency asymmetry Jorijn noticed. A match ends the loop the moment it happens, mean 1317 ms. A no-match waits for the finger to lift, mean 2190 ms, because a later frame in the same press may still match -- and they do, at frames 3, 5 and 8. That is the press rule working, not a fault. What the same run says about the template is worse than the loop ever was. One press produced eight frames at full contact, 362 to 367, and every one rejected; another produced six. Roughly one frame in seven matches, against the 47 to 75 percent the journal records for the template the research harness enrolled. The first template here was ten quick taps in about one position, so the algorithm was handed ten near-duplicate images of one spot. fpenrol.sh enrols with a different contact position per ACCEPTED sample -- centre, left, right, tip, joint, rolled either way -- driven by fprintd-enroll's own per-stage output rather than by counting presses. Enrol as a SECOND finger so both templates coexist and the comparison holds the loop constant; the trustlet reports which fid matched, and the daemon's map turns that back into a name.
2026-09-03 00:20:34 +02:00
"tip, rolled slightly left" \
"joint, rolled slightly right" \
Adopt stock's enrolment-quality config: 20 samples, and thresholds that refuse a bad one Jorijn asked whether the sample count is ours to control and whether more samples would help. It is -- and the config dump says something more useful. Stock enrols with 20 samples, not the 10 we had guessed, but it also sets six keys we were leaving entirely to the trustlet's built-in defaults: min_enrolling_coverage_threshold 70 min_enrolling_quality_threshold 20 enroll_overlap_min_area 60 enroll_overlap_max_area 80 enable_duplicated_finger_checking on max_extral_enroll_low_quality 16 Those defaults accept anything, which is how ten quick taps in one position became a stored template. The overlap bounds are the mechanism that matters: a sample must overlap the previous one by 60 to 80 percent -- more means the finger did not move, less means a gap -- so the algorithm now refuses the same-spot sample instead of storing it. Sample count alone would have stored twenty near-duplicates rather than ten. Deliberately left out: min_identify_quality_threshold and min_identify_coverage_threshold. Those gate matching rather than enrolment and would reject exactly the landing frames the 1.5x detection threshold exists to catch. One group of variables at a time. fpenrol.sh grows to twenty positions, and its rejection message now says to move rather than to press harder, because the enforcement and the guidance finally agree on what a rejected sample means.
2026-09-03 00:26:14 +02:00
"centre, a little firmer" \
"far LEFT edge of the pad" \
"far RIGHT edge of the pad" \
"very tip of the finger" \
"well down toward the joint" \
"upper left of the pad" \
"upper right of the pad" \
"lower left of the pad" \
"lower right of the pad" \
"centre, rolled hard left" \
"centre, rolled hard right"
echo "enrolling $F with position guidance -- 20 samples (stock's count)"
Threshold at 1.5x doubles the tap rate; add coverage-guided enrolment The threshold change is the first thing to move accuracy. Labelled protocol, enrolled quick taps: 4 of 10, against 2 of 10 for every previous build. Seven of fifteen presses now get two or more frames where none did before, and the landing frames the old threshold discarded turn up in the transcript at 207, 213, 242 and 284. Wrong finger still 0 of 5. It also explains the latency asymmetry Jorijn noticed. A match ends the loop the moment it happens, mean 1317 ms. A no-match waits for the finger to lift, mean 2190 ms, because a later frame in the same press may still match -- and they do, at frames 3, 5 and 8. That is the press rule working, not a fault. What the same run says about the template is worse than the loop ever was. One press produced eight frames at full contact, 362 to 367, and every one rejected; another produced six. Roughly one frame in seven matches, against the 47 to 75 percent the journal records for the template the research harness enrolled. The first template here was ten quick taps in about one position, so the algorithm was handed ten near-duplicate images of one spot. fpenrol.sh enrols with a different contact position per ACCEPTED sample -- centre, left, right, tip, joint, rolled either way -- driven by fprintd-enroll's own per-stage output rather than by counting presses. Enrol as a SECOND finger so both templates coexist and the comparison holds the loop constant; the trustlet reports which fid matched, and the daemon's map turns that back into a name.
2026-09-03 00:20:34 +02:00
echo "press FLAT and firm, hold about a second, then LIFT fully."
echo
# The reader runs in a subshell, so `shift` there cannot advance the caller's
# list. Index into it instead.
pos() { eval "printf '%s' \"\$$1\""; }
Adopt stock's enrolment-quality config: 20 samples, and thresholds that refuse a bad one Jorijn asked whether the sample count is ours to control and whether more samples would help. It is -- and the config dump says something more useful. Stock enrols with 20 samples, not the 10 we had guessed, but it also sets six keys we were leaving entirely to the trustlet's built-in defaults: min_enrolling_coverage_threshold 70 min_enrolling_quality_threshold 20 enroll_overlap_min_area 60 enroll_overlap_max_area 80 enable_duplicated_finger_checking on max_extral_enroll_low_quality 16 Those defaults accept anything, which is how ten quick taps in one position became a stored template. The overlap bounds are the mechanism that matters: a sample must overlap the previous one by 60 to 80 percent -- more means the finger did not move, less means a gap -- so the algorithm now refuses the same-spot sample instead of storing it. Sample count alone would have stored twenty near-duplicates rather than ten. Deliberately left out: min_identify_quality_threshold and min_identify_coverage_threshold. Those gate matching rather than enrolment and would reject exactly the landing frames the 1.5x detection threshold exists to catch. One group of variables at a time. fpenrol.sh grows to twenty positions, and its rejection message now says to move rather than to press harder, because the enforcement and the guidance finally agree on what a rejected sample means.
2026-09-03 00:26:14 +02:00
echo ">>> sample 1/20: $(pos 1)"
Threshold at 1.5x doubles the tap rate; add coverage-guided enrolment The threshold change is the first thing to move accuracy. Labelled protocol, enrolled quick taps: 4 of 10, against 2 of 10 for every previous build. Seven of fifteen presses now get two or more frames where none did before, and the landing frames the old threshold discarded turn up in the transcript at 207, 213, 242 and 284. Wrong finger still 0 of 5. It also explains the latency asymmetry Jorijn noticed. A match ends the loop the moment it happens, mean 1317 ms. A no-match waits for the finger to lift, mean 2190 ms, because a later frame in the same press may still match -- and they do, at frames 3, 5 and 8. That is the press rule working, not a fault. What the same run says about the template is worse than the loop ever was. One press produced eight frames at full contact, 362 to 367, and every one rejected; another produced six. Roughly one frame in seven matches, against the 47 to 75 percent the journal records for the template the research harness enrolled. The first template here was ten quick taps in about one position, so the algorithm was handed ten near-duplicate images of one spot. fpenrol.sh enrols with a different contact position per ACCEPTED sample -- centre, left, right, tip, joint, rolled either way -- driven by fprintd-enroll's own per-stage output rather than by counting presses. Enrol as a SECOND finger so both templates coexist and the comparison holds the loop constant; the trustlet reports which fid matched, and the daemon's map turns that back into a name.
2026-09-03 00:20:34 +02:00
fprintd-enroll -f "$F" user 2>&1 | while IFS= read -r line; do
case "$line" in
*enroll-stage-passed*)
i=$((i+1))
Adopt stock's enrolment-quality config: 20 samples, and thresholds that refuse a bad one Jorijn asked whether the sample count is ours to control and whether more samples would help. It is -- and the config dump says something more useful. Stock enrols with 20 samples, not the 10 we had guessed, but it also sets six keys we were leaving entirely to the trustlet's built-in defaults: min_enrolling_coverage_threshold 70 min_enrolling_quality_threshold 20 enroll_overlap_min_area 60 enroll_overlap_max_area 80 enable_duplicated_finger_checking on max_extral_enroll_low_quality 16 Those defaults accept anything, which is how ten quick taps in one position became a stored template. The overlap bounds are the mechanism that matters: a sample must overlap the previous one by 60 to 80 percent -- more means the finger did not move, less means a gap -- so the algorithm now refuses the same-spot sample instead of storing it. Sample count alone would have stored twenty near-duplicates rather than ten. Deliberately left out: min_identify_quality_threshold and min_identify_coverage_threshold. Those gate matching rather than enrolment and would reject exactly the landing frames the 1.5x detection threshold exists to catch. One group of variables at a time. fpenrol.sh grows to twenty positions, and its rejection message now says to move rather than to press harder, because the enforcement and the guidance finally agree on what a rejected sample means.
2026-09-03 00:26:14 +02:00
if [ "$i" -le 20 ]; then
Threshold at 1.5x doubles the tap rate; add coverage-guided enrolment The threshold change is the first thing to move accuracy. Labelled protocol, enrolled quick taps: 4 of 10, against 2 of 10 for every previous build. Seven of fifteen presses now get two or more frames where none did before, and the landing frames the old threshold discarded turn up in the transcript at 207, 213, 242 and 284. Wrong finger still 0 of 5. It also explains the latency asymmetry Jorijn noticed. A match ends the loop the moment it happens, mean 1317 ms. A no-match waits for the finger to lift, mean 2190 ms, because a later frame in the same press may still match -- and they do, at frames 3, 5 and 8. That is the press rule working, not a fault. What the same run says about the template is worse than the loop ever was. One press produced eight frames at full contact, 362 to 367, and every one rejected; another produced six. Roughly one frame in seven matches, against the 47 to 75 percent the journal records for the template the research harness enrolled. The first template here was ten quick taps in about one position, so the algorithm was handed ten near-duplicate images of one spot. fpenrol.sh enrols with a different contact position per ACCEPTED sample -- centre, left, right, tip, joint, rolled either way -- driven by fprintd-enroll's own per-stage output rather than by counting presses. Enrol as a SECOND finger so both templates coexist and the comparison holds the loop constant; the trustlet reports which fid matched, and the daemon's map turns that back into a name.
2026-09-03 00:20:34 +02:00
echo " accepted."
Adopt stock's enrolment-quality config: 20 samples, and thresholds that refuse a bad one Jorijn asked whether the sample count is ours to control and whether more samples would help. It is -- and the config dump says something more useful. Stock enrols with 20 samples, not the 10 we had guessed, but it also sets six keys we were leaving entirely to the trustlet's built-in defaults: min_enrolling_coverage_threshold 70 min_enrolling_quality_threshold 20 enroll_overlap_min_area 60 enroll_overlap_max_area 80 enable_duplicated_finger_checking on max_extral_enroll_low_quality 16 Those defaults accept anything, which is how ten quick taps in one position became a stored template. The overlap bounds are the mechanism that matters: a sample must overlap the previous one by 60 to 80 percent -- more means the finger did not move, less means a gap -- so the algorithm now refuses the same-spot sample instead of storing it. Sample count alone would have stored twenty near-duplicates rather than ten. Deliberately left out: min_identify_quality_threshold and min_identify_coverage_threshold. Those gate matching rather than enrolment and would reject exactly the landing frames the 1.5x detection threshold exists to catch. One group of variables at a time. fpenrol.sh grows to twenty positions, and its rejection message now says to move rather than to press harder, because the enforcement and the guidance finally agree on what a rejected sample means.
2026-09-03 00:26:14 +02:00
echo ">>> sample $i/20: $(pos $i)"
Threshold at 1.5x doubles the tap rate; add coverage-guided enrolment The threshold change is the first thing to move accuracy. Labelled protocol, enrolled quick taps: 4 of 10, against 2 of 10 for every previous build. Seven of fifteen presses now get two or more frames where none did before, and the landing frames the old threshold discarded turn up in the transcript at 207, 213, 242 and 284. Wrong finger still 0 of 5. It also explains the latency asymmetry Jorijn noticed. A match ends the loop the moment it happens, mean 1317 ms. A no-match waits for the finger to lift, mean 2190 ms, because a later frame in the same press may still match -- and they do, at frames 3, 5 and 8. That is the press rule working, not a fault. What the same run says about the template is worse than the loop ever was. One press produced eight frames at full contact, 362 to 367, and every one rejected; another produced six. Roughly one frame in seven matches, against the 47 to 75 percent the journal records for the template the research harness enrolled. The first template here was ten quick taps in about one position, so the algorithm was handed ten near-duplicate images of one spot. fpenrol.sh enrols with a different contact position per ACCEPTED sample -- centre, left, right, tip, joint, rolled either way -- driven by fprintd-enroll's own per-stage output rather than by counting presses. Enrol as a SECOND finger so both templates coexist and the comparison holds the loop constant; the trustlet reports which fid matched, and the daemon's map turns that back into a name.
2026-09-03 00:20:34 +02:00
fi ;;
Adopt stock's enrolment-quality config: 20 samples, and thresholds that refuse a bad one Jorijn asked whether the sample count is ours to control and whether more samples would help. It is -- and the config dump says something more useful. Stock enrols with 20 samples, not the 10 we had guessed, but it also sets six keys we were leaving entirely to the trustlet's built-in defaults: min_enrolling_coverage_threshold 70 min_enrolling_quality_threshold 20 enroll_overlap_min_area 60 enroll_overlap_max_area 80 enable_duplicated_finger_checking on max_extral_enroll_low_quality 16 Those defaults accept anything, which is how ten quick taps in one position became a stored template. The overlap bounds are the mechanism that matters: a sample must overlap the previous one by 60 to 80 percent -- more means the finger did not move, less means a gap -- so the algorithm now refuses the same-spot sample instead of storing it. Sample count alone would have stored twenty near-duplicates rather than ten. Deliberately left out: min_identify_quality_threshold and min_identify_coverage_threshold. Those gate matching rather than enrolment and would reject exactly the landing frames the 1.5x detection threshold exists to catch. One group of variables at a time. fpenrol.sh grows to twenty positions, and its rejection message now says to move rather than to press harder, because the enforcement and the guidance finally agree on what a rejected sample means.
2026-09-03 00:26:14 +02:00
*enroll-retry-scan*) echo " REFUSED -- move further from the last position, or press flatter" ;;
Threshold at 1.5x doubles the tap rate; add coverage-guided enrolment The threshold change is the first thing to move accuracy. Labelled protocol, enrolled quick taps: 4 of 10, against 2 of 10 for every previous build. Seven of fifteen presses now get two or more frames where none did before, and the landing frames the old threshold discarded turn up in the transcript at 207, 213, 242 and 284. Wrong finger still 0 of 5. It also explains the latency asymmetry Jorijn noticed. A match ends the loop the moment it happens, mean 1317 ms. A no-match waits for the finger to lift, mean 2190 ms, because a later frame in the same press may still match -- and they do, at frames 3, 5 and 8. That is the press rule working, not a fault. What the same run says about the template is worse than the loop ever was. One press produced eight frames at full contact, 362 to 367, and every one rejected; another produced six. Roughly one frame in seven matches, against the 47 to 75 percent the journal records for the template the research harness enrolled. The first template here was ten quick taps in about one position, so the algorithm was handed ten near-duplicate images of one spot. fpenrol.sh enrols with a different contact position per ACCEPTED sample -- centre, left, right, tip, joint, rolled either way -- driven by fprintd-enroll's own per-stage output rather than by counting presses. Enrol as a SECOND finger so both templates coexist and the comparison holds the loop constant; the trustlet reports which fid matched, and the daemon's map turns that back into a name.
2026-09-03 00:20:34 +02:00
*enroll-completed*) echo; echo "COMPLETED." ;;
*enroll-failed*) echo; echo "FAILED." ;;
*) printf '%s\n' "$line" ;;
esac
done
Reference in a new issue Copy permalink