I'm not for this. If you are not sure that the server will provide the filename and you have a query like that I would use --output instead

I agree with @jay. -O is about using the name from the URL as file name as that makes the client side absolutely sure what file name that will be used. Trimming it changes that and opens up a risk for overwriting files that were not meant to overwrite.

If possible, the error message could be clearer.

The error message shown above was shortemed, wasn't it?

The code already uses strerror() which should at least include some clue about the specific reason for the failure. I would presume the errno would be ENAMETOOLONG or something on Linux.

Shortened? Not really, full output:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                             Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
Warning: Failed to create the file 
Warning: test?somelongargumentlistsomelongargumentlistsomelongargumentlistsomel
Warning: ongargumentlistsomelongargumentlistsomelongargumentlistsomelongargumen
Warning: tlistsomelongargumentlistsomelongargumentlistsomelongargumentlistsomel
100  1270  100  1270    0     0   1270      0  0:00:01 --:--:--  0:00:01  3082
curl: (23) Failed writing body (0 != 1270)

error code = 23

I'm using curl as a download tool for custom webkit-based browser (surf).

Option -J is necessary to have proper filenames for downloadable *zip, *pdf, etc. On the other hand I could trim filename by myself (in surf c code), but in such case I loose -J Content-Disposition filename because -o is apparently superior to -J.

So other expected solution would be:

curl -J -o "my-filename" "http://..."

but to make -o "my-filename" work only if Content-Disposition is not in the headers.

Aaah, the warning message itself is truncated as it only uses a 256 bytes buffer so the error message after the file name isn't visible! I'll start out by fixing that... (commit 5d0ba70)

because -o is apparently superior to -J.

Yes, -J only works with -O. I suppose it could be expanded to also work with -o, but that would mean new functionality.

So really, with a >255 bytes long part to the right of the rightmost slash, -O is doomed to fail and there's not a lot we can do about it.

I think curl is doing the right thing here. It tries to use the name as instructed, and when it fails is tells the user why. With the landed fix, it should now display it even with very long file names in the message.