curl bails al descargar en cygwin pero no en os x

curl bails al descargar en cygwin pero no en os x

Estoy intentando descargar una copia de una base de datos postgresql de Amazon S3 en cygwin. Pero produce ceros en todos los ámbitos, lo que produce un archivo inútil. Este es mi comando curl:

 curl `heroku.bat pgbackups:url` -o latest.dump --verbose

que produce: * ESTADO: INIT => CONNECT handle 0x60002de60; línea 1011 (conexión #-5000) * El nombre de host NO se encontró en la caché de DNS * Probando 54.231.1.232... * Agregando identificador: conn: 0x600069f80 * Agregando identificador: enviar: 0 * Agregando identificador: recv: 0 * Curl_addHandleToPipeline: longitud: ¡1 * 0x60002de60 está en el cabezal de la tubería de envío! * - Conexión 0 (0x600069f80) send_pipe: 1, recv_pipe: 0 * ESTADO: CONECTAR => WAITCONNECT manejar 0x60002de60; línea 1058 (conexión #0) % Total % recibido % Xferd Velocidad promedio Tiempo Tiempo Tiempo Descarga actual Carga Total gastado Velocidad izquierda 0 0 0 0 0 0 0 0 --:--:-- --:--:-- - -:--:-- 0* Conectado a s3.amazonaws.com (54.231.1.232) puerto 443 (#0) * Configurar correctamente las ubicaciones de verificación de certificados: * CAfile: /usr/ssl/certs/ca-bundle.crt CApath : ninguno * SSLv3, protocolo de enlace TLS, saludo del cliente (1): } [datos no mostrados] * ESTADO: WAITCONNECT => PROTOCONNECT handle 0x60002de60; línea 1171 (conexión #0) * SSLv3, protocolo de enlace TLS, saludo del servidor (2): { [datos no mostrados] * SSLv3, protocolo de enlace TLS, CERT (11): { [datos no mostrados] * SSLv3, protocolo de enlace TLS, servidor terminado (14): { [datos no mostrados] * SSLv3, protocolo de enlace TLS, intercambio de claves del cliente (16): } [datos no mostrados] * SSLv3, cambio de cifrado TLS, saludo del cliente (1): } [datos no mostrados] * SSLv3 , protocolo de enlace TLS, finalizado (20): } [datos no mostrados] * SSLv3, cambio de cifrado TLS, saludo del cliente (1): { [datos no mostrados] * SSLv3, protocolo de enlace TLS, finalizado (20): { [datos no mostrados] ] * Conexión SSL usando AES128-SHA * Certificado de servidor: redactado * Verificación del certificado SSL correcto. * ESTADO: PROTOCONNECT => MANEJAR 0x60002de60; línea 1190 (conexión #0)

OBTENER /hkpgbackups/[correo electrónico protegido]/b007.dump?AWSA redactado User-Agent: curl/7.34.0 Host: s3.amazonaws.com Aceptar:/

 * STATE: DO => DO_DONE handle 0x60002de60; line 1263 (connection #0)
 * STATE: DO_DONE => WAITPERFORM handle 0x60002de60; line 1384 (connection #0)
 * STATE: WAITPERFORM => PERFORM handle 0x60002de60; line 1395 (connection #0)
 * HTTP 1.1 or later with persistent connection, pipelining supported
 < HTTP/1.1 400 Bad Request
 < Transfer-Encoding: chunked
 < Date: Wed, 02 Jul 2014 21:03:39 GMT
 < Connection: close
 * Server AmazonS3 is not blacklisted
 < Server: AmazonS3
 { [data not shown]
 * STATE: PERFORM => DONE handle 0x60002de60; line 1565 (connection #0)
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
 * Closing connection 0

La ejecución de este comando en el terminal OS X desde la misma subred produce prácticamente el mismo resultado, excepto que obtengo un 200 para la solicitud http/1.1.

Entonces, ¿por qué debería obtener 200 para Mac, pero 400 para cygwin en Windows? Intenté eliminar otras variables potenciales, pero cygwin en esta máquina no obtiene un 200. Puedo decirles que la URL redactada en cygwin coincide con la URL en la salida del comando heroku y lo mismo en Mac hasta donde puedo. consulte, excepto la clave de acceso de AWS. ¿No ves por qué serían diferentes?

¿Por qué esto sería diferente?

Como referencia este es mirecurso.

Respuesta1

Esto debería haber funcionado, pero la única forma en que se ejecutaría es omitir la evaluación del comando heroku y simplemente copiar y pegar la salida de la URL Y SOLO si incluyo la URL entre comillas simples.

curl -o último.volcado 'https://example.com/reallyLongAndUglyUrl'

La razón por la que funciona en OS X es porque la salida es muy larga y no se modifica. Pero se bloquea en cygwin porque estoy usando el comando heroku.bat para obtener el resultado. Eso impone restricciones de Windows, es decir, agrega un retorno de carro, etc. a la línea muy larga que divide la URL. La otra pista es que curl devuelve un error 400 que indica una URL modificada. La solución es canalizar la salida al programa dos2unix y curl responde como debería.

curl -o last.dump heroku.bat pgbackups:url | dos2unixy reina la felicidad.

información relacionada