jumpcutter: Jumpcutter can't handle inputs with spaces

@abhiTronix That’s a hacky solution. We need to replace shell invocations with pure argument-list ones.

This is actually the correct way to do it: https://github.com/balsoft/jumpcutter/blob/5a5adddd14cf4242cfb54ec26ae6a043f77b202c/jumpcutter.py#L116

@balsoft No its a problem with Unix systems, as they fail to take filename/ foldername with space(s) as input on the terminal. Here’s the more insight into this problem: https://askubuntu.com/questions/516772/how-to-access-files-directories-with-spaces-in-the-name , Your solution will not work on the terminal, and the algorithm will fail before it even starts. Here is an example, try this: python jumpcutter.py --input_file abc/filename with space.mp4 Output: no such file or directory Hope that clears your doubt.

Does --input_file "filename with spaces" not work?

No, it can absolutely work, you just need to handle those string properly with f strings. Here’s the Repo. owner’s comment

I was talking about the way things are implemented currently. It won’t work correctly in the current form unless GUI uses some stupid hacks.

Can you please elaborate on how python does that?

I was oversimplifying, of course. The gist is this: a POSIX-compatible shell, from which the python process is executed, automatically parses the escape sequences and removes them from process arguments. E.g. if you do echo "Hello" you won’t see the quotes around Hello, because the shell removed them. This means that whatever argparse returns as input_file won’t contain quotes either - so it’ll be fiename with spaces, not "filename with spaces". This returned value then gets simply added to a ffmpeg command – so it becomes subprocess.call("ffmpeg -foo filename with spaces", shell=True), and then this shell which should invoke ffmpeg now sees three different arguments (filename, with, spaces) instead of one (filename with spaces). This is why your hack works - according to POSIX, shell shouldn’t parse any escape sequences inside quotes, so the python is invoked with filename\ with\ spaces which then means that ffmpeg is invoked with "ffmpeg -foo filename\ with\ spaces", so now the second shell parses the \ escape sequence three times and sees one argument (filename with spaces). So I was sort of wrong - it’s not python that removes the escape sequences, it’s a shell that calls python. What I suggest is that we ditch the second shell (which calls ffmpeg) because it’s practically unneeded and specify arguments ourselves with subprocess.call(["ffmpeg", "-foo", inputFileName]) so that ffmpeg sees exactly the argument that was passed to python. This fixes the issue.

good, you used “” quotations in --input_file argument, that’s another workaround for special characters like spaces beside escaped space.

In your answer, you’ve used both “workarounds” and because of that the second shell handled the input correctly, whereas for a well-behaved program just one of them should work. So either jumpcutter --input_file filename\ with\ spaces.mp4 or jumpcutter --input_file "filename with spaces.mp4" must work. In current form it doesn’t, with my solution it does.

PS: shell=True is a massive problem if this is going to be used as a CGI script – it allows for remote code execution! E.g. jumpcutter --input_file "test; rm -rf ." would remove all files in current directory.

This is actually the correct way to do it: https://github.com/balsoft/jumpcutter/blob/5a5adddd14cf4242cfb54ec26ae6a043f77b202c/jumpcutter.py#L116