RetroMultiInstaller + github: número de la última versión para tu script de instalación

Un problema recurrente que me he encontrado con github es que cada vez que sale una nueva versión en un programa que usa el sistema de repositorios de github cambia la URL y por tanto deja de funcionar el script.

Durante algún tiempo he hecho la ñapa de definir una variable "version" para solo tener que cambiar este valor y estar cambiando todos los sitios donde sale para así evitar errores por "espaguetización", así por ejemplo sería el script para descargar un AppImage:

#/bin/bash
toolname="amspirit"
version="1.10.7"
url="https://github.com/AMSpiriT-Emulator/amspirit-releases/releases/download/v${version}-beta/freetube-${version}-beta-${arch}.AppImage"
source $pwddir/../commonscripts/makeopenchangetodir.sh /opt/appimages
wget -N ${url} -O ${toolname}.AppImage
chmod +x ${toolname}.AppImage
source $pwddir/../commonscripts/makeopenchangetodir.sh /opt/appimages/${toolname}.AppImage.home
cd $pwddir
$pwddir/../commonscripts/createshortcuts.sh ${toolname} 

Pero seguimos con la necesidad de estar pendiente de los cambios de versión, algo que es poco sostenible, así que investigué un poco como sabe github y, si está bien definido la dirección URL donde podemos consultar el número sería algo como ésto:

https://api.github.com/repos/usuario/programa/releases/latest 

La consulta nos devolverá un json con muchos valores, a nosotros nos interesa el que tiene la etiqueta 'tag_name', que tendría un valor como:

tag_name:    "1.10.7"

Así que lo primero que hice fue un nuevo script para uso común que haga esta tarea, pasándole como parámetros el usuario y repositorio del programa:

script: ./commonscripts/githubversion.sh 

#/bin/bash
# $1: user
# $2: repo
pwddir=$(pwd)
$pwddir/../commonscripts/instalator.sh  jq &> /dev/null
latestversionurl="https://api.github.com/repos/${1}/${2}/releases/latest"
versionpack=$(wget "${latestversionurl}" -q -O -)
tag=$(echo "${versionpack}" | jq -r '.tag_name')
echo ${tag#v} 

Con este script obtengo el número, puede que tenga algún sufijo o prefijo que sobra, por ejemplo supongamos que nos devuelve "Lite-1.10.7" en ese caso con el comando sed sustituimos esa cadena por la cadena vacía, así quedaría el script de instalación:

#/bin/bash
pwddir=$(pwd)
toolname="amspirit"
user="AMSpiriT-Emulator"
repo="amspirit-releases"
version=$(${pwddir}/../commonscripts/githubversion.sh ${user} ${repo} | sed 's/Lite-//')
arch=`uname -m`
url="https://github.com/${user}/${repo}/releases/download/Lite-${version}/amspirit-lite-qt-${version}-linux-${arch}.AppImage"
source $pwddir/../commonscripts/makeopenchangetodir.sh /opt/appimages
wget -N ${url} -O ${toolname}.AppImage
chmod +x ${toolname}.AppImage
source $pwddir/../commonscripts/makeopenchangetodir.sh /opt/appimages/${toolname}.AppImage.home
cd $pwddir
$pwddir/../commonscripts/createshortcuts.sh ${toolname} 

En caso de devolver solo "1.10.7" el trozo siguiente sobraría:

| sed 's/Lite-//')

Y ya está, ahora cada vez que seleccionemos instalar uno de estos programas siempre nos descargará la última versión publicada. 

Leer parte de una URL de otra URL y con plan B

Supongamos que queremos descargar mediante un script un archivo, pero con estas circunstancias:

1. Cuando cambia de versión, la URL cambia porque el número de versión es parte de la descarga.
2. Si accedemos a una dirección concreta obtendremos el número de versión actual. Para ello usamos el comando wget URL -q -O - que nos devolverá el contenido del archivo descargado, si no tiene éxito nos devolverá una cadena vacía. El resultado de la operación lo pasamos una variable.
   
3. En el caso de haber obtenido una cadena vacía, por estar la dirección que nos devuelve la versión fuera de línea, indicamos una versión que sabemos que siempre vamos a tener disponible. Así al menos poder instalar el programa aunque no sea la última versión.

En el script de descarga del emulador ZESarUX, tenemos un buen ejemplo de implementación de todo lo explicado:

#/bin/bash
software="zesarux"
carpeta="zesaruxpack"
latestversionurl="http://51.83.33.13/check_updates/stable.txt"
versionpack=$(wget $latestversionurl -q -O -)
if ["$versionpack" == ""]; then
    versionpack="12.0"
fi
echo "ZESarUX $versionpack"
../commonscripts/instalator.sh git build-essential libsdl1.2-dev libsdl2-dev libncurses5-dev libaal-dev libcaca-dev wget
wget -c https://github.com/chernandezba/zesarux/releases/download/ZEsarUX-$versionpack/ZEsarUX_src-$versionpack.tar.gz -O $software.tar.gz
tar -zxvf $software.tar.gz
mv ZEsarUX-$versionpack $carpeta
cd $carpeta
# compilar
git pull
cd src
./configure
make
sudo make install

Este script descarga la última versión estable de código, que tenemos en http://51.83.33.13/check_updates/stable.txt tal y como me indicó su creador.

Instala todas las herramientas TENTE 3D con RetroMultiInstaller

A finales del mes pasado le di un buen repaso a RetroMultiInstaller para ampliar las aplicaciones para crear, ver y renderizar modelos de TENTE 3D.

Como podéis ver en esa captura, hay 16 aplicaciones relacionadas con el uso de TENTE 3D con el formato abierto LDraw que se podrían agrupar así:

1. Editores:
1. MLCad: editor recomendado, es para Windows pero funciona perfecto con WINE.
2. LeoCAD: editor nativo. 
3. LDCad: editor nativo.
   
2. Visores:
1. LDView: Visor nativo muy sencillo pero potente.
   
3. Renderizadores: para obtener una mejor calidad que con los visores tradicionales:
1. StudIO: herramienta multiuso de LEGO, a nosotros nos va a interesar más como renderizador.
2. Blender: con un addon para añadir modelos LDraw, es una poderosa herramienta para hacer transformaciones y renderizar.
3. Povray: renderizador de rayos.
   
4. Generadores.
1. Generador de proas.
2. Generador de tubos.
5. Conversores:
   
1. STL2DAT.
2. SVG2LDraw.
6. Animación:
1.  LD4DStudio: herramienta de animación.
2. Stopmotion for TENTE 3D.
   
7. Utilidades varias:
1. BMP2LDraw: convierte archivo BMP en etiquetas en formato LDraw, es conveniente darle algún tratamiento previo a la imagen con GIMP para obtener óptimos resultados.
2. LDDesignPad: editor de texto para el formato LDraw, para cambiar a mano elementos de modelos y fichas.
3. LPartEditor: editor de piezas.

Todas estas herramientas están preconfiguradas para usar directamente el juego de fichas de TENTE, y en la mayoría de los casos también con el de LEGO o el de Exin Castillos.

Os dejo un vídeo con la instalación sencilla de RetroMultiInstaller, ni siquiera hay que entrar en la consola de GNU/Linux.

 

Si encontráis alguna deficiencia o tenéis más piezas para añadir podéis poner un comentario en la sección de issues de cada repositorio.

RetroMultiInstaller: los menús solo muestran apps compatibles con el ordenador que lo ejecuta (e instalación desatendida)

RetroMultiInstaller, el script facilitador de instalaciones tenía el defecto de ofrecerte todos los scripts de instalación en sus menús, aunque no fueran compatibles con tu hardware, así por ejemplo, si lo ejecutabas en una Raspberry Pi podrías terminar instalando un programa que no fuera compatible con ARM y que por tanto no iba a funcionar.

También se ha corregido la instalación por lotes desatendida y ya aparecen solo los programas ordenados para la arquitectura actual.

 

Recuerda que, si ya tienes instalado RMI, lo puedes actualizar seleccionando las opciones:

Update ► update own

 

¿Como lo he hecho y como puedes añadir más instaladores?

Para solucionar esto he incluido un nuevo mecanismo que mira las arquitecturas declaradas en los archivos menu/*.txt de tal manera que la definición de cada línea de script quedaría ahora con esta estructura:

arquitecturas etiqueta definición

• Las arquitecturas se ponen una detrás de otra separadas por el carácter tubería "|" por ejemplo, NUNCA ESPACIOS NORMALES.
• La etiqueta sigue siendo el identificador del script.
• La definición tampoco permite ESPACIOS NORMALES pero sí espacios duros.

Algunos ejemplos, que podemos encontrar casi todos en el archivo menus/multisystem.txt:

• Si ponemos como arquitectura 'all' no filtrará, es decir, mostrará el script del menú independientemente del hardware desde el que ejecutemos RMI:
  

  all ZEsarUX ZEsarUX multi emulator

• Podemos poner una sola arquitectura, en la siguiente línea tenemos un script que solo se mostraría en Raspberry pi OS de 32 bits:
  

  armv7l Retropie Multi Emulationstation Enviroment

• Un ejemplo de un script que se ejecutaría en varias arquitecturas, en este caso solo para Intel de 32 o 64 bits o Raspberry pi OS de 64 bits.
  

  x86|x86_64|aarch64 RetroVM Retro Virtual Machine

• Las opciones para abrir otro menú o salir del actual deben tener la etiqueta menu para no aparecer en las opciones de la instalación desatendida:
  

  menu Exit Return to Main Menu

• Si en un momento un script dejara de funcionar ya no teníamos que borrarlo podemos dejarlo para arreglarlo más adelante y en el menú poner como arquitectura algo así como 'none' o 'disabled':
  

  none oldgame Old Game

 

He encontrado un programa que NO funciona, ¿qué hago?

Ahora queda la ardua tarea de ir comprobando que las arquitecturas definidas en cada script se corresponden con los programas que se pueden ejecutar en cada arquitectura, como seguro se me van a pasar muchos necesitaré vuestra ayuda en los comentarios para que me indiquéis los que no funcionan.

 

Aunque si abrís una incidencia en el propio gitlab me resultará más fácil tener el seguimiento de lo que está pendiente de arreglar. ;-)

Instalación desatendida por lotes (batch)

Actualizar RetroMultiInstaller: autoactualización y actualización manual

El script RetroMultiInstaller sigue añadiendo nuevos scripts de instalación para que tengas cada vez más programas a tu disposición, pero si hace tiempo que lo instalaste te estás perdiendo todos los que se han añadido desde entonces: nuevas instalaciones, corrección de errores, etc...

Si lo instalaste a través de git, opción recomendada, basta con que te vayas a la autoactualización del script accediendo a las opciones:

Update ► updateown

Si te lo descargaste como un zip no te va a funcionar esta opción, ya que no tienes la historia de las versiones, en este caso te tocará borrarlo y volverlo a descargar, ya puestos hazlo con git y la próxima vez podrás actualizar de manera mucho más cómoda:

sudo apt install git
git clone https://gitlab.com/cpcbegin/retromultiinstaller

Saca todo el partido a este script facilitador de instalaciones. ;-)

Ampliando RetroMultiInstaller: los scripts de instalación (V)

El directorio installers es la carpeta que contiene toda colección de scripts que instalan cada uno de los programas.

Estos scripts se ejecutan desde el script instalador.sh desde la carpeta tmp para que los archivos temporales se creen en esa ruta.

El nombre del archivo del script de instalación que vamos a ejecutar sería la etiqueta que tenemos definida en el correspondiente archivo txt de la carpeta /menu seguido del sufijo _installer.sh
Si lo ejecutamos manualmente para probar que funciona correctamente hay que ir a la carpeta tmp y ejecutarlos así:

../installers/programa_installer.sh

Un ejemplo simple de script de instalación de software podría ser así:

#/bin/bash
../commonscripts/instalator.sh git
../commonscripts/createshortcuts.sh desktopcal
source ../commonscripts/makeopenchangetodir.sh /opt/webapps
git clone https://github.com/hvianna/desktopCal.js desktopcal

Los scripts que están dentro de la carpeta ../commonscripts son scripts para diversos usos que veremos en el próximo epígrafe.
El último de estos script se invoca con la instrucción source al principio, esto se hace para cambiar al directorio indicado. Hay que tener especial cuidado con los scripts que se ejecuten después de él, ya que a partir de ahora ya no se van a ejecutar desde la carpeta tmp sino por la indicada en este último script.
Después de git clone se pueden añadir todos los comandos para compilar el programa, si requiriera compilación, integración, etc…

Ampliando RetroMultiInstaller: el script principal (IV)

retroinstaller.sh es el script principal que debemos ejecutar para lanzar el RetroMultiinstaller, para analizar el código más en profundidad, he incluido en el mismo un comentario con un número que identifica lo explicado en los siguientes puntos:

1. La primera línea es distinta al típico /bin/bash para que también podamos ejecutarlo haciendo doble clic sobre el script en un entorno gráfico.
2. Definimos la función is_missing_dialog_pkg que comprueba si el paquete dialog está instalado y si no es así lo instala.
3. Después de invocar la función para instalar dialog si es preciso entramos en un bucle infinito.
4. Se asigna a la variable “seleccion” la salida del comando menugen.sh, pasada a minúsculas. El script ‘menugen.sh’ es el que realmente dibuja los menús y lo veremos más adelante.
5. Si se elige “exit” o se cancela el menú se sale del menú y se acaba la ejecución.
6. Si existe un archivo en la carpeta menús cuyo nombre sea igual al valor de la variable “seleccion” más la extensión “.txt” se ejecuta de nuevo el script pero pasándole como parámetro el valor de la variable “seleccion”.
7. Si selección toma un valor distinto a “exit” se ejecuta el comando cuyo nombre es el valor de la variable selección seguido de “_installer.sh”.
8. En este caso también se muestra un texto de ayuda con el script warninggen.sh de la carpeta commonscripts, si existe el archivo warning/seleccion.txt 

A continuación podemos ver como quedaría el script:

#!/usr/bin/env bash
function is_missing_dialog_pkg() { #2
    if [ ! -f /usr/bin/dialog ]; then
        while true; do
            read -p "Missing 'dialog' package. Do you wish to let me try to install it for you? (aprox. 1.3 kB) [y/n] " yn
            case $yn in
            [Yy]*)
                ./commonscripts/instalator.sh dialog
                break
                ;;
            [Nn]*)
                echo "Please install 'dialog' package to continue."
                exit 1
                ;;
            *) echo "Please answer (y)es or (n)o." ;;
            esac
        done
    fi
}

#3
is_missing_dialog_pkg
#Blue infinito para pintar los menus #3
while true; do
    #4
    seleccion=$(./commonscripts/menugen.sh $1  | tr '[:upper:]' '[:lower:]')
    #5
    if [ $seleccion == "exit" ] || [ -z "$seleccion" ]; then
        clear
        break
    fi
    #6
    if  [ -f "./menus/${seleccion}.txt" ]; then
        ./retroinstaller.sh $seleccion
    else
        #7
        mkdir tmp
        clear
        echo ">>> Installing ${seleccion}..."
        cd tmp
        ../installers/${seleccion}_installer.sh
        #8
        ../commonscripts/warninggen.sh ${seleccion}
        cd ..
    fi
done

Ampliando RetroMultiInstaller: archivos del directorio principal (III)

En el propio directorio donde hemos copiado Multi-installer tenemos una serie de archivos esenciales para su funcionamiento:

• retroinstaller.sh: es el script principal que tendremos que ejecutar para la ejecución del programa desde el directorio donde hemos copiado el programa, ya sea desde consola con la instrucción ./instalador.sh o haciendo doble clic desde el entorno gráfico de GNU/Linux, en cuyo caso tendremos que seleccionar la opción ‘Ejecutar desde una terminal’.
• README.md: documento escrito en el lenguaje markup para wiki en el que podemos incluir una descripción del programa Multi-installer junto con la relación de programas que se pueden instalar con el script, en cada ítem debería incluirse al menos una descripción de lo que hace, enlace para descargar el programa de su página oficial, arquitecturas soportadas, etc.
• TO_DO.md: documento con las mejoras que se desean incluir en un futuro sin plazo determinado.
  
• logo.png: icono identificativo de la aplicación que se mostrará en la descripción del proyecto si se sube a algún servicio de hospedaje de código gestionado por git, como github o gitlab.
  Se recomienda que sea cuadrado, no muy pesado ni grande, 256x256 pixels es una buena opción.
  
• LICENSE: licencia del programa, GNU GPL 3.
  

En el próximo capítulo veremos como funciona el script retroinstaller.sh en más profundidad.

Ampliando RetroMultiInstaller: carpetas principales (II)

Los próximos primeros viernes de cada mes voy a retomar el análisis de la herramienta que creé para agrupar todos los scripts de instalación que tengo y seleccionarlo con un sencillo menú.

Así cada uno podrá adaptar RetroMultiInstaller a sus necesidades.

Aunque en el anterior artículo ya comenté algo de la estructura interna del programa, en este voy a explicar los directorios esenciales que cuelgan de la carpeta donde descomprimos RMI.

En el directorio donde copiamos Multi-installer hay una serie de directorios que contienen otros directorios y archivos.
La estructura de directorios es la siguiente:

├── commonscripts
├── installers
├── menus
├── shotcuts
│   ├── etc
│   │   └── xdg
│   │       └── menus
│   │           └── applications-merged
│   ├── opt
│   └── usr
│       └── share
│           ├── applications
│           ├── desktop-directories
│           └── pixmaps
└── resources
└── warning
└──tmp

Analizando cada directorio con más detalle:

• commonscripts: aquí se incluyen todos los scripts de uso común y que llamaremos desde otros scripts.
• installers: aquí se incluyen los script de instalación, uno por cada programa.
• menus: son los archivos txt que contienen la definición de los menús.
  Cada archivo tiene la definición de un menú y cada línea de cada menú la definición de un programa a instalar o una categoría que abre un nuevo menú.
• shotcuts: incluye todos los archivos para crear los accesos directos con sus iconos y las categorías especiales para agruparlos.
  Dentro de este directorio hay una estructura de subdirectorios igual que donde se van a copiar los archivos en el sistema operativo.
  
• warning: incluye los archivos de texto con instrucciones u otra información que se mostrará al terminar la instalación del programa.
• tmp: carpeta donde se crearán los archivos temporales para las instalaciones tales como el código fuente antes de compilar e instalar.

Casi todos los scripts se ejecutarán desde esta carpeta, por lo que siempre deberemos referirnos a ellos con una ruta relativa que parte de esta carpeta.
Todos los archivos que contienen las carpetas installers, menus, shotcuts y warning correspondientes a un programa a instalar, contienen al principio de su nombre la etiqueta que identifica ese programa en minúsculas.

Ampliando RetroMultiInstaller: estructura interna (I)

RetroMultiInstaller es una colección de scripts que facilitan la instalación de programas en distros GNU/Linux de la familia Debian, éste va a ser el primero de varios artículos en el que vamos a aprender a ampliar esta aplicación para que instale también los programas que necesitemos y que aún no estén incluidos, incluso me podéis sugerir la inclusión de scripts de interés adjuntándolos junto a una descripción en la sección de issues.

El primer paso para conocer una nueva herramienta es saber algo de su estructura interna y eso es lo que vamos a tratar de ver hoy, RetroMultiInstaler está pensado para que podamos ver y entender que hacen los scripts aunque seamos novatos en el uso de los mismos, tratando que el código sea claro y comprensible.

Requisitos preliminares

Para usar RetroMultiInstaler necesitamos dos cosas:

• git para su descarga y mantenimiento.
• Que nuestro usuario esté autorizado en sudoers, es decir, que pueda ejecutar programas como administrador mediante la orden sudo.

También necesitaremos el paquete dialog para que pinte los menús, pero el propio script nos pedirá instalarlo en su primera ejecución si no está presente.

Descarga y actualización

Ya podemos descargar el script con toda su estructura con el comando:

git clone https://gitlab.com/cpcbegin/retromultiinstaller

Si ya lo tenemos descargado podemos actualizarlo a la última versión con el comando:

git pull

La actualización es fundamental antes de cambiar algo en el script.

Estructura interna

Estos son los archivos y carpetas principales que cuelgan de la carpeta que contiene el script

• retroinstaller.sh: script principal con el que ejecutamos la herramienta.
• opt: carpeta donde se generan los archivos y carpetas , todos los scripts se ejecutan desde esta ubicación y por tanto todas las rutas relativas deben componerse como si estuviéramos en este directorio. También es conveniente excluirlo del contol de git
• commonscripts: scripts que se usan en varios sitios.
• installers: contiene los scripts de instalación.
• menus: contiene los archivos con los menús, el principal es main.txt que llama al resto de menús ya que se pueden llamar unos a otros. Cada línea contiene una etiqueta índice un espacio y una descripción, dentro de la descripción puede haber espacios pero deben ser espacios duros.
• resources: diversos recursos incluidos en el script.
• shotcuts: archivos a copiar en la estructura del sistema.
• warning: archivos con texto de aviso al finalizar la instalación.
• README.md: Información sobre el software que se puede instalar.

La etiqueta índice del menú debe coinidir con el prefijo del script de instalación, cuyo nombre será indice_installer.sh

También es conveniente que se use en el nombre del resto de archivos del script para mantener la coherencia y facilitar el mantenimiento.   

Retromultiinstaller, para tener lo último en retro en tu GNU/Linux

Os presento Retromultiinstaller, un script que mediante un simple menú te permite instalar multitud de emuladores, aplicaciones LDraw para hacer tus propios Tentes y Legos virtuales, juegos, lenguajes/entornos de programación retro y cualquier cosa que le quieras añadir.

Lo puedes descargar con este enlace directo o mediante el comando:

git clone https://gitlab.com/cpcbegin/retromultiinstaller

Como puedes ver en las capturas es un menú basado en dialog similar al que trae retropie u otros scripts instaladores, aunque internamente es más fácil de modificar.

Los scripts te permiten instalar los programas desde el código fuente si está disponible y los deja con accesos directos en el menú para tener la última versión de la manera más accesible para el usuario novato.

Para los más avanzados verán que es muy fácil añadir más scripts, pues solo hay que modificar o añadir archivos de texto en la carpeta menus, organizados de una manera muy intuitiva. No es necesario ser un crack de bash y de la consola precisamente.

Es la fusión de tres proyectos que han ido creciendo en github hasta ahora y que ahora quedan en vía muerta:

• Tente 3D installer
• Amstrad Emulator Installer.
• Linux Emulator category.

A partir de ahora será Retromultiinstaller el que irá creciendo en sus posibilidades, además de pasar a gitlab que es un poco más de fiar que github.

Crear una nueva categoria en el menú de Ubuntu MATE (II): desde consola

Vamos a ver como crear una categoría de menú en Ubuntu MATE desde la consola, muy útil para hacer un script de instalación o inclusiones masivas/automáticas, por ejemplo.

Al lío.

1. Lo primero sería disponer de los iconos que vayamos a utilizar tanto para los lanzadores como para la categoría, si no queremos tener que poner la ruta completa deberían estar en /usr/share/pixmaps
2. Creamos los lanzadores en la carpeta ~/.local/share/applications/, podríamos crear uno para el emulador caprice que se llamara menulibre-caprice32.desktop con el siguiente contenido:
   

   [Desktop Entry]
Version=1.1
Type=Application
Name=Caprice32 (CPC emulator)
Name[es]=Caprice32 (emulador CPC)
Comment=Amstrad CPC/CPC+ emulator
Comment[es]=Emulador Amstrad CPC/CPC+
Icon=cpc6128
Exec=cap32
Actions=
Categories=menulibre-emuladores;

3. Creamos los directorios necesarios para la categoría:
   

   mkdir -p ~/.config/menus/applications-merged
mkdir -p  ~/.local/share/desktop-directories/

4. Creamos el archivo ~/.local/share/desktop-directories/menulibre-emuladores.directory con el siguiente contenido:
   

   [Desktop Entry]
Version=1.1
Type=Directory
Name=Emulators
Name[es]=Emuladores
Comment=Emulation and retrocomputing
Comment[es]=Emuladores y retroinformática
Icon=3disk

5. Creamos el archivo ~/.config/menus/applications-merged/user-menulibre-emuladores.menu como administrador con vim, leafpad o el editor que queramos con este contenido:
   

   <!DOCTYPE Menu PUBLIC "-//freedesktop//DTD Menu 1.0//EN"
    "http://www.freedesktop.org/standards/menu-spec/menu-1.0.dtd">
<!-- Do not edit manually - generated and managed by xdg-desktop-menu -->
<Menu>
    <Name>Applications</Name>
<Menu>
    <Name>menulibre-emuladores</Name>
    <Directory>menulibre-emuladores.directory</Directory>
    <Include>
        <Filename>menulibre-caprice32.desktop</Filename>
    </Include>
</Menu>
</Menu>

6. Si quieres incluir más elementos dentro de la categoría solo hay que repetir el bloque <Menu></Menu> interior con los datos correspondientes de cada lanzador.

Aprovecho esta investigación para que mi script de instalación de herramientas LDraw cree una nueva categoría de menú 'Tente y Lego 3D".


Posiblemente funcione con cualquier distro de la familia Debian y con otros entornos gráficos, en los comentarios podéis contarnos vuestras experiencias en este sentido.

Enlaces de interés

• How to create a new category in the GNOME menu?.
• Desktop entries (archwiki).