He escrito un script que funciona bien cuando se ejecuta localmente:
./sysMole -time Aug 18 18
Los argumentos "-time" , "Aug" , "18" y "18" se pasan con éxito al script.
Ahora, este script está diseñado para ejecutarse en una máquina remota, pero desde un directorio local en la máquina local. Ejemplo:
ssh root@remoteServer "bash -s" < /var/www/html/ops1/sysMole
Eso también funciona bien. Pero el problema surge cuando trato de incluir esos argumentos antes mencionados (-tiempo 18-18 de agosto) , por ejemplo:
ssh root@remoteServer "bash -s" < /var/www/html/ops1/sysMole -time Aug 18 18
Después de ejecutar ese script me sale el siguiente error:
bash: cannot set terminal process group (-1): Invalid argument
bash: no job control in this shell
Por favor, dime qué estoy haciendo mal, esto es muy frustrante.
Respuestas:
Estuviste bastante cerca con tu ejemplo. Funciona bien cuando lo usa con argumentos como estos.
Script de muestra:
Ejemplo que funciona:
Pero falla para este tipo de argumentos:
¿Que esta pasando?
El problema con el que te encuentras es que el argumento,
-time
o--time
en mi ejemplo, se está interpretando como un cambio abash -s
. Puede apaciguarlobash
al terminar de tomar cualquiera de los argumentos restantes de la línea de comando para sí mismo utilizando el--
argumento.Me gusta esto:
Ejemplos
# 1:
# 2:
# 3:
# 4:
NOTA: Solo para dejar en claro que donde sea que aparezca la redirección en la línea de comando no hay diferencia, porque de
ssh
todos modos llama a un shell remoto con la concatenación de sus argumentos, las citas no hacen mucha diferencia, excepto cuando necesita hacerlo en el shell remoto como en el ejemplo # 4:fuente
bash -s -- --time bye < ./ex.bash
o incluso< ./ex.bash bash -s -- --time bye
. Esto se debe a que el shell primero toma la instrucción de redireccionamiento (independientemente de dónde esté en el comando), luego configura la redirección, luego ejecuta el resto de la línea de comando con la redirección en su lugar.Sobre el manejo de argumentos arbitrarios
Si realmente solo usa una sola cadena, es decir
-time Aug 18 18
, entonces simplemente puede codificarlo, y las respuestas existentes le indican cómo hacerlo adecuadamente. Por otro lado, si necesita pasar argumentos desconocidos (como un mensaje que se mostrará en el otro sistema o el nombre de un archivo creado donde los usuarios finales podrían controlar su nombre), entonces se necesita más cuidado.Con
bash
oksh
como/bin/sh
Si su control remoto
/bin/sh
es proporcionado por bash o ksh, puede hacer lo siguiente de manera segura con una lista de argumentos no confiables, de modo que incluso los nombres maliciosos (como$(rm -rf $HOME).txt
) se puedan pasar como argumentos de manera segura:Con cualquier POSIX-obediente
/bin/sh
Para estar a salvo de datos de argumentos suficientemente maliciosos (tratando de aprovechar la cita no compatible con POSIX utilizada por
printf %q
in bash cuando hay caracteres no imprimibles en la cadena que se escapa) incluso con un/bin/sh
BASIX-POSIX (comodash
oash
), se pone un poco más interesante:Uso (para cualquiera de los anteriores)
Las funciones dadas anteriormente se pueden invocar como:
...o...
fuente
decir aa es un archivo local que contiene ls
$ssh servername "cat | bash" < a.a
cambie 127.0.0.1 a cualquiera que sea su ip remota
estos dos dan un mensaje sobre la asignación de pseudo tty pero funcionan.
$ cat a.a | ssh 127.0.0.1
$ ssh 127.0.0.1 <a.a
O
$ cat a.a | ssh 127.0.0.1 bash or
$ ssh 127.0.0.1 bash < a.a
fuente