Estoy tratando de llenar un archivo con una secuencia de 0 y 1 aleatorios con un número de líneas definido por el usuario y un número de caracteres por línea.
el primer paso es obtener un flujo aleatorio de 0 y 1:
cat /dev/urandom | tr -dc 01
luego traté de llenar un archivo con esta secuencia (y terminé el proceso de llenado con ctrl+c)
cat /dev/urandom | tr -dc 01 > foo
cuando cuento el número de líneas del archivo foo creado, obtengo 0 líneas.
cat foo | wc -l 0
Ahora traté de controlar la transmisión, así que creé una canalización con nombre y dirigí la transmisión hacia ella. Luego hice una conexión a la canalización nombrada con el comando dd con la esperanza de controlar de esta manera la cantidad de caracteres por línea y el número de líneas en el archivo.
makefifo namedpipe
cat /dev/urandom | tr -dc 01 > namedpipe
dd if=namedpipe of=foo bs=10 count=5
el archivo foo se llenó con 50 bytes de 0 y 1, pero el número de líneas seguía siendo 0.
¿Cómo puedo resolverlo? Supongo que tal vez tenga que insertar cada número de caracteres en una nueva línea en el archivo, pero si es así, no sé cómo.
Respuesta aceptada:
¿Qué tal fold ? Es parte de coreutils...
$ tr -dc 01 < /dev/urandom | fold -w 30 | head -n 5
001010000111110001100101101101
000101110011011100100101111000
111010101011100101010110111001
111011000000000101111110110100
110011010111001110011010100011
O si eso no está disponible, algo de awk :
$ tr -dc 01 < /dev/urandom | awk $0=RT RS=.{,30} | head -n 5
000100010010001110100110100111
101010010100100110111010001110
100011100101001010111101001111
010010100111100101101100010100
001101100000101001111011011000
O simplemente podrías hacer algo con un bucle...
$ for line in $(seq 1 5)
> do
> echo $(tr -dc 01 < /dev/urandom | head -c 30)
> done
100101100111011110010010100000
000000010000010010110111101011
010000111110010010000000010100
001110110001111011101011001001
001010111011000111110001100110
Estoy seguro de que hay otras formas... Pensé que tal vez hexdump con un formato personalizado podría hacerlo, pero aparentemente no... 😉