<div dir="ltr"><div>Thanks to everyone that responded - this has been very helpful.</div><div><br></div><div>So it seems that this _is_ locale-related: Hugh's explanation points out that not all two-byte strings are valid characters under UTF-8, and that would break 'tr'.  Thus the change to 'C' fixing the problem.  That really helped me understand the problem, thanks.<br></div><div><br></div><div>I want a command line solution, so GRC's website doesn't work for me.  And I don't think it's a good idea to take a password from another source: it's unlikely GRC stores generated passwords and then tries to hack the associated IP or web browser with it, but isn't it better to do this yourself so only you know the outputted password?</div><div><br></div><div>As for 'pwgen', it has precisely the same problem as 'apg' - it's not installed by default as Stewart mentioned.</div><div><br></div><div>Someone asked what these passwords used for.  We have to create accounts on many services (most of which don't support any authentication method except passwords) and give those accounts to other people to use.  It's my intent that the recipient should change the password to something more to their liking.  But many people don't: they just let their web browser memorize the password and then let us reset the password when they "forget" it by changing browsers.  At least this way I know they have a relatively random and secure password to start with, usually much better than what they would have changed it to.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 27 Sep 2018 at 15:30, William Park via talk <<a href="mailto:talk@gtalug.org" target="_blank">talk@gtalug.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If Mac has recent Bash, then you could probably use $RANDOM variable<br>
which picks a number from 0-32767 every time you read it.  From top of<br>
my head,<br>
    for i in $(seq 32); do<br>
        printf '%x' $((RANDOM % 94 + 33))<br>
    done | xxd -r -ps<br>
That will give you full 94 character range you want.<br>
-- <br>
William Park <<a href="mailto:opengeometry@yahoo.ca" target="_blank">opengeometry@yahoo.ca</a>><br>
<br>
On Wed, Sep 26, 2018 at 10:43:46AM -0400, Giles Orr via talk wrote:<br>
> I wrote a random password generator shell script, the core of which is this<br>
> one-liner:<br>
> <br>
> dd if=/dev/urandom bs=1 count=256 2>/dev/null | tr -dc<br>
> 'A-Za-z0-9!@$%^&*(){}[]=+-_/?\|~`' | head -c 32<br>
> <br>
> The very ugly string 'A-Za-z0-9!@$%^&*(){}[]=+-_/?\|~`' is the ALLOWED<br>
> values.  The two counts are replaced by variables, the first 'count='<br>
> needing to be a lot bigger than the final '-c <number>' which is the length<br>
> of the password generated.  The size difference is necessary because 'tr'<br>
> throws away a lot of values.<br>
> <br>
> I've never had a problem with this on Linux, but on a Mac under some<br>
> circumstances we get:<br>
> <br>
>     tr: Illegal byte sequence<br>
> <br>
> My coworker, who's also using the script, always got that error.  It seems<br>
> to come down to locale settings.  Mine by default are:<br>
> <br>
> $ locale<br>
> LANG="en_CA.UTF-8"<br>
> LC_COLLATE="en_CA.UTF-8"<br>
> LC_CTYPE="en_CA.UTF-8"<br>
> LC_MESSAGES="en_CA.UTF-8"<br>
> LC_MONETARY="en_CA.UTF-8"<br>
> LC_NUMERIC="en_CA.UTF-8"<br>
> LC_TIME="en_CA.UTF-8"<br>
> LC_ALL=<br>
> <br>
> My co-worker's settings are:<br>
> <br>
> LANG="en_US.UTF-8"<br>
> LC_COLLATE="en_US.UTF-8"<br>
> LC_CTYPE="en_US.UTF-8"<br>
> LC_MESSAGES="en_US.UTF-8"<br>
> LC_MONETARY="en_US.UTF-8"<br>
> LC_NUMERIC="en_US.UTF-8"<br>
> LC_TIME="en_US.UTF-8"<br>
> LC_ALL="en_US.UTF-8"<br>
> <br>
> A reliable fix (so far ...):<br>
> <br>
>     $ export LC_CTYPE=C<br>
>     $ export LC_ALL=C<br>
>     $ dd if=/dev/urandom bs=1 count=256 2>/dev/null | tr -dc<br>
> 'A-Za-z0-9!@$%^&*(){}[]=+-_/?\|~`' | head -c 32<br>
>     z%V;d9uZfWLTgsT*J]Bz`mAmA<br>
> <br>
> I'd really like to understand what the problem is, why 'tr' barfs, and what<br>
> the 'locale' settings have to do with this.  Thanks.<br>
> <br>
> (Should anyone have arguments against this as a method of password<br>
> generation, I'll entertain those too.  And yes, I'm aware of 'apg' but it's<br>
> not readily available for Mac and this is much lighter weight.)<br>
> <br>
> -- <br>
> Giles<br>
> <a href="https://www.gilesorr.com/" rel="noreferrer" target="_blank">https://www.gilesorr.com/</a><br>
> <a href="mailto:gilesorr@gmail.com" target="_blank">gilesorr@gmail.com</a><br>
<br>
> ---<br>
> Talk Mailing List<br>
> <a href="mailto:talk@gtalug.org" target="_blank">talk@gtalug.org</a><br>
> <a href="https://gtalug.org/mailman/listinfo/talk" rel="noreferrer" target="_blank">https://gtalug.org/mailman/listinfo/talk</a><br>
---<br>
Talk Mailing List<br>
<a href="mailto:talk@gtalug.org" target="_blank">talk@gtalug.org</a><br>
<a href="https://gtalug.org/mailman/listinfo/talk" rel="noreferrer" target="_blank">https://gtalug.org/mailman/listinfo/talk</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="m_1200002935970043608gmail_signature" data-smartmail="gmail_signature">Giles<br><a href="https://www.gilesorr.com/" target="_blank">https://www.gilesorr.com/</a><br><a href="mailto:gilesorr@gmail.com" target="_blank">gilesorr@gmail.com</a></div>