Una introducción a Dotfiles: cómo tomar el control de su entorno de desarrollo

Nota: Este es un artículo introductorio muy básico. Si ya conoce los fundamentos de la gestión de archivos dot, le recomiendo que lea mi segundo artículo.

Como desarrolladores, nos esforzamos por minimizar el tiempo que dedicamos a cosas redundantes, como configurar nuestro entorno, escribir código repetitivo y, básicamente, no hacer nada que no tenga que ver con la parte divertida de la codificación: crear cosas nuevas.

En este contexto, imagina un mundo perfecto donde los pequeños comandos llevan a cabo tareas increíblemente complejas adaptadas a tus necesidades, donde podrías comprar una nueva computadora portátil hoy e instalar todas las herramientas y paquetes que necesitas y configurar tu entorno de desarrollo con nada más que un par de terminales. comandos, y donde todo es mágico.

Este país de las hadas digital se puede hacer y con facilidad. Y hay un nombre para esta magia: dotfiles.

Sin más preámbulos, ¡descubramos los secretos de los archivos de puntos!

Introducción

Nota: Este artículo asume que está trabajando con un sistema operativo similar a Unix y se basa en gran medida en los comandos de terminal de Unix y los scripts de shell. Si no está familiarizado con estos, le recomiendo aprender los conceptos básicos y volver aquí. Aquí hay una introducción a las secuencias de comandos de shell.

En sistemas similares a UNIX, muchos archivos de configuración y similares están precedidos por un punto (.). Estos archivos están ocultos por el sistema operativo de forma predeterminada, e incluso el lscomando no revela su presencia (veremos cómo encontrar estos archivos en un momento). Dado que estos archivos están precedidos por un punto, se denominan dotfiles. Duh.

Entonces, ¿cómo encontramos estos archivos legendarios si están ocultos de forma predeterminada? Abre una terminal y haz esto:

Nota: El signo "$" no debe escribirse en la terminal. Representa el hecho de que el texto posterior se supone que debe escribirse en un indicador de terminal.
$ cd ~$ ls -a

Entonces que hace esto?

El primer comando ( cd ~) se mueve al directorio de inicio (el símbolo “~” representa el directorio de inicio). El directorio de inicio es donde se encuentran la mayoría de sus archivos de configuración. Entonces nos mudamos allí primero.

El segundo comando enumera los archivos y carpetas en el directorio actual. Pero hay algo de magia aquí. La -abandera indica al comando que incluya archivos ocultos en la lista.

¡Bingo! ¡Ahora podemos ver los archivos de puntos!

Modificar el .bash_profile

Por lo general, el primer archivo que la mayoría de la gente modifica cuando ingresa al mundo de los dotfiles es el .bash_profileo el .bashrc. Y por una buena razón. Este archivo se carga cuando inicia su terminal, y sus comandos se ejecutan al iniciar el terminal.

Una razón por la que podría querer modificar su .bash_profilees para personalizar el aspecto de su terminal (para ser específico, el indicador de su terminal). Esto es un arte y una ciencia en sí mismo y probablemente debería tener un libro completo dedicado a él, así que no cubriré mucho este tema en este artículo. Puede comenzar a personalizar su mensaje con este artículo.

En cambio, veamos dos construcciones de shell comunes que quizás se encuentran entre las partes más importantes y útiles de los archivos de puntos: los alias y las funciones.

Alias

Los alias son simplemente nombres cortos / acrónimos que puede asignar a una secuencia más larga de comandos para reducir el tiempo que tarda en escribirlos y así aumentar su velocidad. Por ejemplo, casi todos los desarrolladores usan git. Cualquiera que use la CLI de git (y seamos sinceros, debería usar la CLI de git), probablemente haya usado comandos largos como estos:

// commit changes$ git commit -m "some changes"
// push changes to the master branch of origin$ git push origin master

Estos comandos son bastante para escribir. Si cree que no lo son, cambiará de opinión después de comenzar a usar alias.

Escriba lo siguiente en el indicador de shell:

$ alias gpom="git push origin master"

Ahora cuando escribe gpom, git push origin masterse ejecuta! ¡Has pasado de 4 palabras a 4 letras ! ?

Pero hay un problema. Cierre su terminal, reinícielo y gpomvuelva a intentarlo . ¡Tu alias se ha ido! Esto se debe a que el alias está definido para la sesión de terminal actual.

Entonces, ¿cómo podemos solucionar esto y hacer que nuestros alias se mantengan?

¿Recuerda que hablamos de un archivo cuyos comandos se ejecutan cuando se inicia una terminal? ¡Bingo!

Agregue la siguiente línea a su .bash_profileo .bashrcy guárdelo:

alias gpom="git push origin master"

Ahora, cada vez que inicia una terminal bash, se crea el alias anterior. ¡La vida ya está empezando a ponerse increíble!

Nota: puede utilizar el nanoeditor de texto para editar sus archivos de texto. Cuando nano .bash_profileesté en el directorio de inicio, escriba para abrir el archivo usando nano, haga sus cambios y guarde el archivo presionando Ctrl+Xy luego ycuando se le solicite. Vimes otro editor de texto que puede utilizar.

Dado que los alias esencialmente reemplazan el comando completo, puede usar alias como parte de una herramienta CLI común de múltiples comandos como git para facilitar todos sus comandos. Solo agrega esto a tu .bash_profile:

alias g="git"

Y puede escribir "g" en lugar de "git" donde quiera usar "git". ¡Dulce!

A continuación, se muestran algunos alias comunes que quizás desee utilizar:

alias home="cd ~"alias ..='cd ..'alias '?=man'# Git CLI aliasesalias g="git"alias gi="git init"alias gra="git remote add"alias gs="git status"...# Aliases for NPMalias nr="npm run"alias ni="npm install"alias nid="npm install -D"...

Funciones

Los alias pueden contribuir en gran medida a mejorar nuestro flujo de trabajo, pero hay una cosa que no pueden hacer: trabajar con argumentos.

Digamos que estaba cansado de ejecutar dos comandos para crear un nuevo directorio y cdentrar en él:

$ mkdir new_folder$ cd new_folder

Y querías crear un alias para esto. Pero no puede, ya que ambos mkdiry cdtoman argumentos, y no puede pasar argumentos a alias.

So what now? Remember, there’s a super common programming construct that takes arguments? Yup, functions! Shell scripts can have functions that can take arguments. Awesome! If you’re a little rusty with functions in shell scripts, here’s a little reminder.

You can turn the above sequence into a shell function like this (this example was taken from the dotfiles of mathiasbynens, who has some of the most popular dotfiles around. Other people with excellent dotfiles to refer to are listed and linked to at the end of the article):

# Create a new directory and enter itfunction mkd() { mkdir -p "[email protected]" && cd "$_";}

Again, you can put this in your .bash_profile and the function will be accessible during any terminal session.

Nota: Tendrá que reiniciar su terminal para que se apliquen los cambios realizados .bash_profile. Si esto es una tarea, ejecute source .bash_profilepara agregar sus cambios a la sesión de terminal actual. Aún mejor, en el espíritu de los archivos punto, ¡crea un alias como alias reload="source .bash_profile"!

Dotfiles y uso compartido

¿Por qué la gente confía sus entornos de desarrollo, sus archivos punto, al control de versiones? ¿Por qué lo ponen en GitHub para que todos lo vean? La misma razón de siempre: para realizar un seguimiento de cómo evolucionan sus dotfiles con el tiempo y, lo más importante, para compartir sus dotfiles e inspirar a otras personas .

If you look at any mature dotfiles repo, you’ll realize that there are always snippets taken from other dotfiles repos and the like. They may even have multiple contributors and maintainers. We share dotfiles to collectively help each other build better environments and workflows.

This also allows people to use features of version control to make each others’ dotfiles better. One example of this is using the GitHub Issue Tracker to discuss issues and improvements.

I was inspired to work on my dotfiles from the dotfiles of pradyunsg, who has an impressive dotfiles repo of his own.

My own dotfiles are fairly basic and very immature right now, and they’ll get better over time. But this also means that beginners in the world of dotfiles will be less intimidated when they check the repo out.

Like many other people, I’ve added some support for customization of my dotfiles, so it might be a good idea for people who are new to the idea of dotfiles to fork the repo and try making it their own. More details in the repository. Do check them out and give me feedback!

Here’s a list of a people whose dotfiles are much more expansive and might inspire you:

  • pradyunsg
  • mathiasbynens
  • paulmillr
  • holman

Conclusion

These are the very fundamentals of creating your development environment using dotfiles. However, there is a lot more to this, which we’ll continue looking at in the next article in this series.

Some of the topics we’ll look at in the next article in the series are:

  • Creating an environment to organize, track and painlessly work with dotfiles
  • Splitting our dotfiles to make managing them easier and more scalable (notice it is dotfiles, not dotfile)
  • Writing scripts to setup (bootstrap) a new system with our dotfiles
  • Making our dotfiles easy to share by adding support for customization

That concludes the first part of the series on dotfiles! Here’s a link to the next one.

I loved the idea of dotfiles so much that it inspired me to create a basic dotfile management framework - autodot. The framework is in its infancy, so I’m looking for enthusiastic people who can give me feedback for the framework, contribute to it by telling me about bugs and making feature requests, and contribute to the code and documentation. Do take some time out for this! :)

ajmalsiddiqui/autodot

autodot - A dotfile management system that makes sharing your dotfiles easy while keeping you in the loop.github.com

Also, connect with me on GitHub and LinkedIn.

Good luck and Happy Coding! :)