shorten filenames in the middle if needed (linux only)

[Wikinaut]

Before submitting a pull request make sure you have:

• At least skimmed through contributing guidelines including yt-dlp coding conventions
• Searched the bugtracker for similar pull requests
• Checked the code with flake8

In order to be accepted and merged into yt-dlp each piece of code must be in public domain or released under Unlicense. Check one of the following options:

• I am the original author of this code and I am willing to release it under Unlicense
• I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

• Bug fix
• Improvement
• New extractor
• New feature

---

Description of your pull request and other information

fixes #1136 partially

[pukkandan]

This causes filename in the infodict and the one in disk to be different. Any changes to the final filename must happen in YoutubeDL.prepare_filename (You can change the temp filename in download as long as it is deterministic and unique enough to unambigiously resume). Also, the behavior should be consistent b/w OSes

[Wikinaut]

This causes filename in the infodict and the one in disk to be different. Any changes to the final filename must happen in > YoutubeDL.prepare_filename (You can change the temp filename in download as long as it is deterministic and unique enough to unambigiously resume). Also, the behavior should be consistent b/w OSes

I understand the OS-issues. Very difficult for me, to find a solution.
But for downloading Tweets, long filenames were a show-stopper until I supplied this fix.

Should be handled better and improved by experts (I am not).

I will at least fix this as suggested in prepare_filename, anmd I need to understand what infodict means and is.
Perhaps someone can help me to fix it properly?

[pukkandan]

I understand the OS-issues. Very difficult for me, to find a solution.

You can hardcode the limit to 255 for windows. There is also the issue of total path length, but this PR doesn't need to address it

But for downloading Tweets, long filenames were a show-stopper until I supplied this fix.

You can use something like -o "%(title).200B [%(id)s].%(ext)s"

I will at least fix this as suggested in prepare_filename.

The code has other issues as well that I didn't mentioned above. For example, it can't just be applied to basename. It is possible that some path segments in the middle can have long names too

anmd I need to understand what infodict means and is

The information dictionary as returned by -j

[Wikinaut]

I will close my pr for the moment.

[ghost]

can we have the .200B as a default for everything?