Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

328
Views
¿Existen inconvenientes en el uso de llamadas a system() en lugar de las funciones de su lenguaje de programación?

Estoy programando en C para crear una API para un dispositivo integrado. Este dispositivo integrado ejecuta una variante de Linux. No estoy muy familiarizado con C, estoy más familiarizado con shell scripting/bash.

Con eso en mente, cuando se trata de cosas como verificar si existe un directorio u obtener el uso del disco, me resulta más fácil simplemente hacer una llamada al system o popen y ejecutar mi comando, luego analizar la salida. Es más rápido para mí como desarrollador.

¿Hay inconvenientes en hacer estas llamadas al system y popen en lugar de descubrir cómo hacer cada una de estas cosas en C y luego hacer uso de las funciones de C?

over 4 years ago · Santiago Trujillo
3 answers
Answer question

0

Incluso si va a funcionar en Linux, no puede confiar en la disponibilidad de todos los comandos que pretende usar, por lo que la desventaja es sencilla: no puede confiar en que una herramienta determinada esté disponible .

Una cosa más a considerar es que analizar la salida de los comandos de shell desde c es terriblemente difícil.

Y finalmente, no puede hacer que su programa llame aleatoriamente a una utilidad del sistema o script de shell simplemente porque no es seguro.

over 4 years ago · Santiago Trujillo Report

0

Contras:

  1. es inseguro si hay entrada del usuario
  2. es difícil analizar la salida
  3. se basará en algo externo, como un script de shell.
  4. proceso pesado - bifurcación del sistema () e inicie el otro programa en paralelo

Ventajas:

  1. fácil de implementar
  2. depende del análisis de salida del programa podría ser muy fácil. system("ls -1");

resumir -

Depende de lo que tengas que hacer, pero en general hay más aspectos negativos que positivos.

over 4 years ago · Santiago Trujillo Report

0

Al final del día, en un sistema Linux, prácticamente todo está llamando a funciones C en algún momento.

Para tocar algunos de los argumentos en los comentarios, así como mis propios pensamientos:

  1. Ejecutar comandos de shell desde el programa ac, especialmente cuando se usan argumentos de usuario, es una vulnerabilidad potencial. Un ejemplo sería si permitiera al usuario llamar a su programa con el argumento "foo; rm -rf *"; dependiendo de cómo invoque el shell, existe la posibilidad de que pueda llamar efectivamente a "mkdir foo; rm -rf *" si desea crear el directorio que proporcionó el usuario. Esto puede o no ser un gran problema dependiendo de cómo confíes en tus usuarios, etc.
  2. La ejecución de comandos de shell conduce a posibles condiciones de carrera que no puede evitar y que podrían tratarse más fácilmente mediante llamadas directas al sistema que encadena.
  3. Analizar la salida de los comandos significa lidiar con más operaciones de cadenas en C, lo cual es menos que divertido.
  4. Si realmente prefiere bash, su mejor apuesta probablemente sea implementar pequeños programas que envuelvan porciones discretas de la API C de su biblioteca de destino. Esta es la forma UNIX (tm) de todos modos.

EDITAR para abordar el comentario de Pimgd: tenga en cuenta que las condiciones de carrera son un dolor de cabeza y muchas de ellas no son necesariamente un problema para su caso de uso particular, pero al menos vale la pena considerarlas al sopesar los pros y los contras. De todos modos, las instancias específicas de condición de carrera en las que estaba pensando incluyen (y es probable que haya otras clases):

  1. Condiciones de carrera tipo seguridad. Si crea un archivo temporal que contiene un conjunto de comandos y luego lo ejecuta, existe la posibilidad de que entre la creación y la ejecución, alguien ingrese y modifique el archivo. (En realidad, hay una variedad de variaciones en este tema para cosas como configurar/restablecer enlaces simbólicos, etc.). Según sus comentarios anteriores, esto está bastante fuera del alcance de su proyecto, pero es algo que debe tener en cuenta para otras aplicaciones.
  2. Condiciones de carrera multiproceso. El ejemplo más simple que se me ocurre es lo que sucede si dos instancias de su programa desean configurar un archivo de configuración y se ejecutan al mismo tiempo. Hay ciertas llamadas al sistema operativo que tienen ciertos niveles de garantía de atomicidad, pero se pierde mucho si llama a una serie de comandos de shell para escribir en el archivo. (Tenga en cuenta que incluso si lo hace desde una aplicación C monolítica en lugar de una serie de comandos de shell, aún necesitaría hacer algo adicional para evitar que la instancia 1 sobrescriba el cambio de la instancia 2, pero al menos no es probable que se encuentre con el caso de que termine teniendo cambios entremezclados. Como ejemplo, considere:

    ARCHIVO *fp = fopen("config.txt","wt");

    fprintf(fp,"Valor de configuración 1: %s",config[0]);

    fprintf(fp,"Valor de configuración 2: %s",config[1]);

    fflush(fp);

    fcerrar(fp);

contra

 system("echo Config value 1: `df | awk '{print $1}'` > config.txt"); system("echo Config value 2: `ps | grep foo | awk '{print $2}'` >> config.txt");

Donde, si dos instancias del programa se ejecutan casi a la hora exacta, puede terminar con, por ejemplo, 2 instancias del valor de configuración 2 en el archivo de configuración en el último caso.

over 4 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!