4 ms·

tr -cd a-zA-Z0-9 </dev/urandom | dd bs=1 count=32 2>/dev/null; echo Works on Android (Toybox userland) and macOS (BSD userland, but you might need to prefix LC

tr -cd a-zA-Z0-9 </dev/urandom | dd bs=1 count=32 2>/dev/null; echo Works on Android (Toybox userland) and macOS (BSD userland, but you might need to prefix LC_ALL=C to get `tr` to not hate the binary input) at least. And it's more flexible, as you can customize the charset and password length arbitrarily, which you can't with base64.

DonHopkins 5y ago
I always wanted the /dev/zero driver to use the device minor number to define the number that got used instead of zero, so you could mknod /dev/seven to make an infinite source of beeps.
- enriquto 5y ago
  Why don't you submit a patch to the kernel so that this beautiful idea becomes reality? It is free software: here you can easily be the change you want to see in the world. You may need to be careful because the major number is shared with /dev/null, but I doubt these numbers are hardcoded in many places.
  - marcan_42 5y ago
    They are definitely hardcoded in many places (e.g. embedded systems, early bring-up - udev style stuff is used for most things these days, but the core /dev/zero, /dev/null, /dev/console stuff is hardcoded everywhere). This would be a kernel-userspace ABI break, which is a big no-no. You could add a new major that does this (keeping the old numbers for compatibility), but I think you'd have a hard time convincing people that this is a worthwhile enough idea; hard-coded new major numbers are in short supply.
    - DonHopkins 5y ago
      At this point in history it would be prudent to support the full unicode character set, so you could have /dev/poop, etc.
- GoblinSlayer 5y ago
  /dev/echo - open it, write what you want and let it be echoed as much as you read.
ReleaseCandidat 5y ago
/dev/urandom is not part of POSIX. POSIX only defined/dev/null, /dev/tty and /dev/console https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap10.html https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1... But uuencode exists in the POSIX standard. https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/uuencode.html https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...
- marcan_42 5y ago
  True, but it's also not GNU anything. Most modern UNIX-like kernels implement some form of /dev/urandom or /dev/random. The actual shell tools used are POSIX. I don't think POSIX even defines any functions/system calls for getting cryptographically secure random numbers, so if you're literally restricting yourself to POSIX constructs, then indeed what OP asks for is impossible :)
GoblinSlayer 5y ago
In this sense base64 does 80% of the work, if plus and solidus are unwanted, you can delete them from the result by hand, another option is head -c 20 /dev/urandom | md5sum

DonHopkins 5y ago

I always wanted the /dev/zero driver to use the device minor number to define the number that got used instead of zero, so you could mknod /dev/seven to make an infinite source of beeps.

enriquto 5y ago
Why don't you submit a patch to the kernel so that this beautiful idea becomes reality? It is free software: here you can easily be the change you want to see in the world. You may need to be careful because the major number is shared with /dev/null, but I doubt these numbers are hardcoded in many places.
- marcan_42 5y ago
  They are definitely hardcoded in many places (e.g. embedded systems, early bring-up - udev style stuff is used for most things these days, but the core /dev/zero, /dev/null, /dev/console stuff is hardcoded everywhere). This would be a kernel-userspace ABI break, which is a big no-no. You could add a new major that does this (keeping the old numbers for compatibility), but I think you'd have a hard time convincing people that this is a worthwhile enough idea; hard-coded new major numbers are in short supply.
  - DonHopkins 5y ago
    At this point in history it would be prudent to support the full unicode character set, so you could have /dev/poop, etc.
GoblinSlayer 5y ago
/dev/echo - open it, write what you want and let it be echoed as much as you read.

ReleaseCandidat 5y ago

/dev/urandom is not part of POSIX. POSIX only defined/dev/null, /dev/tty and /dev/console https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap10.html https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1... But uuencode exists in the POSIX standard. https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/uuencode.html https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...

marcan_42 5y ago
True, but it's also not GNU anything. Most modern UNIX-like kernels implement some form of /dev/urandom or /dev/random. The actual shell tools used are POSIX. I don't think POSIX even defines any functions/system calls for getting cryptographically secure random numbers, so if you're literally restricting yourself to POSIX constructs, then indeed what OP asks for is impossible :)

GoblinSlayer 5y ago

In this sense base64 does 80% of the work, if plus and solidus are unwanted, you can delete them from the result by hand, another option is head -c 20 /dev/urandom | md5sum