name generation error about tmpmail

[GReagle]

I think that using LC_ALL=C is faster than inserting a uuencode, but there are other aspects of efficiency.

You tested speed. It makes sense to me that adding another step in the pipeline (i.e. uuencode) would slow it down. However, making this particular line faster (by 2 milliseconds) is a micro-optimization and probably a premature optimization. This line is not in a loop in the program. I doubt that this whole program will be run in a tight loop. The time that this program spends on network communication (curl) probably dominates the CPU time anyway. There are probably some articles or blog posts about premature and micro optimization on the WWW if you want to learn more.

Another aspect of efficiency is memory use. The same ideas about micro and premature optimization apply to memory also.

Another aspect of efficiency is efficient use of programmer time and effort, so code that is more clear, more brief, more simple, and more easy to understand is better (all other things being equal).

All of these different aspects of efficiency need to be balanced against one another, with the developer deciding, based on context and the issue in question, how important they are.

[sdushantha]

@GReagle
What about this?

USERNAME=$(head /dev/urandom | LC_ALL=C tr -dc "[:alnum:]" | cut -c1-11 | tr "[:upper:]" "[:lower:]")

It's pretty much the same command as earlier, but I added LC_ALL=C before the tr command.
We could of course maybe replace cut -c1-11 with head -c 10 but other than that, I think that this command seems reasonable as it fixes the issue without having to make the line too long.

[GReagle]

This web page addresses the problem and suggests some solutions: https://unix.stackexchange.com/questions/45404/why-cant-tr-read-from-dev-urandom-on-osx.

The problem with the solution proposed of using date +%s is that on my computer it only puts out numerals, and it is not POSIX compatible. Maybe it's not random enough?

[GReagle]

I propose:

#          get 8 random bytes     | encode as text          | omit header| omit non-alphanum  | get 10 chars|change upper to lower
USERNAME=$(head -c 8 /dev/urandom | uuencode -m /dev/stdout | tail -n +2 | tr -dc "[:alnum:]" | head -c 10 | tr "[:upper:]" "[:lower:]")
 

[GReagle]

That (using LC_ALL=C tr) might fix this error with tr. I can neither confirm nor deny based on my own experience because this bug doesn't affect my system, but the web page to which I referred does seem to conclude that it works.

FYI, this command generates thousands of bytes to throw all but 10 of them. I don't think that really matters, but it does bother my OCD a little bit. Putting the binary output through uuencode uses much less data from /dev/urandom.

[sdushantha]

FYI, this command generates thousands of bytes to throw all but 10 of them. I don't think that really matters, but it does bother my OCD a little bit. Putting the binary output through uuencode uses much less data from /dev/urandom.

I do understand what you mean but, I did run both of our command 100 times and timed it to see which one is was more efficient.

Here are the results:

• your method took 0.76s
• my method took 0.52s

So from these results we can say that using LC_ALL=C might the be the best option in terms of efficiency.

What are you thoughts on this?