Por cierto, si a alguien le aburren mis peroratas sobre cualquier tema... ¡avisad! Mi intención con este cacharro de Fediverso era tener @yo como cuenta genérica.
Ahora tengo @coder para cosas de programación en inglés.
He acabado mi primer libro de la Úrsula. Seguramente tenga que leer más (libros suyos y en general). Muy recomendable La mano izquierda de la oscuridad.
@kastwey @jmdaweb curiosamente, cuando usas la tecla en Windows, parece que si nadie recibe la tecla, Windows saca una ventanita que te dice que no hay conferencia activa o algo así. O sea que Windows podría avisar si la tecla "pasa", pero entiendo que lo correcto es que se encargue la aplicación de la misma manera que si pulsas su botón.
Hay por ahí bastantes scripts y chapuzas alrededor de esto. Esperaba que con los Stream Deck y tal avanzase más el tema...
@kastwey ah, ni sabía que Meet tenía aplicación. Pensaba que Meet tenía atajos de teclado globales de navegador, pero acabo de probar en Windows y parece que no.
(Con Slack me funcionaron brevemente atajos globales en Linux con Wayland, lo que es rarísimo. Allí avanza que las aplicaciones puedan registrar acciones globales que puedes mapear a teclas en el entorno de escritorio. Pero tardaremos años en que todas estas cosas lleguen a puerto.)
@kastwey hostias. No funciona en Google Meet ni con Edge ni con Firefox. (Igual con Chrome sí.)
Este es un tema que me obsesiona; silenciar el micrófono a nivel de sistema operativo no mola tanto como activar el mute de la aplicación de conferencia de turno.
Con el Stream Deck hay más gente intentando hacer estas cosas.
(Entiendo que en ecosistema llevan ventaja con esto. Entiendo que Win+Alt+K va por el mismo camino que usan los auriculares "certificados" para Teams.)
para los ciegos de mi TL y para todo aquel que use teclas rápidas :). En windows hay una tecla rápida para silenciar o quitar el silencio del micrófono en una app de llamada activa: teams, zoom, meet... NO sé con cuáles funciona, pero con Teams va súper bien.
Windows+Alt+K. No importa en qué ventana tengamos el foco. ¡Se acbó buscar la ventana de Teams para cambiar eso!
Lleva años, pero yo la descubrí esta mañana xD
¿Y vosotros, ya os la sabíais? :)
@microblogc uff, accidentes con rsync :)
Sí, por el mismo motivo te he puesto trozos de bash en los toots; si no lo pruebo antes no creo que pueda ser preciso. Yo ya me he acostumbrado a ese manual, pero cuesta...
Yo uso mucho:
https://pubs.opengroup.org/onlinepubs/9799919799/
, aunque creo que tampoco es mucho mejor. Pero normalmente lo que sale ahí funciona en todos sitios (e.g. en macOS).
@yo bueno, igual lo suyo es el microformato h-feed, que al parecer tiene soporte en algún que otro lector de RSS:
Quizá lo que habría que hacer es impulsar este sistema para HTML. Permitiría escribir páginas en HTML pelao o con Markdown "suscribibles" sin todo el bagaje de RSS/Atom.
Muchos días pienso que la característica más extraordinaria del protocolo Gemini es su "alternativa" a RSS. Una página Gemini con enlaces que empiezan por una fecha como "1979-12-03 Hoy es un gran día" se considera "suscribible" como un feed RSS o Atom.
Pero RSS y Atom son absurdamente complejos (con algún buen motivo, pero en general es complejidad accidental e innecesaria), mientras que el sistema de Gemini es trivial de hacer a mano.
@aperalesf es *muy* fácil romper un feed RSS (también Atom, creo).
Los gemfeeds de Gemini demuestran que RSS y Atom son excesivamente complejos para la mayoría de casos :)
Yo mismo he roto mi feed cada vez que he cambiado cómo funciona mi blog.
@microblogc (mucha gente es fan de TCL hoy en día. No lo conozco suficiente, pero igual es una alternativa a Perl... Rexx es un lenguaje bizarro de IBM que se usa en mainframes y que tuvo cierta vida en el Amiga. Yo lo usé un poco, es especialito pero tiene mucho encanto. No recomiendo intentar programar LibreOffice con TCL o Rexx, ni usar esos dos lenguajes para nada... pero igual sí dan una experiencia más tipo VBA.)
@microblogc ¿estás con Windows con WSL? https://flow-control.dev/ tiene pintaca, aunque lo he usado muy poco.
@microblogc hoy en día casi todos los editores ligeros tienen soporte decente para trabajar bien en Python. vim y su familia desde luego. Yo uso Emacs que sí tarda mucho en cargar (2s) pero con emacsclient no me entero.
Pero ya te digo, igual Perl es lo que buscas. Mucha gente de Perl se pasó a Ruby, pero por lo que dices de Python seguramente no te guste tampoco (la indentación no es significativa, pero es más o menos igual de "superestructurado").
@microblogc https://en.wikipedia.org/wiki/Universal_Network_Objects ,¡ veo que hay soporte para Rexx y TCL!
Igual ya has tocado UNO, yo no lo he usado personalmente, sólo creo que es el equivalente de VBA, pero ni idea, igual es horrible.
@microblogc huy, eso es todavía más bizarro :)
A=b comando es *casi* equivalente a export A=B ; comando y desexporta y se carga la variable al acabar. Es muy conveniente cuando quieres pasar variables de entorno sólo a un subproceso.
Pero hace unos meses me descubrieron otra criatura del averno que acecha en esa sintaxis. Hay una diferencia sutil entre las variables de entorno definidas así y las definiciones normales que creo que recordar que da pánico...
@microblogc siempre me falta un "Perl limpio y moderno" que te permita meter un chorro de código en una línea (lo que no permite Python) y con todos los atajos que molan de los shells que no tiene Python.
El problema es que siempre intento ceñirme a herramientas más o menos estándar (por eso intento conocer bash y sus diferencias con sh, que sh siempre está). Pero me salgo a Python porque está casi siempre y hay cosas que con sh es imposible. (Me niego a aprender awk, perl...)
@microblogc creo que ./script debería ser más o menos equivalente, no se me ocurren casos (fuera de lo de querer afectar el entorno o no querer pagar subprocesos) en los que usar . sea una ventaja. Pero no es un tema que domine 100%
@microblogc va a gustos, claro. Yo uso Python porque estoy acostumbrado y está casi siempre instalado. La cosa más parecida a un lenguaje de shell pero más cercana a un lenguaje de programación es Perl. Yo me niego a aprender Perl, pero me parece que resuelve la mayoría de problemas de los shell (y crea muchos nuevos, claro). Si no has jugado con Perl igual te gustaría si te disgusta Python.
@microblogc y menos importante: antes he mencionado trap como signo de que hay que dejar bash porque si en la mayoría de lenguajes el control de errores y los bloques "finally" ya son complicados y un dolor de cabeza para hacerlos correctamente, en bash todavía más.
Intentar "deshacer" cosas en bash es... mala señal. Lo suyo es usar subprocesos para lo que sea importante limpiar y se pueda acotar mediante un subproceso. (Y eso implica pagar el coste de los subprocesos, claro.)
@microblogc ten en cuenta que find -exec ejecuta un subproceso, con lo que pierdes igual las variables que las funciones. (Que al final son casi lo mismo.)
@microblogc si las exportas aparecen en los subshells, pero sí:
$ A=a
$ echo $A
a
$ bash -c 'echo $A'
$
Si ejecutas tu script con ./script, eso se ejecuta en un subproceso y su entorno se pierde al finalizar. Si lo ejecutas con '. script', se ejecuta en el mismo entorno en el que estás modificándolo.
Recomiendo usar '. script' sólo cuando es estrictamente necesario; precisamente por necesitar afectar al entorno o (muy raramente) por rendimiento.
@microblogc export -f me parece maravilloso o terrorífico según el día.
Te animaría a usar Python u otro lenguaje de programación que no sea un shell. Bash es mi lenguaje de programación favorito (en serio), pero es agotador tener que explicar todas sus idiosincrasias. Hay una serie de puntos donde es mejor abandonar el shell; típicamente pongo de ejemplo tener que usar trap, arrays o IFS; export -f es todavía peor, creo...
$ f() { echo hola ; }
$ f
hola
$ export -f f
$ bash -c "f"
hola
En el manual de bash puedes encontrar la explicación de export -f. Una pista para ver cómo funciona es ejecutar:
$ bash -c 'cat /proc/$$/environ | xargs -0 echo'
después de los comandos anteriores.