Categorías
hoy aprendí ...

… a decirle a git que deje de darle bola al cambio de modo de los archivos

git config core.fileMode false

Encontrado en https://stackoverflow.com/a/1580644

Con una explicación muy buena:

Try:

git config core.fileMode false

From git-config(1):

core.fileMode
    Tells Git if the executable bit of files in the working tree
    is to be honored.

    Some filesystems lose the executable bit when a file that is
    marked as executable is checked out, or checks out a
    non-executable file with executable bit on. git-clone(1)
    or git-init(1) probe the filesystem to see if it handles the 
    executable bit correctly and this variable is automatically
    set as necessary.

    A repository, however, may be on a filesystem that handles
    the filemode correctly, and this variable is set to true when
    created, but later may be made accessible from another
    environment that loses the filemode (e.g. exporting ext4
    via CIFS mount, visiting a Cygwin created repository with Git
    for Windows or Eclipse). In such a case it may be necessary
    to set this variable to false. See git-update-index(1).

    The default is true (when core.filemode is not specified
    in the config file).

The -c flag can be used to set this option for one-off commands:

git -c core.fileMode=false diff

Typing the -c core.fileMode=false can be bothersome and so you can set this flag for all git repos or just for one git repo:

# this will set your the flag for your user for all git repos (modifies `$HOME/.gitconfig`)
git config --global core.fileMode false

# this will set the flag for one git repo (modifies `$current_git_repo/.git/config`)
git config core.fileMode false

Additionally, git clone and git init explicitly set core.fileMode to true in the repo config as discussed in Git global core.fileMode false overridden locally on clone

Warning

core.fileMode is not the best practice and should be used carefully. This setting only covers the executable bit of mode and never the read/write bits. In many cases you think you need this setting because you did something like chmod -R 777, making all your files executable. But in most projects most files don’t need and should not be executable for security reasons.

The proper way to solve this kind of situation is to handle folder and file permission separately, with something like:

find . -type d -exec chmod a+rwx {} \; # Make folders traversable and read/write
find . -type f -exec chmod a+rw {} \;  # Make files read/write

If you do that, you’ll never need to use core.fileMode, except in very rare environment.

Categorías
hoy aprendí ...

… a ordenar archivos en carpetas según el patrón de nombre

Descargando un montón de referencias desde Instagram usando esta maravillosa extensión, Instagram Download Button, me llené de archivos JPG y MP4 y se hacía necesario ordenarlos en carpetas.

El patrón es que todos los archivos tienen en la primer parte del nombre la perfil de Instagram y luego la fecha y hora original del posteo seguidos de un choclazo de números, así que tendría que ser «relativamente» sencillo poder encarpetarlos identificando el perfil.

nombre_perfil-YYYYMMDD_HHMMSS-XXXXXXXXX….. [jpg|mp4]

Buscando en encontré varias propuestas aproximadas para hacer algo como lo que quería

Y la opción ganadora

Extract part of a file name in bash

Específicamente esta respuesta que utiliza el comando SED. La única condición es que la primera parte no sean numeros.

El escenario

I have a folder with lots of files having a pattern, which is some string followed by a date and time:

BOS_CRM_SUS_20130101_10-00-10.csv (3 strings before date)
SEL_DMD_20141224_10-00-11.csv (2 strings before date)
SEL_DMD_SOUS_20141224_10-00-10.csv (3 strings before date)

I want to loop through the folder and extract only the part before the date and output into a file.

Output
BOS_CRM_SUS_
SEL_DMD_
SEL_DMD_SOUS_

La propuesta

Assuming you wont have numbers in the first part, you could use:

$ for i in *csv;do  str=$(echo $i|sed -r 's/[0-9]+.*//'); echo $str; done
BOS_CRM_SUS_
SEL_DMD_
SEL_DMD_SOUS_

Prueba

Cuando hice la prueba, solo mostrando el resultado del SED, funcionaba casi como lo deseaba, con el único tema que era que procesaba algunos archivos con otros patrón de nombre (que no eran necesarios) y los que si debía procesar dejaba el guión del medio.

Ejemplo:

almendromaestro-20220602_195749-285312905_1062446314350240_327302066906487345_n.jpeg

> almendromaestro-

Mi modificación a la RegExp

Agregar un guión que aparece antes de la regla para la fecha, así sólo busca los archivos que se aproximan al patrón.

sed -r 's/-[0-9]+.*//'

y pasó el testeo!

Script terminado

Básicamente hace un loop en todos los archivos que haya en la carpeta, separa el nombre y la almacena en STR (y lo mostramos para ir viendo el progreso), usa eso para verificar que si no existe una carpeta la crea, y luego mueve el archivo a la carpeta.

#!/bin/sh

for i in *.*
do
  str=$(echo $i|sed -r 's/-[0-9]+.*//'); 
  echo $str;
  if [ ! -d $str ]; then
      mkdir $str
  fi
  mv $i $str
done

Y chau!

Categorías
hoy aprendí ...

… a tener que escribir todo, incluso lo que ya sabía

Por que por más buena memoria que uno cree tener, a medida que el disco rígido se llena, cada vez es un esfuerzo mayúsculo tener que rememorar. Y a hacer limpieza!

Categorías
hoy aprendí ...

… a reparar unos errores en GIT al hacer push

Quise realizar un push a un repositorio remoto y me soltó un error que nunca había visto:

remote: error: refs/tags/v2.0 does not point to a valid object!

Pensé que se trataba de algún archivo en el disco remoto que se había corrompido, pero cuando hice la prueba con otro repositorio obtuve un error similar (lo trato más abajo).

Lo que pude averiguar es que la referencia del tag v2.0 no apuntaba bien. La solución no está confirmada pero hice:

  • prune en el repo remoto
  • gc tambien en el remoto, aunque me soltaba un error también relacionado con el tag v2.0
  • desde el repo local borré el tag remoto
  • hice un prune y gc (me dio error)
  • luego el push del tag local al repo remoto y funcionó.

En el caso del otro repositorio el problema eran ramas y no etiquera, y varias.

Aquí lo que me funcionó fue: en el repo remoto editar el archivo packed-refs y eliminar las referencias de las ramas indicada, correr un prune y luego en un gc. En el repo local facer un prune y un fetch. Y funcionó.

No estoy totalmente seguro pero hay pasos que me parece que no hace falta.

Chau.

Categorías
hoy aprendí ...

… a recuperar mis escritorios en W10 y darle una patada al Task View

Resulta que a pesar de tener que trabajar en Windows 10 había logrado organizar el tema de los múltiples escritorios para ayudarme a focalizar el trabajo según el tema con la ayuda de Windows 10 Virtual Desktop Enhancer, una aplicación que le agregaba mejoras a los paupérrimos escritorios virtuales (virtual desktops) que traía el sistema operativo ¡en pleno 2019! Nada de fondos personalizados o la posibilidad de darles nombres. Había que recurrir a soluciones de terceros.

El W10VDH ya no tenía soporte ni desarrollo desde fines del 2018 pero funcionaba muy bien hasta hace poco, cuando hubo una actualización de Windows que de repente había habilitado el Task View, Historial, Cortana, y otras «mejoras» más. Pasó que de repente cuando cambiaba de escritorio no me cambiaba el fondo, ni me mostraba el nombre, y al hacer WIN+TAB para tener la vista general de las ventana, me habían cambiado todo de lugar, y aparecía lo de la actividad reciente con el Historial. WTF!

La solución que encontré para poder trabajar como venía haciendo fue:

  1. Encontrar un fork más actualizado del Windows 10 Virtual Desktop Enhacer: https://github.com/vlwkaos/win10-virtual-desktop-enhancer
  2. Descargar el repositorio y ubicar los nuevos scripts en la carpeta donde tenía corriendo el ejecutable original del Windows 10 Virtual Desktop Enhacer.
  3. Desactivar la tecla TaskView de la barra, Cortana, y el Historial.