#7 ¿Según tu cuales comandos si son bash y cuales no?
¿Sabes cómo puedes desinstalar cp, mkdir, cat, exec y los otros programas que usa sin desinstalar bash? ¿Sabes cómo puedes desinstalar netcat?
¿Por qué es eso? Porque cp, mkdir, cat y los otros programas que utiliza son o parte de bash y netcat es un paquete aparte. De hecho en ubuntu el paquete de netcat se llama 'netcat-openbsd'
Second example is a quick way to check if a port is open or not. You can always use netcat or telnet, but I find this easier.
Basicamente dice que usando /dev/tcp comprueba si existe un programa aceptando conexiones en un host y puerto determinado, pero después de soltar que lo hace así por que es mas fácil que con telnet o con nc, suelta la linea de comandos con la que lo hace:
#4 Efestivamente, y aunque sólo sea saber que puedes tener algo en /dev/ para hacer conexiones te puede salvar la situación en algunos Unix metidos en dispositivos extraños donde ni telnet tienes
#7 Luego vuelvo a leer el resto del artículo y veo que NO usa cp y mkdir de manera finalista, sino que los usa en unos ejemplos de expansión de argumentos, la técnica que utiliza vale para cualquier comando, el uso de cp y mkdir ahí es irrelevante.
Si usa cat y echo en los scripts, pero nuevamente, eso es parte del shell, están hasta en tu router y el unix más basico.
Si usa cat y echo en los scripts, pero nuevamente, eso es parte del shell, están hasta en tu router y el unix más basico.
cat es parte del 'shell'? de que shell exactamente. Si te refieres al interprete de comandos, no, no lo es. Si te refieres al emulador de terminal, no, no lo es. En todo caso entiendo que te refieres a que cat es un comando de LSB (Linux Standard Base):
Con todo el respeto del mundo, tu no sabes mucho de GNU/Linux. Bash es un interprete de comandos con un lenguaje de scripting. Normalmente el trabajo de bash es ejecutar otros programas informáticos que hay en tu sistema, y habitualmente la gente usa las funcionalidades de entrada/salida, variables y demás funcionalidades de bash, para conectar estos programas o extender sus funcionalidades.
¿Sabes cómo puedes desinstalar cp, mkdir, cat, exec y los otros programas que usa sin desinstalar bash?
Esta pregunta no tiene sentido. Eso depende tu sistema. Si te refieres a un sistema GNU/Linux, depende entonces de tu distribución, si es que usas una distribución y no has conseguido el software por tus medios. Entonces, la respuesta a esa pregunta es muy variada. Además el concepto 'instalar' y 'desinstalar' es un concepto abstracto que agregan los sistema de paquetería de las distribuciones.
En todo caso, la respuesta mas genérica posible a esa pregunta, sin entrar en distribuciones concretas o sistemas de paquetería, sería:
rm /bin/cp
rm /bin/mkdir
rm /bin/cat
Ojo, si haces rm /bin/rm luego no podrás seguir haciendo rm!
¿Sabes cómo puedes desinstalar netcat?
Pues de nuevo, no te voy a repetir todo lo que ya he dicho, así que:
rm /usr/bin/nc en mi caso.
¿Por qué es eso?
Por que es el que? He podido eliminar de mi sistema sin problemas a cp y a mkdir
Supongo que te refieres a que si lo hubiese intentando en, digamos, Ubuntu, con su sistema de paquetería especifico al intentar desinstalar uno u otro hubiese tenido problemas de dependencias.
Claro, pero tu entiendes que eso es una decisión del empaquetador de ubuntu verdad? GNU coreutils (de donde sale el programa cat que normalmente usas) NO es bash. Bash es un programa informático y GNU Coreutils otro proyecto diferente, con otro conjunto de programas informático.
El empaquetador de tu distrubición ha decidido que esos dos programas, deben estar relacionados en forma de dependencias, y que al quitar uno se debe quitar el otro. Pero eso es un asunto de tu distribución y no de bash, ni de coreutils
Porque cp, mkdir, cat y los otros programas que utiliza son o parte de bash y netcat es un paquete aparte
No, de nuevo: eso pasa por que así lo ha decidido el empaquetador de tu distribución de Linux cuando creó el paquete de coreutils y el de bash.
mkdir cp y cat NO SON parte de bash. Te paso algunos enlaces:
De hecho, sacado de la propia web del proyecto bash:
Command line editing
Unlimited size command history
Job Control
Shell Functions and Aliases
Indexed arrays of unlimited size
Integer arithmetic in any base from two to sixty-four
Como ves, bash no incluye 'basic commands' ni nada similar.
De hecho en ubuntu el paquete de netcat se llama 'netcat-openbsd'
en realidad eso es así por que historicamente han existido al menos dos implementaciones extendidas de netcat, la de openbsd y la que suelen llamar 'tradicional'. Por eso en apt-get tienes netcat-traditional y netcat-openbsd y un metapaquete llamado netcat, que creo que apunta al tradicional, si no recuerdo mal.
En serio, ubuntu ha ido muy bien para llevar Linux a la gente. Nadie te exige ser un experto en Linux ni nada similar, lo que no entiendo es como sin entender la mayoría de estos conceptos me contestas de esa forma
#10 Tienes razón en muchas cosas y en otras no tanto.
Sigo pensando que los ejemplos del artículo son válidos y no tiene mucho sentido usar netcat para poner ejemplos de cosas que se pueden hacer con bash.
Asumes los conceptos que entiendo y los que no arbitrariamente por una respuesta que te di que parece que te ofendió, te pido disculpas si es así. Traté de que fuera lo más simple posible. No tengo mucho tiempo para ponerme a buscar enlaces y revisar cosas que aprendí hace más de 20 años.
Pero en tu respuesta está basicamente lo que te he dicho antes, lo que infinitamente mejor explicado que lo que he hecho yo.
#11 no hombre, no me has ofendido. Lo que pasa es que he considerado oportuno aclarar bien este asunto y de forma contundente, para evitar que cualquiera interesado en el tema pueda pensar que cp es parte de bash o cosas similares.
Sólo me ha faltado que me aclares exactamente en que cosas no tengo razón, ya que sería muy constructivo de cara a entender mejor el asunto.
#12 Sí tienes razón con lo de mkdir, cp, rm. Son comandos que no pertenecen a bash y no hay una alternativa usando solo bash. Pero te enrocas en lo de usar nc cuando tirar de /dev/tcp es totalmente válido.
Prueba a hacer esto, create un script con bash usando /dev/tcp que haga un portscan y haz lo mismo pero con nc.
Te dejo los que yo he creado, y los tiempos de ejecución:
yo@nas:~$ cat bash-pscan.sh
echo "Scanning TCP ports..."
for p in
do
(echo >/dev/tcp/localhost/$p) >/dev/null 2>&1 && echo "$p open"
done
yo@nas:~$ cat nc-pscan.sh
echo "Scanning TCP ports..."
for p in
do
(nc -z localhost $p) >/dev/null 2>&1 && echo "$p open"
done
yo@nas:~$ time ./bash-pscan.sh
Scanning TCP ports...
21 open
22 open
80 open
139 open
445 open
real 0m1.775s
user 0m0.203s
sys 0m1.605s
yo@nas:~$ time ./nc-pscan.sh
Scanning TCP ports...
21 open
22 open
80 open
139 open
445 open
real 0m3.093s
user 0m0.708s
sys 0m2.387s
Como ves, el resultado es el mismo, pero con bash, al tirar directamente de funcionalidad de la shell y no de un programa externo es más rápido, ya que se están usando muchas menos llamadas al sistema.
#13 Yo no me he enrocado en nada. De hecho, de nuevo, tu comentario me está dando la razón. Lo que he dicho es que no es mas sencillo. En todo caso es igual. Y de eso me reía del comentario del autor, donde dice, y cito textualmente:
Second example is a quick way to check if a port is open or not. You can always use netcat or telnet, but I find this easier.
Que hacerlo con /dev/tcp es mas portable? Seguro, yo mismo lo he explicado.
Que hacerlo con /dev/tcp es mas rápido? Seguro, aunque seguramente haciendo:
nc -v -z host 1-1024 es igual de rápido o mas (no mucha gente sabe que netcat acepta rangos de puertos)
Que hacerlo con /dev/tcp es mas fácil? En absoluto, incluso diría mas complejo. Por ejemplo, mucha gente no lo conoce y tendrás que explicarlo. Eso como mínimo.
Me gustaría que me explicases donde me he 'enrocado', cuando lo que he hecho es el típico analisis ingenierístico del tema.
#14 Obviamente es más rápido si haces el nc por rango (incluso sería mucho más rapido si lo haces con nmap -p 1-1023 host), pero si lo haces así pierdes la posibilidad de tener un código de retorno por cada puerto, que es lo que está demostrando el autor en el script probando un puerto y manejando el código de retorno.
Digo que te enrocas porque veo que prefieres usar netcat y directamente rechazas otras formas, aunque también son válidas, y bueno, a tu criterio pueden ser más complejas, pero si te fijas lo que está haciendo es manejar /dev/tcp/host/port abriendo un descriptor de fichero (5), evalua que el comando exec ha retornado 0 y lo cierra. Pero fíjate en el ejemplo que puse yo en el comentario anterior, se puede saber el estado de un puerto haciendo un simple echo sin necesidad de andar abriendo descriptores de fichero, simplemente con un echo > /dev/tcp/host/port.
Yo podría llegar a concidir contigo en que el script que propone el autor tiene una complejidad añadida por el tema de abrir un descriptor de fichero y tal, pero el uso de las bash net redirections me parece apropiado en un post sobre bash.
En mi humilde opinión, en un curso de bash (o en un post de bash como es el caso), veo más correcto enseñar esto, ya que es una funcionalidad interna de bash. De cualquier forma nadie nace con el man de bash o netcat aprendido y con ambas formas se puede llegar al mismo resultado.
#15 yo también veo correcto enseñar eso, no veo correcto decir 'que es mas fácil'. Creo que genera una incorrecta visión de lo que es fácil, díficil, complejo, simple, mantenible, inmantenible, etc etc.
Creo que es mejor llamar las cosas por su nombre: mas portable, solución de emergencia, funcionalidad interesante, etc.
#1#2 De comprensión lectora parece andais un poco mal los dos.
Ha dicho que lo incluye en su .bashrc así que más que un script, es una función.
#3 El motivo de no usar netcat en este caso es que podría no estar instalado, por tanto en el bashrc le interesa que se a ser posible no haya que llamar a programas externos en la medida de lo posible. Desconozco en qeu entorno trabaja habitualmente.
Yo trabajo en uno en el que contar con bash es un lujo que en muchas ocasiones no me puedo permitir, ni lsof, ni netcat, ni en general ninguna herramienta moderna que no venga de serie con el sistema operativo. En algunos he instalado alguna herramienta del estilo, pero al final es más trabajo que el que me suele ahorrar instalarla.
![Trucos para BASH [ENG]](https://cdn.mnmstatic.net/cache/2a/b3/media_thumb_2x-link-2798502.jpeg?1499806802)
Comentarios
#7 ¿Según tu cuales comandos si son bash y cuales no?
¿Sabes cómo puedes desinstalar cp, mkdir, cat, exec y los otros programas que usa sin desinstalar bash? ¿Sabes cómo puedes desinstalar netcat?
¿Por qué es eso? Porque cp, mkdir, cat y los otros programas que utiliza son o parte de bash y netcat es un paquete aparte. De hecho en ubuntu el paquete de netcat se llama 'netcat-openbsd'
El tío suelta esto:
Second example is a quick way to check if a port is open or not. You can always use netcat or telnet, but I find this easier.
Basicamente dice que usando /dev/tcp comprueba si existe un programa aceptando conexiones en un host y puerto determinado, pero después de soltar que lo hace así por que es mas fácil que con telnet o con nc, suelta la linea de comandos con la que lo hace:
testPort()
exec 5/dev/$proto/$server/$port
(( $? == 0 )) && exec 5
#1 Es un script. Lo escribes una vez y luego lo llamas con testPort
Si lo usas mucho, sí que ahorra tiempo.
#2 ese script lo puedes crear igual usando netcat.
#3 La gracia de esto es que usa solo bash y no tira de programas externos como netcat, telnet, nmap...
#4 Efestivamente, y aunque sólo sea saber que puedes tener algo en /dev/ para hacer conexiones te puede salvar la situación en algunos Unix metidos en dispositivos extraños donde ni telnet tienes
#3 Eso en trucos para netcat daría el pego, pero si habla de bash no tiene sentido usar netcat.
#6 ah, claro, tienes razón! pero espera... dejame ver el resto del artículo
Vaya, usa los siguientes programas que no son bash:
cp, mkdir,cat
Esos si los puede usar pero netcat no puede? No lo entiendo.
#7 Luego vuelvo a leer el resto del artículo y veo que NO usa cp y mkdir de manera finalista, sino que los usa en unos ejemplos de expansión de argumentos, la técnica que utiliza vale para cualquier comando, el uso de cp y mkdir ahí es irrelevante.
Si usa cat y echo en los scripts, pero nuevamente, eso es parte del shell, están hasta en tu router y el unix más basico.
#9
Si usa cat y echo en los scripts, pero nuevamente, eso es parte del shell, están hasta en tu router y el unix más basico.
cat es parte del 'shell'? de que shell exactamente. Si te refieres al interprete de comandos, no, no lo es. Si te refieres al emulador de terminal, no, no lo es. En todo caso entiendo que te refieres a que cat es un comando de LSB (Linux Standard Base):
http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/command.html
Sin embargo, ese es un argumento raro, ya que bash en si mismo no está en LSB.
Además el autor dice que lo hace así por que le es mas fácil, no por que sea mas portable.
#7
Según tu cuales comandos si son bash y cuales no?
Con todo el respeto del mundo, tu no sabes mucho de GNU/Linux. Bash es un interprete de comandos con un lenguaje de scripting. Normalmente el trabajo de bash es ejecutar otros programas informáticos que hay en tu sistema, y habitualmente la gente usa las funcionalidades de entrada/salida, variables y demás funcionalidades de bash, para conectar estos programas o extender sus funcionalidades.
¿Sabes cómo puedes desinstalar cp, mkdir, cat, exec y los otros programas que usa sin desinstalar bash?
Esta pregunta no tiene sentido. Eso depende tu sistema. Si te refieres a un sistema GNU/Linux, depende entonces de tu distribución, si es que usas una distribución y no has conseguido el software por tus medios. Entonces, la respuesta a esa pregunta es muy variada. Además el concepto 'instalar' y 'desinstalar' es un concepto abstracto que agregan los sistema de paquetería de las distribuciones.
En todo caso, la respuesta mas genérica posible a esa pregunta, sin entrar en distribuciones concretas o sistemas de paquetería, sería:
rm /bin/cp
rm /bin/mkdir
rm /bin/cat
Ojo, si haces rm /bin/rm luego no podrás seguir haciendo rm!
¿Sabes cómo puedes desinstalar netcat?
Pues de nuevo, no te voy a repetir todo lo que ya he dicho, así que:
rm /usr/bin/nc en mi caso.
¿Por qué es eso?
Por que es el que? He podido eliminar de mi sistema sin problemas a cp y a mkdir
Supongo que te refieres a que si lo hubiese intentando en, digamos, Ubuntu, con su sistema de paquetería especifico al intentar desinstalar uno u otro hubiese tenido problemas de dependencias.
Claro, pero tu entiendes que eso es una decisión del empaquetador de ubuntu verdad? GNU coreutils (de donde sale el programa cat que normalmente usas) NO es bash. Bash es un programa informático y GNU Coreutils otro proyecto diferente, con otro conjunto de programas informático.
El empaquetador de tu distrubición ha decidido que esos dos programas, deben estar relacionados en forma de dependencias, y que al quitar uno se debe quitar el otro. Pero eso es un asunto de tu distribución y no de bash, ni de coreutils
Porque cp, mkdir, cat y los otros programas que utiliza son o parte de bash y netcat es un paquete aparte
No, de nuevo: eso pasa por que así lo ha decidido el empaquetador de tu distribución de Linux cuando creó el paquete de coreutils y el de bash.
mkdir cp y cat NO SON parte de bash. Te paso algunos enlaces:
http://www.gnu.org/software/coreutils/coreutils.html
https://www.gnu.org/software/bash/
De hecho, sacado de la propia web del proyecto bash:
Command line editing
Unlimited size command history
Job Control
Shell Functions and Aliases
Indexed arrays of unlimited size
Integer arithmetic in any base from two to sixty-four
Como ves, bash no incluye 'basic commands' ni nada similar.
De hecho en ubuntu el paquete de netcat se llama 'netcat-openbsd'
en realidad eso es así por que historicamente han existido al menos dos implementaciones extendidas de netcat, la de openbsd y la que suelen llamar 'tradicional'. Por eso en apt-get tienes netcat-traditional y netcat-openbsd y un metapaquete llamado netcat, que creo que apunta al tradicional, si no recuerdo mal.
En serio, ubuntu ha ido muy bien para llevar Linux a la gente. Nadie te exige ser un experto en Linux ni nada similar, lo que no entiendo es como sin entender la mayoría de estos conceptos me contestas de esa forma
#10 Tienes razón en muchas cosas y en otras no tanto.
Sigo pensando que los ejemplos del artículo son válidos y no tiene mucho sentido usar netcat para poner ejemplos de cosas que se pueden hacer con bash.
Asumes los conceptos que entiendo y los que no arbitrariamente por una respuesta que te di que parece que te ofendió, te pido disculpas si es así. Traté de que fuera lo más simple posible. No tengo mucho tiempo para ponerme a buscar enlaces y revisar cosas que aprendí hace más de 20 años.
Pero en tu respuesta está basicamente lo que te he dicho antes, lo que infinitamente mejor explicado que lo que he hecho yo.
#11 no hombre, no me has ofendido. Lo que pasa es que he considerado oportuno aclarar bien este asunto y de forma contundente, para evitar que cualquiera interesado en el tema pueda pensar que cp es parte de bash o cosas similares.
Sólo me ha faltado que me aclares exactamente en que cosas no tengo razón, ya que sería muy constructivo de cara a entender mejor el asunto.
#12 Sí tienes razón con lo de mkdir, cp, rm. Son comandos que no pertenecen a bash y no hay una alternativa usando solo bash. Pero te enrocas en lo de usar nc cuando tirar de /dev/tcp es totalmente válido.
Prueba a hacer esto, create un script con bash usando /dev/tcp que haga un portscan y haz lo mismo pero con nc.
Te dejo los que yo he creado, y los tiempos de ejecución:
yo@nas:~$ cat bash-pscan.sh
echo "Scanning TCP ports..."
for p in
do
(echo >/dev/tcp/localhost/$p) >/dev/null 2>&1 && echo "$p open"
done
yo@nas:~$ cat nc-pscan.sh
echo "Scanning TCP ports..."
for p in
do
(nc -z localhost $p) >/dev/null 2>&1 && echo "$p open"
done
yo@nas:~$ time ./bash-pscan.sh
Scanning TCP ports...
21 open
22 open
80 open
139 open
445 open
real 0m1.775s
user 0m0.203s
sys 0m1.605s
yo@nas:~$ time ./nc-pscan.sh
Scanning TCP ports...
21 open
22 open
80 open
139 open
445 open
real 0m3.093s
user 0m0.708s
sys 0m2.387s
Como ves, el resultado es el mismo, pero con bash, al tirar directamente de funcionalidad de la shell y no de un programa externo es más rápido, ya que se están usando muchas menos llamadas al sistema.
#13 Yo no me he enrocado en nada. De hecho, de nuevo, tu comentario me está dando la razón. Lo que he dicho es que no es mas sencillo. En todo caso es igual. Y de eso me reía del comentario del autor, donde dice, y cito textualmente:
Second example is a quick way to check if a port is open or not. You can always use netcat or telnet, but I find this easier.
Que hacerlo con /dev/tcp es mas portable? Seguro, yo mismo lo he explicado.
Que hacerlo con /dev/tcp es mas rápido? Seguro, aunque seguramente haciendo:
nc -v -z host 1-1024 es igual de rápido o mas (no mucha gente sabe que netcat acepta rangos de puertos)
Que hacerlo con /dev/tcp es mas fácil? En absoluto, incluso diría mas complejo. Por ejemplo, mucha gente no lo conoce y tendrás que explicarlo. Eso como mínimo.
Me gustaría que me explicases donde me he 'enrocado', cuando lo que he hecho es el típico analisis ingenierístico del tema.
#14 Obviamente es más rápido si haces el nc por rango (incluso sería mucho más rapido si lo haces con nmap -p 1-1023 host), pero si lo haces así pierdes la posibilidad de tener un código de retorno por cada puerto, que es lo que está demostrando el autor en el script probando un puerto y manejando el código de retorno.
Digo que te enrocas porque veo que prefieres usar netcat y directamente rechazas otras formas, aunque también son válidas, y bueno, a tu criterio pueden ser más complejas, pero si te fijas lo que está haciendo es manejar /dev/tcp/host/port abriendo un descriptor de fichero (5), evalua que el comando exec ha retornado 0 y lo cierra. Pero fíjate en el ejemplo que puse yo en el comentario anterior, se puede saber el estado de un puerto haciendo un simple echo sin necesidad de andar abriendo descriptores de fichero, simplemente con un echo > /dev/tcp/host/port.
Yo podría llegar a concidir contigo en que el script que propone el autor tiene una complejidad añadida por el tema de abrir un descriptor de fichero y tal, pero el uso de las bash net redirections me parece apropiado en un post sobre bash.
En mi humilde opinión, en un curso de bash (o en un post de bash como es el caso), veo más correcto enseñar esto, ya que es una funcionalidad interna de bash. De cualquier forma nadie nace con el man de bash o netcat aprendido y con ambas formas se puede llegar al mismo resultado.
#15 yo también veo correcto enseñar eso, no veo correcto decir 'que es mas fácil'. Creo que genera una incorrecta visión de lo que es fácil, díficil, complejo, simple, mantenible, inmantenible, etc etc.
Creo que es mejor llamar las cosas por su nombre: mas portable, solución de emergencia, funcionalidad interesante, etc.
#16 En eso estoy de acuerdo.
#1 #2 De comprensión lectora parece andais un poco mal los dos.
Ha dicho que lo incluye en su .bashrc así que más que un script, es una función.
#3 El motivo de no usar netcat en este caso es que podría no estar instalado, por tanto en el bashrc le interesa que se a ser posible no haya que llamar a programas externos en la medida de lo posible. Desconozco en qeu entorno trabaja habitualmente.
Yo trabajo en uno en el que contar con bash es un lujo que en muchas ocasiones no me puedo permitir, ni lsof, ni netcat, ni en general ninguna herramienta moderna que no venga de serie con el sistema operativo. En algunos he instalado alguna herramienta del estilo, pero al final es más trabajo que el que me suele ahorrar instalarla.