Nerver forget again. For timestamp 1353101513:
$ date -d "1970-01-01 + 1353101513 seconds" +"%F %T"2012-11-16 21:31:53Et voilí!
Categoría: trucos (Página 1 de 2)
Esta pregunta me ha hecho hoy Mr. Client*. Reconozco que no ha sido el primero pero supongo que tampoco será el último.
Mi primera respuesta es que mi religión me lo impide. Ya no recuerdo la última vez que usé FTP por cuenta propia. En caso de necesitar FTP siempre usaré SFTP y, si tengo acceso shell, SCP. No hay nada mejor que una consola y, si es posible, una sesión SSH.
Pero realmente no quería hablar de FTP, sino de clientes para estos servicios. No tengo nada en contra de ellos y si los usas me parece muy bien, pero voy a explicar porque tiendo a no usarlos si es que puedo cambiarlos por comandos en la consola o por acciones que pueda controlar directamente con el teclado. ¿Raro? ¿Arcaico? ¿Friki? Ni mucho menos, eficiente.
Y si el simple hecho de mover las manos entre el teclado y el ratón hace que seas más lento, podemos incluir el hecho de que para la mayoría de las acciones que tengas que hacer bastaría con repetir la misma acción (subir un fichero, copiar una carpeta, borrar un fichero, etc).
Ahí van un par de las preguntas más frecuentes:
«¿Y tienes que estar todo el rato conectándote? ¿Y la contraseña?»
Para esta pregunta, la solución está en este post en el que explica como crear un par de claves que te permita acceder al servidor de forma sencilla y segura.
La respuesta es sí, pero es que conectarme al servidor es una cosa muy sencilla. Además, para configuraciones habituales o que requieran de muchos parámetros, siempre podemos «Tunear» un poco nuestro ssh 😉
«¿Y cuando tienes que subir varios ficheros?»
El tema se pone interesante. Depende del caso, desde el más sencillo usando wildcards:
scp *.log host:/var/logO algo más complicado:
scp {script,config}.php host:/var/wwwO siempre está la opción de hacernos un mini-script que suba varios ficheros, aunque recordemos que siempre que podamos hacerlo en la misma conexión, ganaremos tiempo.
«Vale, ¿y cuando tienes que subir muchos ficheros? ¿Y carpetas?»
Para las carpetas, nada como la opción -r que permite subir ficheros de forma recursiva, incluyendo directorios.
Cuando tienes que subir muchos ficheros, automatización con un script o incluso usar un tar.gz, subir y descomprimir. Si realmente tienes que trabajar con cambios en muchos ficheros en distintos sitios, la mejor opción sería rsync lanzado manualmente (hasta el momento, no me he encontrado con este caso, pero bueno, será por opciones).
O puedo asegurar que si os gusta la velocidad, lo primero es aprender a no usar el ratón (que no quiere decir que no lo uséis) y luego, a automatizar los trabajos repetitivos. Conseguiréis ser más rápidos, eficientes y, como no, aprenderéis más cosas.
Que no se me enfade nadie, cada uno es libre de usar las herramientas como quiera. Sólo he dado mi propuesta que, además, vale tanto para Linux, Windows o Mac.
*: cariñosamente para el post de hoy 😉
Uno de los métodos más baratos y conocido para hacer debugging «en parejas» es el método denominado «el patito de goma». Creo que esta es la primera vez que se habla sobre él.
Es realmente sencillo y he tenido he podido comprobar (conmigo y con otros) como la eficacia de este método es elevadísima. Hay que seguir unos sencillos pasos:
- Conseguir un patito de goma, preferiblemente variedad baño (aunque se aceptan versiones tipo pirata, Sherlock Holmes o incluso ¡diablo!)
- Colocar el patito cerca nuestra, en el escritorio por ejemplo e informarle que vais a ver un poco de código, a ver si está de acuerdo.
- Explicar al pato qué es lo que se supone que hace el código y tras esto, entrar en detalle explicándolo línea a línea.
- En algún momento le dirás al patito lo que se supone que es lo siguiente a hacer y te darás cuenta que eso no es lo que realmente está haciendo tu código. El pato se mantendrá sentado serenamente, contento de saber que te ha ayudado en tu tarea.
Existen variantes al patito de goma, como otro tipo de peluches y objetos, pero su efectividad no está tan demostrada como con el patito de goma.
Es posible que te encuentres en la situación (doy un par de ejemplos más abajo) en los que necesites que tu Android Emulator haga caso a tu /etc/hosts en vez de al DNS. Para este caso, lo que tienes que hacer es seguir estos dos sencillos pasos:
- Crear un fichero hosts en tu ordenador (o usar el que ya tienes en /etc/hosts)
- Remontar el emulador y copiar el fichero anterior
La necesidad de remontar viene porque si no, el dispositivo está como sólo lectura y por lo tanto es imposible escribir nada en él.
Supongamos que tenemos partimos de nuestro /etc/hosts, iríamos al directorio donde tenemos las tools del SDK y teclearíamos:
adb remount
adb push /etc/hosts /system/etc/También es posible coger el fichero hosts que tiene el emulador (por ejemplo, copiandolo a nuestro directorio /tmp):
adb push /system/etc/hosts /tmp¿Y en qué casos nos puede hacer falta? Bueno, yo en concreto lo he necesitado cuando estaba desarrollando una aplicación que se alimentaba de un webservice. Realizaba el desarrollo del webservice en paralelo y por lo tanto no estaba (todavía) en la máquina de producción. De esta forma, gracias al fichero hosts obligaba al emulador a buscar en mi entorno de desarrollo en vez de ir al de producción, haciendo que la aplicación tuviese un comportamiento transparente, en código, sobre dónde atacar.
Por defecto en bash sólo se pueden retornar enteros. ¿Qué hay que hacer entonces para que retorne un valor no entero?
El truco está en hacer un echo del valor y asegurarnos en la llamada de la función que se asigna a una variable. Es decir, nuestra función sería:
function retorna_texto {
echo -n "este es el valor a retornar"
}Y la llamada:
VALOR=$( retorna_texto )Ahora en ${VALOR} tendremos el texto tal y como queríamos
Seguro que no es la primera vez que, usando git, inicializas el repositorio, haces unos cuantos commit y para cuando te das cuenta, ya tienes varios Usuario
Antes de ponerlo en un repositorio público como por ejemplo github, hay que cambiar esto y lo haremos de una forma muy sencilla usando git filter-branch. Este comando nos permite hacer multitud de diferentes cambios sobre todas las ramas en el proyecto y, entre otras cosas, cambiar estos dos datos que nos hacen falta.
Supongamos que los datos que queremos poner son:
- Usuario: Tatai
- E-mail: tatai@example.com
Entonces, el comando que tenemos que usar es:
git filter-branch --env-filter 'export GIT_AUTHOR_NAME="Tatai";GIT_AUTHOR_EMAIL="tatai@example.com"'Tras ejecutar el comando, veremos como se reescriben todos los commits.
En caso de querer cambiar únicamente ciertos commits y no todos, podemos añadir al final del comando el intervalo, por ejemplo, para los 10 últimos commits: HEAD~10..HEAD
Al hilo del último post sobre cómo «tunear» un poco nuestro ssh, podemos usarlo por ejemplo si tenemos varias cuentas en github.com. Cuando ocurre esto, por cada cuenta que tienes en github, tienes que añadir una clave pública; esto no es ningún problema ya que podemos crear tantas claves como queramos, pero lo que no es tan fácil es cambiar la cuenta ssh con la que debe conectarse el cliente de git a github. No es muy común, pero te puede ocurrir como a mi, que tienes tu cuenta personal y la del trabajo.
Para poder conseguir esto, supongamos que tienes estos datos:
- Cuenta personal
- Usuario: usuario_casa
- Fichero de clave: ~/.ssh/casa
- Cuenta trabajo
- Usuario: usuario_trabajo
- Fichero de clave: ~/.ssh/trabajo
Lo que habría que hacer es tener un fichero de configuración ssh (recordemos que está en ~/.ssh/config) de la siguiente forma:
Host github
HostName github.com
User usuario_casa
IdentityFile ~/.ssh/casa
Host github-trabajo
HostName github.com
User usuario_trabajo
IdentityFile ~/.ssh/trabajo
La diferencia es sutil: cambia el valor que ponemos en Host (los espacios o tabulaciones son opcionales, yo los uso para dar un poco más de orden).
Con esto, tenemos que cambiar la dirección con la que nos conectaremos con la cuenta de trabajo. Si por ejemplo, para añadir el repositorio remoto usamos:
git remote add origin git@github.com:usuario_trabajo/proyecto.gitAhora deberemos poner:
git remote add origin git@github-trabajo:usuario_trabajo/proyecto.gitEs decir, ssh se encargará automáticamente de hacer el cambio por nosotros y, de esta forma, no tendremos problemas decidiendo con qué usuario debe conectar o no, está todo en el fichero de configuración 😉
Este es un sencillo truco que a mi me descubrió hace ya un tiempo mi buen amigo Iñigo, que os abrirá (si no lo ha hecho ya) una puerta hacía una mayor rapidez con el comando ssh. Empezaré directamente poniendo un ejemplo: supongamos que para acceder a un servidor con los siguientes parámetros (lo sé, están un poco exagerados, pero creo que se entenderá el ejemplo):
- Dirección: punto.de.entrada.al.servidor.com
- Usuario: miusuario
- Puerto 12345
- Fichero de clave: /home/user/.ssh/fichero.clave
El chorizo comando que nos hace falta es:
ssh punto.de.entrada.al.servidor.com -l miusuario -p 12345 -i /home/user/.ssh/fichero.claveCasi nada
Bien, hay una forma de acortarlo un poco. El truco está en configurar todos estos parámetros en un fichero. Este fichero lo podemos encontrar en nuestra cuenta de usuario, concretamente en ~/.ssh/config. Este fichero por defecto viene vacío pero, siguiendo con el ejemplo escribimos estas líneas en su interior:
Host miservidor
HostName punto.de.entrada.al.servidor.com
User miusuario
Port 1234
IdentityFile /home/user/.ssh/fichero.clave
Con este simple gesto, ahora podemos cambiar el comando ssh anterior por:
ssh miservidorCasi nada la diferencia 🙂
Si investigas un poco el man de ssh_config seguro que encuentras muchas cosas de utilidad. Más adelante daré otro truco relacionado con este.
P. P: y como bien te recomendaría un administrador de sistemas, si encima añades el hostname a tu /etc/hosts, irá «volado»! Se ahorrará la resolución DNS
Enlaces:
Si estás trabajando con git, seguro que alguna vez has querido hacer un «export» (usando terminología de subversion: un svn export), es decir, obtener todos los ficheros sin los datos de #git. La opción más fácil sería copiar todos los datos y borrar la carpeta .git, pero si quieres evitarte crear el script, aquí tienes una sencilla solución, usar checkout-index. El comando sería más o menos así:
git checkout-index -a -f --prefix=/path/export/Importante: no olvides la última barra (slash).
Y ahora la breve explicación. checkout-index crea una copia de los fichero en el index a donde le indiques, pero sin sobreescribir, algo que evitaremos con la opción -f. Con la opción -a le indicamos que copie todos los ficheros en el index y con –prefix indicamos un prefijo que queremos que añada a todos los ficheros que extraiga (es decir, poniendo un path, es un truco para decirle que lo extraiga en otro lugar y con el mismo nombre, de aquí que tengamos que poner la última barra).
Es una forma sencilla y necesitas de tu copia local en el mismo servidor, algo que me gustaría evitar, pero de momento, tiraremos con esta opción.
Seguro que alguna vez has necesitado una contraseña de estas complicadas y no sabías que poner. Pues bien, de las millones de posibilidades que tienes para generar una, yo tengo esta que la verdad, me parece sencilla y rápida:
cat /dev/urandom | tr -dc "a-zA-Z0-9-_\.\!\$\?" | fold -w 10 | head -n 1Ok, explicación:
- /dev/urandom: fuente aleatorio de información
- tr -dc «a-zA-Z0-9-_\.\!\$\?»: elimina cualquier caracter que no sea una letra, un dígito o alguno de los símbolos – _ . ! $ ?
- fold -w 10: obliga a que el tamaño sea de 10 caracteres
- head -n 1: mostrar una contraseña
Así pues, si quieres que tu contraseña tenga x caracteres, cambia el 10 del comando fold por ese valor y si quieres obtener más de una contraseña, indicalo cambiando el 1 de head por tantas como quieras. Por supuesto, si quieres cambiar los caracteres válidos, modifica la expresión de tr.