[GTALUG] tr: Illegal byte sequence

[Giles Orr]

Thanks to everyone that responded - this has been very helpful.

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.

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?

As for 'pwgen', it has precisely the same problem as 'apg' - it's not
installed by default as Stewart mentioned.

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.


On Thu, 27 Sep 2018 at 15:30, William Park via talk <talk at gtalug.org> wrote:

> If Mac has recent Bash, then you could probably use $RANDOM variable
> which picks a number from 0-32767 every time you read it.  From top of
> my head,
>     for i in $(seq 32); do
>         printf '%x' $((RANDOM % 94 + 33))
>     done | xxd -r -ps
> That will give you full 94 character range you want.
> --
> William Park <opengeometry at yahoo.ca>
>
> On Wed, Sep 26, 2018 at 10:43:46AM -0400, Giles Orr via talk wrote:
> > I wrote a random password generator shell script, the core of which is
> this
> > one-liner:
> >
> > dd if=/dev/urandom bs=1 count=256 2>/dev/null | tr -dc
> > 'A-Za-z0-9!@$%^&*(){}[]=+-_/?\|~`' | head -c 32
> >
> > The very ugly string 'A-Za-z0-9!@$%^&*(){}[]=+-_/?\|~`' is the ALLOWED
> > values.  The two counts are replaced by variables, the first 'count='
> > needing to be a lot bigger than the final '-c <number>' which is the
> length
> > of the password generated.  The size difference is necessary because 'tr'
> > throws away a lot of values.
> >
> > I've never had a problem with this on Linux, but on a Mac under some
> > circumstances we get:
> >
> >     tr: Illegal byte sequence
> >
> > My coworker, who's also using the script, always got that error.  It
> seems
> > to come down to locale settings.  Mine by default are:
> >
> > $ locale
> > LANG="en_CA.UTF-8"
> > LC_COLLATE="en_CA.UTF-8"
> > LC_CTYPE="en_CA.UTF-8"
> > LC_MESSAGES="en_CA.UTF-8"
> > LC_MONETARY="en_CA.UTF-8"
> > LC_NUMERIC="en_CA.UTF-8"
> > LC_TIME="en_CA.UTF-8"
> > LC_ALL=
> >
> > My co-worker's settings are:
> >
> > LANG="en_US.UTF-8"
> > LC_COLLATE="en_US.UTF-8"
> > LC_CTYPE="en_US.UTF-8"
> > LC_MESSAGES="en_US.UTF-8"
> > LC_MONETARY="en_US.UTF-8"
> > LC_NUMERIC="en_US.UTF-8"
> > LC_TIME="en_US.UTF-8"
> > LC_ALL="en_US.UTF-8"
> >
> > A reliable fix (so far ...):
> >
> >     $ export LC_CTYPE=C
> >     $ export LC_ALL=C
> >     $ dd if=/dev/urandom bs=1 count=256 2>/dev/null | tr -dc
> > 'A-Za-z0-9!@$%^&*(){}[]=+-_/?\|~`' | head -c 32
> >     z%V;d9uZfWLTgsT*J]Bz`mAmA
> >
> > I'd really like to understand what the problem is, why 'tr' barfs, and
> what
> > the 'locale' settings have to do with this.  Thanks.
> >
> > (Should anyone have arguments against this as a method of password
> > generation, I'll entertain those too.  And yes, I'm aware of 'apg' but
> it's
> > not readily available for Mac and this is much lighter weight.)
> >
> > --
> > Giles
> > https://www.gilesorr.com/
> > gilesorr at gmail.com
>
> > ---
> > Talk Mailing List
> > talk at gtalug.org
> > https://gtalug.org/mailman/listinfo/talk
> ---
> Talk Mailing List
> talk at gtalug.org
> https://gtalug.org/mailman/listinfo/talk
>


-- 
Giles
https://www.gilesorr.com/
gilesorr at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/talk/attachments/20181001/30358880/attachment.html>