Me preguntaba cual es el comando y la sintasis para poder abrir un programa externo programando en C.
Es decir q en cualquier momento meta el comando y pueda abrir el iexplorer con la pagina del google por ejemplo u otra q yo le diga al programa, por lo tanto el comando q se, debe llevar parametros.
Muxas gracias.
PD: quizas como C es de msdos, pues no pueda abrir programas en windows, si alguien sabe como es el visual basic, por favor q me lo diga tb, gracias
No es un comando, es una sentencia, y probablemente no sea de C, sino una llamada del sistema operativo (en este caso, Windows).
Las llamadas POSIX, por si te interesa, son fork y exec. Para dudas, pregunta al man.
PD: C no es de ningún sistema operativo, las llamadas al sistema sí lo son. En Visual Basic, creo recordar que era "Shell", pero hace milenios que no toco VB.
Poco haras con el ms-dos cutre de Micro$oft 
(Ade+ que no le veo el interes cuando con un par de clicks lo harias = ) Si quieres un prompt (consola de comandos) de verdad tendras que pasarte a UNIX.
Y los unixeros siguen ignorando el potencial de la consola de comandos de Windows XP (y 2000 y NT con Option Pack)... y los scripts administrativos en cualquier lenguaje de scripting con soporte para WSH (VBScript, JScript, Perl, Python...) que permiten hacer absolutamente todo con el Windows, pero que taaaaaanta gente desconoce... aish...
#5 Absolutamente todo lo que Windows te permite, que no es demasiado. La shell de Windows es patética: ni completion, ni piping, ni bg/fg... La shell que programé en menos de una semana para una práctica de SSOO es más versátil que la de Windows.
Por cierto, te fallan un poco los conceptos, una cosa es shell scripting (programación de bash, ksh, tcsh... en Windows es .bat) y otra cosa son "scripts" de lenguajes interpretados (los que has mencionado). Me parece que has mezclado churras con merinas, ya que nadie ha hablado de ellos.
PS: La velocidad de Perl en Windows es horrorosa.
#7 Es verdad, acabo de comprobarlo, pero es un completion en pañales. Sólo te lo hace de ficheros, no de mandatos (aunque sean ficheros ejecutables que se encuentren en el path).
Ahora que miro también hay un atisbo de piping, pero tampoco parece muy útil ya que no hay (o no conozco) programas que lean de stdin texto bruto. Probaré con Perl cuando tenga tiempo.
No se si es esto lo que pides, a ver si te ayuda:
http://www.media-vida.net/vertema.php?tid=99171
(si, me aburria mucho y tenía mucho tiempo libre)
#8 No hay demasiados programas que lean de stdin porque es una cosa antigua y bastante fea... Teniendo bonitos scripts en VBScript y similares (que vienen a ser lo mismo que los scripts de bash y compañía, pero más fáciles de hacer y con acceso a absolutamente todo... hasta puedes controlar programas en cualquier ordenador de la red muy fácilmente...).
En un mundo de componentes distribuidos, servicios web y demás... ¿quién necesita leer de stdin? O_o
Se pueden ejecutar vbs, js y demás con parámetros de entrada desde línea de comandos... ¿me puede explicar usted en qué se diferencia un script de este tipo de un script de shell de unix? Además de la facilidad del primero jeje
No hay demasiados programas que lean de stdin porque es una cosa antigua y bastante fea...
Falacia nº1: "antigua"
Algo antiguo no es malo. Unix es antiguo. Y sistemas Unix son los que se encuentran en el 95% de servidores y clústeres de alto rendimiento. Sólo tienes que echar un vistazo a www.top500.org
Falacia nº2: "bastante fea"
Por favor, no lances juicios de valor. A mí me parece que posee una belleza matemática increíble. Estudia las máquinas de Turing si no lo has hecho ya, quizá cambies de opinión.
Ahora te digo: maneja de expresiones regulares y tiras de caracteres, parsing en general, en VBS o JS con la misma facilidad y eficiencia que bash + awk + grep + sed (+ el programa que se te ocurra, porque al final es eso...). Lo único que conozco que se le acerca es Perl.
pero más fáciles de hacer y con acceso a absolutamente todo... hasta puedes controlar programas en cualquier ordenador de la red muy fácilmente...
Falacia nº3: "más fáciles de hacer"
Otro juicio de valor.
"Acceso a absolutamente todo"
A todo lo que Windows te deja acceder. Por poner un ejemplo extremo, haz un VBS o JS que te particione un disco en varios trozos, no hace falta ni que tengan sistema de ficheros. Esto en bash es una línea (y no demasiado larga).
O si quieres, haz un sniffer de un interfaz de red que te vuelque a un fichero la metainformación de todos los paquetes ACK al puerto TCP 80 durante 30 segundos, y al acabar, te mande el resultado por mail. En bash, y con programas externos, puedes hacerlo con una sola línea.
En un mundo de componentes distribuidos, servicios web y demás... ¿quién necesita leer de stdin? O_o
En un mundo con componentes distribuídos, servicios web y demás... ¿Quién necesita IPC? Porque stdin no deja de ser un pipe, que es la base del IPC local en Unix (que casualmente, es el tipo de sistemas operativos que más frecuentemente suelen correr componentes distribuídos y blablabla).
(Nótese la ironía)
Se pueden ejecutar vbs, js y demás con parámetros de entrada desde línea de comandos... ¿me puede explicar usted en qué se diferencia un script de este tipo de un script de shell de unix? Además de la facilidad del primero jeje
Obviando el nuevo juicio de valor (que además es irrelevante) sólo he de decir:
La base de un shell script es la ejecución de programas externos, la de un script es su interpretación y ejecución.
A partir de ahí ya puedes deducir (o eso espero) que los objetivos son distintos.
PS: No sé si te he entendido mal, pero creo que confundes stdin con argumentos de entrada.
PS2: Si quieres continuamos la discusión en privado.
