On Fri, Feb 20, 2026 at 07:28:46PM -0800, Samuel wrote: > sha256 hash (file ends with newline): > SHA256 (pwgenerator) = > 740470dc3ea3911a19c7165d3439136ff8fb180a7f65ad31c6086a91957b77e4
(unimportant side-note): I couldn't get the code to match this checksum, which is not surprising given that you've retyped it and probably introduced or removed whitespace unintentionally. > #!/bin/ksh > > set -e Do not use 'set -e' here. Or anywhere. Not in this script nor in any other new script that you write. > trap 'error=$?; if (($error)); then print -ru2 -- "$0: line $LINENO: > $error"; fi' ERR This trap only writes to STDERR. If it's triggered early on, then there will be no output to STDOUT. Your other script will happily pass that null input to 'encrypt'. > if [ -t 1 ]; then > tput clear || exit 1 > tput cup 0 0 || exit 1 > tput el || exit 1 > fi Why have you done this in such a complicated way using tput instead of just calling 'clear'? What is the point of the final clear to end of line? In fact, what is the point of homing the cursor? All modern terminals that you are likely to be running on already home the cursor with the clear sequence. What if your system hits some kind of resource limit and cannot spawn tput here? That would be an obvious way to cause the situation you described - an empty password field being created by your other script. > LENGTH=20 > VARIATION=4 > set -A P > set -A Q Why the use of set -A here? > while :; do > for i in $(dd if=/dev/random bs=4 count=1 2>/dev/null | > hexdump -e '/1 "%u\n"') Do you think that this is guaranteed to print four decimal numbers to stdout, one per line? Bad assumption. Test this: $ echo -n '0000' | hexdump -e '/1 "%u\n"' Hexdump replaces duplicated lines with '*' by default. Any idea how your shell script interprets that '*'? Try this: $ for i in $(echo '00' | hexdump -e '/1 "%u\n"') ; do echo $i ; done ... and you'll see a directory listing. So part of your script that expects four lines each with a decimal number on each line, will instead receive any number of non-numeric entries. This even potentially _creates an exploit_, because if somebody had write access to the directory that you're running this script in, they could create files with numeric filenames and influence the generated password. Password generator runs as normal, but the output is no longer truely random. At this point, we can clearly see that this script is fundamentally broken, and I don't see any point in further analysing it. I suspect that this was either written by an LLM, or you have been studying some very ancient books about UNIX-like systems. Either way, not a good approach. My instinct tells me that something in this script triggered the error handler which passed a null input to 'encrypt', and due to the lack of error checking in your other script allowed an empty password field to be written to the password file. BUT, and this is probably the most important part - don't be discouraged from learning about shell programming or whatever you were trying to do. We learn by making mistakes. If you have any more questions feel free to ask.
