When a shell script is the handling application for a mimetype, registrar does not propagate arguments to it

[waddlesplash]

I'm currently working on a launcher for Jar files. Everything currently works, except when Registrar launches the script because I double-click on a file in Tracker or use open, it doesn't pass the filename as an argument, even with B_ARGV_ONLY in the app_flags.

The script and RDEF are attached. Set them up with:

chmod +x hjava
rc hjava.rdef
resattr -o hjava hjava.rsrc

(Note that resattr was not included in the build until hrev48852, so prior to that you'll have to compile it yourself.)

[bonefish]

If the script can be registered as an application -- which surprises me a bit, but well ... -- the registrar isn't involved in its execution. The code you're looking for is generally in BRoster::Launch(), but I believe Tracker only gets the handling application from BRoster and does the launching itself.

[waddlesplash]

Ah, makes sense. I did look at BRoster::Launch but I saw no reason why it wouldn't work...

[hamish]

Looking at the BRoster code this seems intentional (and also applies to regular non-BApplication executables, not just scripts). If no additional arguments (argc, argv) are passed to BRoster::Launch() then it won't include the target file path in the argument vector.

It will send the file ref later in a message. It will try to send the message even if the app has the B_ARGV_ONLY flag — which seems to go against the definition given in the Be Book. Is this the BeOS behaviour, or a mistake?

[bonefish]

At least the BRoster::Launch() unit tests for the B_MULTIPLE_LAUNCH | B_ARGV_ONLY cases suggest (​here and ​here) that main() args are actually expected. At a quick glance, the argv cases are exercised by the test methods ​LaunchTester::LaunchTestC3(), ​LaunchTester::LaunchTestF8(), and ​LaunchTester::LaunchTestF9().

The tests were modelled to verify the BeOS R5 behavior and Haiku's app kit classes were written against the tests. It would be interesting to run the tests against the current Haiku.

[hamish]

After some battling with the unit tests it seems that the argv is not expected to contain the file path if no additional args are passed. See ​http://cgit.haiku-os.org/haiku/tree/src/tests/kits/app/broster/LaunchTesterHelper.cpp#n426.

I'm curious if this is indeed the behaviour on BeOS for a B_ARGV_ONLY app, because it seems that a B_ARGV_ONLY app would have no other way to receive the target file in that case.

A few of the tests were also broken because the BMessage::ReturnAddress() of the messages sent to the launch context would refer to the launch context itself. On the test app side, it makes a copy of the RefsReceived message, and this also ends up copying the reply-to address of the message. If the tests pass under BeOS, that would suggest this behaviour is also wrong.

[ttcoder]

Replying to hamish:

It will send the file ref later in a message. It will try to send the message even if the app has the B_ARGV_ONLY flag — which seems to go against the definition given in the Be Book. Is this the BeOS behaviour, or a mistake?

Is that part maybe adressed in hrev49064 ?

[hamish]

Unfortunately not — this concerns the BRoster launching behaviour rather than BApplication's silent-relaunch.

[hamish]

After some testing (thanks to Diver) it seems that this does indeed match the BeOS behaviour.

Is there a strong reason to keep this behaviour? None of our in-tree apps that use B_ARGV_ONLY expect to be launched as the handler of a file -- so they would not be affected by such a change.

[waddlesplash]

Interestingly, it seems that as long as the passed ref is indeed a document, it gets put into argv anyway: ​http://xref.plausible.coop/source/xref/haiku/src/kits/app/Roster.cpp#518 -- ​http://xref.plausible.coop/source/xref/haiku/src/kits/app/Roster.cpp#1893. So I'm not entirely sure what's going on here.

[danboid]

It looks like I've encountered this bug now and its stopping me using mpv as my default video player under Tracker.

​https://github.com/haikuports/haikuports/issues/8626

[nephele]

mpv is a gui application and should not use this flag. It will mark that the application does not accept BMessages and break other functionality like screenshoting.