🐛 Open from CLI does not open in background

[mklaber]

I have a lot of issues to go through, so in order to make it easier for me to help you, I ask that you please try these things first

• Try with the newest version from GitHub
• Read the documentation and FAQ, Known issues, Troubleshooting
• Search for your problem under Issues or Discussions
• If you have a problem only with a particular file (or file type), use this form instead
• Windows 7, 8 and 8.1 are no longer supported. This is not a question about Windows 8.1 or older.

Operating System

MacOS 10

Steps to reproduce

1. Open a new Terminal window
2. Open LosslessCut via command line (I suspect the ERRORs are superfluous for this particular issue but including nonetheless):

   $ /Applications/LosslessCut.app/Contents/MacOS/LosslessCut
   [70701:0420/104153.433642:ERROR:trust_store_mac.cc(838)] Error parsing certificate:
   ERROR: Failed parsing extensions
   
   [70701:0420/104153.433710:ERROR:trust_store_mac.cc(838)] Error parsing certificate:
   ERROR: Failed parsing extensions
   
   

3. Observe Terminal is blocked while LosslessCut is open
4. Open a new Terminal window
5. Open LosslessCut via command line:

   $ /Applications/LosslessCut.app/Contents/MacOS/LosslessCut
   
   $ 

6. Observe the existing LosslessCut instance remains open and Terminal allows commands
7. Switch back to the previous Terminal and ctrl + c
8. Observe LosslessCut closes and Terminal allows commands

Note that above is a simplified example. The same behavior occurs in a more typical case like providing a file to open as the first argument.

Expected behavior

I would expect step 3 to actually look like step 6 and return control to the command line. Step 6's observation would put the app in line with other Electron apps' behavior like VS Code.

Actual behavior

The Terminal is blocked.

Share log

No response

[mifi]

You expect the terminal to become interactive again and losslesscut to fork off into the background when you launch it from the command line?

1. Not sure if this is really a bug, because some people might actually want their script to block until losslesscut has exited (if they use losslesscut as part of some scripted workflow). What's your use case for needing it to be forked to the background? And why can't you just use &
2. I don't really know how to fork off an electron app in the background.

[mklaber]

Use case is that I'm using a terminal for moving/copying/downloading additional files and simply want to tell LosslessCut to open one (or more) of the files and carry on with what I'm doing in the terminal.

While using & is a workaround (that isn't entirely intuitive to users), I think the more important point here is that it does work as expected if an existing instance of LosslessCut is running. So... there's code somewhere in the app that's handling it in the way I'd expect. Also note that & still litters the terminal with output from the app and even takes back the terminal when outputting log messages (I typed ls and then when I had control again dir1; most users are going to think that their bash instance is going to try to execute [71816:0420/1127... as I did until I actually tried a command that should work):

mklaber in ~/Code/lossless-cut-fixtures on master [?]
$ /Applications/LosslessCut.app/Contents/MacOS/LosslessCut &
[2] 71816

mklaber in ~/Code/lossless-cut-fixtures on master [?]
$ ls [71816:0420/112757.880039:ERROR:trust_store_mac.cc(838)] Error parsing certificate:
ERROR: Failed parsing extensions

[71816:0420/112757.880124:ERROR:trust_store_mac.cc(838)] Error parsing certificate:
ERROR: Failed parsing extensions

dir1
sample_mpeg4-html5ified-dummy.mkv  sample_mpeg4.mp4

mklaber in ~/Code/lossless-cut-fixtures on master [?]
$ 

I don't think people expecting a script to block is a real use case for a UI app as long as there's no commands that can be executed via the CLI. As currently implemented (or at least documented), the CLI only exists for opening file(s) in the UI. Having said that, if we did want that behavior, it'd probably best be handled by a flag like VS Code's -w or --wait | Wait for the files to be closed before returning.

Adding CLI commands to perform common actions as described in #980 would still be possible; if a command is provided as the first argument, perform it. If not, open the app (yes this gets a bit dicey with "is this a command or is this the name of a file").

[mifi]

I think the more important point here is that it does work as expected if an existing instance of LosslessCut is running.

not sure what you mean by this. how is it not working as expected if an existing instance is running? You can turn on "allow multiple instances" under settings, then it will open multiple instances (one for each command).

Also note that & still litters the terminal with output from the app and even takes back the terminal when outputting log messages

not sure which shell you're using but with bash this is usually solved by redirecting output, e.g. LosslessCut &> /dev/null &

[mifi]

closing this because i think many people don't want this behaviour (and forking programs to the background is typically done by scripting)