¿Cáscara? ¿Un lenguaje de programación? ¡Relajarse! ¡Son ambos!

Cada vez que publicamos un truco de Linux que usa un script de shell, alguien considerará lo horrible que es programar scripts de shell. Si bien nos gusta la ubicuidad y la eficiencia, no podemos negar que el caparazón es un poco pirata en sí mismo. [Axel Lijencrantz] quiere cambiar su shell para que sea un lenguaje de programación completo llamado Crush.

En la cara parece una concha. ¿Quiere ver el contenido del directorio actual? Sencillo: ls.

La diferencia está por debajo. En Crush, ls está integrado y devuelve datos en filas como una base de datos. Puede manipular esta base de datos con comandos similares a SQL: ls | where {type=="directory"}.

Aún puede tratar las E / S como corrientes binarias. Pero Crush también conoce archivos CSV, JSON, archivos orientados a líneas y varios otros formatos. Entonces, si intenta proporcionar el resultado de ls a un programa y lo necesita en formato JSON, eso es simple: ls | json:to ./listing.json.

Crush también puede hacer matemáticas sin recurrir a trucos como shells antiguos o una sintaxis extraña como bash. El shell admite cierres que puede asignar a una variable para hacer lo que equivale a una función. Otra característica bienvenida es que Crush comprende la idea de los espacios de nombres.

Hay algunas cosas raras para usar % como un bromista en cambio * porque el * es para multiplicar. Sin embargo, nos gustan muchas funciones, incluida la ejecución remota simplificada y la capacidad de crear tipos personalizados.

Crush es similar a Nu, pero tiene algunos propósitos diferentes en relación con los lenguajes de programación. Si todavía está escribiendo programas en shells tradicionales como bash, asegúrese de ejecutar linter.

  • Ostraco dice:

    "Cada vez que publicamos un truco de Linux que utiliza un script de shell, alguien pensará en lo horrible que es programar scripts de shell".

    Considérelo un incentivo no hacer guiones largos donde lo haría un programa.

    • X dice:

      Sí, exactamente, ¿quién necesita un script de shell simple, cuando en su lugar puede proporcionar un proyecto de eclipse completo y todas sus dependencias, por qué no lanzar los digitales para el compilador y el enlace para todas las diferentes plataformas para estar seguro?

      • Gravis dice:

        Umm ... ¿sabes sobre C ahora?

        • Gravis dice:

          No *

        • Steven Clark dice:

          Suele utilizar scripts de shell para procesar texto y flujos de salida que probablemente sean más seguros en cualquier lugar que C.

      • cyberzerocool dice:

        Eso suena mal. Simplemente use AutoIt en Windows o maneje bash en Linux A O ...
        ¡Utilice NodeJS para cualquiera!
        consulte ConsultingJoe para ver algunos de los códigos de NodeJS

        • cyberzerocool dice:

          O supongo que Power Shell en Windows. Blah ..

          • notmyfault2000 dice:

            ¿Qué pasa con Power Shell en Linux?

          • Bert dice:

            Power Shell sigue siendo de la época en que Microsoft pensaba que dominaba el mundo del software.

            En retrospectiva, MSFT podría retrasar su caída con un Python3 elegido en lugar de crear un "Power Shell".

        • Dan dice:

          como alguien que escribe nodos con regularidad, no lo use para cosas simples. Nodejs tiene su propia dependencia especial, y cuando no es así, tiene que instalar medio npm para realizar tareas simples.

          • cyberzerocool dice:

            Como alguien que también escribe nodos con regularidad, sigue siendo un lenguaje de secuencias de comandos. Es perfecto para cosas pequeñas o en escala.
            Npm es mucho más rápido que copiar node_modules.
            Sí, si necesitas una expresión, entonces. Espera unos segundos y el tuyo.

        • kc8rwr dice:

          "Solo use AutoIt en Windows"

          Bien, cuando en Windows.

          "O trata a bash en Linux"

          ¿Leíste el artículo en absoluto?

          "A ... ... ¡Usa NodeJS para cualquiera!"

          ¿Qué drogas tomas?

          No me gustaba JavaScript cuando se usaba solo en páginas web.

          JavaScript comenzó como un lenguaje de juguete para llenar un espacio en blanco con animaciones cuando alguien no podía encontrar suficiente contenido efectivo para su página de inicio personal inútil. Luego se construyó para algo más cuando las personas se dieron cuenta de que necesitaban hacer una programación real para impulsar el lado del cliente en un sitio web.

          Entonces, el resultado es un lenguaje donde la clase es una función y el método es una expresión lambda dentro de una función. Eso es ridículo.

          Y todavía TENEMOS que usarlo si queremos que algo se ejecute en el lado del cliente en un navegador web, porque eso es compatible con los navegadores web.

          ¿Pero NodeJS? ¿Por qué existe eso? ¿Por qué alguien querría tomar esa pila humeante de estiércol, que es JavaScript, y usarla en cualquier lugar que no necesite?

          • cyberzerocool dice:

            Jaja, bueno, esa pila Steaming paga mis facturas. Soy un ingeniero de software de JavaScript y es bueno programar y poderoso. Diviértete compilando mientras mi código ya se está ejecutando. Jajaja

          • kc8rwr dice:

            @cyberzerocool Hay muchos lenguajes interpretados donde clase es clase y método se construye como método en lugar de variable. ¡El hecho de que un idioma no se cumpla no significa que tenga que tener muerte cerebral!

      • Kelly Clowers dice:

        De hecho, hay una variedad de opciones entre un proyecto Java completo y un script de shell.

      • lthemick dice:

        O use Perl. O Python. O Java sin un entorno de desarrollo que obliga a una estructura de proyecto demasiado complicada.

        Muchas, muchas opciones entre el script de shell y las complejidades de Eclipse.

    • Kelly Clowers dice:

      Protip: el guión es un programa

    • Moe dice:

      Python no es adecuado como reemplazo de shell. Carece de funcionalidades básicas para ser el único. ¿Cómo escribirías una sola línea en Python cuando necesitas administrar las sangrías? Solo un script básico en Python debería tener una condición de ruido para que sea útil como cargable y ejecutable al mismo tiempo.

      No debe tener experiencia con CLI para ofrecer Python como reemplazo de shell.

  • X dice:

    Sea lo que sea, las carcasas ordinarias también contienen una carpeta incorporada, con resultados disponibles para tuberías. Por ejemplo: eoo *

    Y es extraño que la sintaxis de bash se considere extraña, pero usar llaves y == para representar una condición SQL no lo es ???

    ¡Guau! ¡Cierres! ¡Como si no pudieras controlar los comandos de shell con comillas inversas! Como si no hubiera reemplazos variables. ¡Como si los comandos find y xargs no existieran! Y todo esto solo para reemplazar una sintaxis extraña con otra sintaxis extraña, sin características reales agregadas.

    • Kelly Clowers dice:

      no se trata de agregar funciones, se trata de una sintaxis prudente y un modelo de programación menos erróneo y delicado

      • X dice:

        ¿Usar% como operador comercial es más "prudente"? Poner {} alrededor de expresiones SQL es "menos complicado" ???

        ¿Qué "errores" evitas ??? Sólo curioso. ¿Cuántos errores hay en su "caparazón" y cómo los evitamos?

        • lthemick dice:

          Esto parece admitir la sintaxis SQL, donde% * es * el carácter comercial; si admite expresiones SQL, tiene sentido seguir con la sintaxis SQL.

  • Moryc dice:

    "Completo" básicamente significa "te soplará en la cara" ...

    Los lenguajes de programación bien establecidos, como Python, pueden realizar llamadas al sistema, leer y escribir archivos o directorios, y hacer todas las cosas que puede hacer un shell. No hay soluciones como "% como un bromista". Y no utilizan "comandos similares a SQL" porque, por lo general, también hablan SQL. Y JSON. Y CSV. Y cualquier otro formato (incluidos algunos, del que Ilve nunca había oído hablar antes, probablemente) ...

    También miembro, ¿cuándo los scripts de shell solían depender de errores en los comandos que los hacían inmortales? "Miembro, ¿cuándo los administradores pasaron más tiempo luchando con estos errores en sus scripts que produciendo realmente? Bash era un gran nombre para la corteza en el día, porque después de trabajar un poco con ella, querían golpearse la cabeza contra un escritorio o una pared ...

    • X dice:

      Ah, sí, las computadoras eran perfectas entonces, bash era el único programa con errores. Los compiladores generaban un código perfecto y el hardware nunca fallaba. Sería el nirvana sin ese estúpido programa de bash.

      • Moryc dice:

        Los compiladores generaron un código perfecto: hicieron lo que escribió un programador, no lo que un programador quería que hiciera. Aparte de que bash no era la única aplicación con errores, también teníamos sendmail que no podía enviar correo de manera confiable (y actuaba como un perro masticando el correo hasta que los sobres y el contenido se integraron en un lío pegajoso), una cosa de X-Window que usó todos los medios del hardware para mostrar un reloj en la pantalla (porque fue escrito por nitwits), NFS (Networked File System), que no entendía redes, archivos y sistemas, etc.

        • aki009 dice:

          "Los compiladores generaron un código perfecto: hicieron lo que un programador escribió, no lo que un programador quería que hiciera".

          Uno para el muro de cotizaciones.

  • Tostadora_ Pollo dice:

    ¿Por qué no PowerShell? Diría que se trata más de un lenguaje de programación que de un shell, pero sigue siendo un shell completamente desmenuzado.

    Conceptualmente es lo mismo, pero las llamadas devuelven "objetos" o, en algunos casos, son objetos, lo cual es mucho más programáticamente lingüístico que cualquier cosa devuelta como una fila SQL o un objeto json. También puede aprovechar .Net (y, aparentemente, Core en Linux) desde PowerShell para obtener todo tipo de problemas divertidos.

    No me importa si es EM, realmente me gusta PowerShell.

    • calcetín dice:

      Fue lo primero que pensé; PowerShell parte del modelo de intercambio de datos, que básicamente raspa la salida de texto de cada comando. Mi único problema es que algunas características vienen como un objeto XML que debe buscar con XPath para el atributo requerido. Pero al menos no tengo que preocuparme por nombres de archivo extraños, citar o convertir marcas de tiempo.

      • X dice:

        ¿Cómo no tiene que "preocuparse" por una cotización en Powershell? Funciona como un caparazón:

        "Cuando inserta una cadena entre comillas dobles (una cadena entre comillas dobles), los nombres de variables precedidos por un signo de dólar ($) se reemplazan por el valor de la variable antes de que la cadena pase al comando para su procesamiento".

        "Para evitar la en lugar de un valor variable en una cadena entre comillas dobles, utilice el carácter de retroceso (`) (ASCII 96), que es la marca de escape de PowerShell. "

        Citar en Powershell es casi idéntico a citar en bash. ¿Estás hablando de WTF?

    • Erik Johansson dice:

      Es demasiado prolijo y tiene un caparazón realmente malo (es decir, nih, y no lo uso) que dice que esta herramienta está inspirada en Powershell. Puedes leer más sobre por qué no en Crush Questions. No estoy seguro de que este sea el camino a seguir, principalmente porque creo que los scripts de Powershell pueden ser una de las peores cosas que se pueden encontrar, creo que es comparable al Perl de Windows. Las personas inconscientes como yo escriben miles de líneas y esperan que otras personas simplemente lo entiendan.

      Dicho esto, ciertamente hay algunos trucos agradables que se pueden hacer, siempre que sean claros como el cristal.

    • Jeffrey Rennie dice:

      También me gusta PowerShell y lo uso en Windows, Mac y Linux.

      > Conceptualmente es lo mismo, pero las llamadas devuelven "objetos"

      ¡Ha despertado la orientación de objeto opuesta! Aunque teóricamente exacto, la mayor parte de mi código de PowerShell consume texto y produce texto; por ejemplo, a menudo `yadayada | grep yadayada` en PowerShell.

  • Knut Uten dice:

    Cualquiera que se queje de los scripts de shell debería verse obligado a utilizar una máquina basada en z80 con una grabadora para hacer su "trabajo" durante un tiempo. Sé con certeza que hay exterminadores que tienen antenas proyectadas con la ayuda de zx81. Así que tu teléfono es una supercomputadora muy loca. La sintaxis del shell es extraña porque no la usas.

    • Rogfanther dice:

      +1

    • Al Williams dice:

      ¿Tenías una cinta? Hubiéramos matado por una cinta. Tuvimos que usar tarjetas perforadas que solo se podían perforar con un cincel y un martillo de 12 libras para hacer los 1 y 0. (Por supuesto, alguien responderá: ¿tenía uno? ¡Tuvimos que programar usando solo 0!)

      • Moryc dice:

        Esto es lo que sucede cuando su computadora fue creada en Atlantis, impulsada por vapor, programada con tarjetas de hoja.

        • RW versión 0.0.3 dice:

          En el pasado, tenían computadoras de silicio, a pesar de que el silicio eran grandes bolas de roca. Huyeron de la luz del sol o de las estrellas. La programación puede haber tomado la forma de palos accesorios y cuerdas anudadas, movidas y sostenidas por ayudantes.

          La evidencia muestra que las culturas antiguas sabían que el sistema solar era heliocéntrico y rastrearon todos los planetas principales. También sabían lo que no es un planeta ... y lo que eso podría significar.

          Uno de los mayores logros de la humanidad no fue más allá de los límites de lo posible, fue la supervivencia intencional de la extinción del Dryas más joven, mediante la predicción de la colisión de un cometa y la preparación para ella. Por supuesto, el número de muertos seguía siendo enorme, y literalmente arrojó a todos a la Edad de Piedra.

  • Brian dice:

    Realmente me gustan las cosas de Al Williams. Realmente me gusta Linux; bueno, lo que realmente me gusta es Slackware. Realmente me gusta BASH; pero mi verdadero amor es C.

    Pero a veces me pregunto si la gente de HaD a veces "canaliza" a Brian Benchoff para animarlo un poco. ¿Un caparazón limitado en Rust?

    • zombi dice:

      > pero mi verdadero amor es C.

      Usar '#! / ... / bin / tcc -run 'al script?

      • Al Williams dice:

        https://la-tecnologia.com/2019/09/17/linux-fu-shell-scripts-in-cc-and-others/

    • X dice:

      Tienes que amar el lenguaje informático que la gente no puede usar de manera segura y confiable, es como admirar un virus de peste o un terremoto catastrófico.

      • RW versión 0.0.1 dice:

        C es un fuego ...

  • Miroslav Cika dice:

    Te puede gustar esto:
    https://en.m.wikipedia.org/wiki/C_shell

    En cuanto a los espíritus del querido BB, siempre es fácil animar a los espíritus afirmando que uno es mejor que el otro: Windows versus Linux versus Mac, usted versus Emacs, CLI versus GUI y muchos otros que no puedo mencionar. aquí debido a una tendencia al bloqueo en los últimos meses.

  • Richard Lucas dice:

    Lo que. La gente hace todo tipo de cosas porque les divierte. No veo el sentido de un "nuevo" lenguaje cuando PHP y Python hacen scripts de shebang completamente buenos. Literalmente, no faltan intérpretes para hacer las cosas. Estas cosas a menudo me entristecen porque me hacen pensar que las personas realmente inteligentes simplemente están perdiendo debido a una enfermedad abstracta. Puede haber una buena razón para reinventar la rueda una y otra vez, pero honestamente, me parece una pluma de pavo real intelectual. El "por qué" está en el "mírame, soy programador". Meh.

  • atbillp37 dice:

    Un tamaño de software demasiado grande [> ~60 lines of code] ¿Qué pasa con un certificado de seguridad del programa?
    ¿Número NTSB también? ¿Los estándares de ingeniería de Boeing limitaron el tamaño de un módulo a una página o menos desde antes? 1966 hasta al menos 1980. ¿Linux Mint en el software de control de vuelo 737 MAX? ¡Intentemos averiguarlo! http://www.prosefights.org/irp2020/windscammers12.htm#faalawsuit1

  • AndyPanda dice:

    Siempre me encanta la cita de que * NIX es un montón de pequeños programas junto con cinta de paquete, también conocidos como scripts

    • X dice:

      Me encanta cuando la gente piensa que los programas Unix son pequeños, como si no supieran qué tan grandes son las bibliotecas estándar, parece que no tienen evidencia de que printf () sea una pieza de código realmente enorme.

      También me encanta cuando la gente piensa que los scripts de shell son cosas "simples" que merecen ser llamadas "cinta adhesiva" cuando en realidad puedes escribir programas completos en ellos.

      • AndyPanda dice:

        Soy AndyPanda, un dibujo animado, mírame ...
        Sí, las bibliotecas son enormes, pero el código es una página requerida
        repasemos con la cinta, yo no inventé eso, ha pasado un tiempo
        cualquiera que quiera llegar a UNIX tendrá que lidiar conmigo

        • Ostraco dice:

          Unix Haters Handbook ya está hecho.

    • Troepje dice:

      Sí, eso necesita una putrefacción adecuada en una base estándar simple utilizable y flexible y como quiera el usuario. Todo el mundo sabe que una talla sirve para todos ...

    • Michael Black dice:

      Pensé que no se trataba mucho de tamaño, sino de función.

      Pequeños programas que hacían una cosa, a veces algunas cosas, pero añadían, a veces mediante un script, se podía hacer mucho.

      Cal. Es una utilidad realmente útil si necesita mostrar un calendario. La apariencia es excelente para revisar la ortografía de una palabra. Y así.

      Incluso en la era de la interfaz gráfica de usuario, muchos programas de interfaz gráfica de usuario de Linux son solo shells para ejecutar programas de línea de comandos existentes.

      Esto es comparable a Word, o Emacs, que están tratando de hacer eso. Lotes en un paquete.

  • X dice:

    Una forma de perder el sentido del caparazón es que los datos enterrados no tienen estructura con respecto al caparazón y sus herramientas. Herramientas como grep y sort y uniq y tr y cat, ninguna de ellas se preocupa por la estructura de sus datos y, sin embargo, aún pueden trabajar con sus datos. No hay diferencia entre flujo y tabla y comando, todos son solo flujos de caracteres y todos pueden ser operados por las mismas funciones.

  • Joel dice:

    Personalmente, he encontrado que los scripts Bash son bastante necesarios a lo largo de los años, ya que el análisis de datos simple y las tareas automatizadas de preparación de programación / construcción son su principal caso de uso para mí. El shell Wait (tcl) tiene una función similar para instalaciones de implementación remota, duplicación y taps de diagnóstico.

    No creo que me gustaría depurar un conjunto de comandos de canal con expresiones regulares complejas en un lenguaje como Python. Porque Python requiere muchas dependencias incluso para cargar y algo de tiempo para ejecutar el intérprete de tamaño completo. Cuando veo el script de estadísticas de Python del equipo juvenil fijando los núcleos al 100% en un estado de reposo ... me recuerda que a menudo no es un bucle ocupado ... sino el planeador trasero agresivo de Python y una falta fundamental de soporte de subprocesos (o control de proceso "agradable") ... jugar con el planificador central de formas a menudo imperdonables, y no es culpa de los niños por no saber por qué eso importa todavía.

    Los lenguajes de script de shell pequeños son simples por una razón ... al mismo tiempo, los scripts a menudo se pueden cargar, ejecutar y luego salir más rápido que una versión C compilada usando llamadas al sistema. Creo que Lua fue uno de los pocos idiomas que unió estos usos bastante bien, pero eso es raro en otros idiomas (incluso Perl).

  • leopardo dice:

    Felicitaciones, acaba de reinventar perl.

Maya Lorenzo
Maya Lorenzo

Deja una respuesta

Tu dirección de correo electrónico no será publicada.