Hi,
I found HERE some useful tip on generating a password using egrep and /dev/urandom. However, I don’t know about the “1” flag in “-ioam1”:
egrep -ioam1 '[a-z0-9]{8}' /dev/urandom
I looked over the Internet, maybe I didn’t look where I had to. I found what “ioam” flags stand for, but there wasn’t anything about the “1” flag.
It’s the number argument to the ‘-m’ which is in the manpage.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
Thanks, ab. I checked the man of egrep again :
-m NUM, --max-count=NUM
Stop reading a file after NUM matching lines. If the input is standard input from a regular file, and NUM
matching lines are output, grep ensures that the standard input is positioned to just after the last
matching line before exiting, regardless of the presence of trailing context lines. This enables a calling
process to resume a search. When grep stops after NUM matching lines, it outputs any trailing context
lines. When the -c or --count option is also used, grep does not output a count greater than NUM. When the
-v or --invert-match option is also used, grep stops after outputting NUM non-matching lines.
So NUM was to be replaced with an actual number…didn’t see that coming, good to know.
Just to be completely clear, I did not know what it meant off the top of
my head and have only used it once or twice in my life. I found this by
removing the unknown option from the command and then hoping to see a
difference in the output from which I could infer the option’s purpose.
Since instead I had an error message, I was led back to ‘-m’. I share
this in case it helps in troubleshooting other flags in the future.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
Just for a bit more explanation, this particular method of generating a
random password does so by waiting for eight consecutive characters
matching the regex specified (alphanumeric stuff basically) which happens
pretty regularly and quickly, but if you increase the integer to something
like 10 or higher you’ll quickly see limits in the usability of this
method to generate a long password unless you call it (the command)
repeatedly. A way that I’ve found recently that seems to work
more-reliably follows (for a 64-character password; adjust the last
integer appropriately for other lengths):
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
I’d appreciate if you could explain what that does…there are many symbols in there and it could be difficult to understand for someone who doesn’t know command line. And the order of operations is also important: you’ve specified a redirection symbol (“<”) and a pipe (“|”) - which one is parsed first?
After reading a bit in the manpage I believe what it does is takes a list
of characters as input (the stuff in single-quotes), finds the complement
(’-c’, so all of the other possible characters) and deletes those other
characters (the complement) when they show up (-d). That output is piped
to head which sees all of this from ‘tr’ as a big stream of data, because
everything going into ‘tr’ is a big stream of data from /dev/urandom, and
head then watches for sixty-four characters at which point it exits.
Regarding stdin vs. stdout, all file descriptors exist at the same time so
they all apply to a process at once. We feel like STDIN happens first
because input usually comes before output, but it’s just a broke in how we
work that causes that misunderstanding. Every program in *nix always has
three file descriptors defined: 0 (STDIN), 1 (STDOUT), and 2 (STDERR), and
most have more. What goes into STDIN, or what comes out of STDOUT and
STDERR, is up to the shell calling the program or the program itself, but
they’re always there. While the order matters a little bit around the
operators, the placement of the operators doesn’t matter as much as we
think. For example, you could rework this to have the redirect to STDIN
before the tr command itself. Go ahead, give it a shot.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
riderplus wrote:
> ab;2592793 Wrote:
>> Code:
>> --------------------
>> tr -dc ‘!@#$%^&*()_±=_A-Z-a-z-0-9’ </dev/urandom | head -c${1:-64}
>> --------------------
>
> I’d appreciate if you could explain what that does…there are many
> symbols in there and it could be difficult to understand for someone who
> doesn’t know command line.
In general, it’s better if YOU make an attempt to understand it first
and then post either specific questions about points you don’t
understand, or post your understanding and ask for confirmation. That
way, you learn something, and you don’t waste other peoples time.
> And the order of operations is also
> important: you’ve specified a redirection symbol ("<") and a pipe ("|")
> - which one is parsed first?
As ab explained, the order isn’t important.
That’s definitely my choice…firstly. Then, I understood what it was about, I asked ab to answer for others who might see this post, since he’s more experienced than myself. Third, I’m not wasting anyone’s time, I didn’t press ab to answer at all, it was his choice to answer and give me further details, even an assignment.
ab didn’t say that the order isn’t important. In fact, in Linux the order in which symbols are parsed is essential. He said something else and I understood his point.
I guess this is what you meant:
< /dev/urandom tr -dc '!@#$%^&*()_+-=_A-Z-a-z-0-9' | head -c${1:-64}
Thank you for this assignment and for taking your time to provide those who read this post with so many details!