Add Option to Execute Bash OR Python scripts onstart and onend

corezon

Please add the option to execute runcommand-onstart.sh OR runcommand-onstart.py on start and runcommand-onend.sh OR runcommand-onend.py on end.

herb_fargus

@corezon you can call any script from within the on start or on end bash scripts. No need to explicitly define every possible executable script.

E.g: http://stackoverflow.com/questions/4377109/shell-script-execute-a-python-program-from-within-a-shell-script

corezon

@herb_fargus Yes, I know. However, it's sloppy. Especially when Python comes pre-installed with Raspbian and the change would be miniscule to the runcommand script.

BuZz

@corezon and next someone will ask it to check for Perl, and ruby. It's not sloppy, just execute your python from the bash script.

corezon

@BuZz Having a one line script to execute another script is amazingly sloppy. If you're reluctant to call additional script types directly, how about giving us the option to specify the script that is run?

BuZz

@corezon I'm not going to change it.

meleu

@corezon said in Add Option to Execute Bash OR Python scripts onstart and onend:

how about giving us the option to specify the script that is run?

This option already exists. Just specify the script you want to run in runcommand-onstart.sh (or -onend.sh).

corezon

@meleu Yes. But again, having a one-line script to execute another script is just silly. Where as everyone seems to enjoy finding ways to turn down a new idea in this thread, adding two options to runcommand.cfg would both satisfy the request and open up a ton of new options for those who want to extend their RetroPies.

BuZz

@corezon opens up a ton of new options? No it doesn't. It just pleases you as you don't want to launch it in the way we have suggested. It's a pointless change imho.

suprjami

@corezon said in Add Option to Execute Bash OR Python scripts onstart and onend:

Yes. But again, having a one-line script to execute another script is just silly.

Man you're going to be real upset when you discover how the EmulationStation autostart works.

The kernel doesn't care about executable file extensions. When one of the exec() system calls is made against a file, as long as the file being executed starts with a shebang then the specified interpreter is run.

For example, here is test.sh but it's actually a Python script:

$ cat test.sh 
#!/usr/bin/python
print "hello"

So you can just run it and it works:

$ ./test.sh 
hello

You can see the kernel literally just checks for the presence of # followed by ! then runs whatever it's told to: http://lxr.linux.no/linux+*/fs/binfmt_script.c

So if you really have such a problem launching a bash script to launch your Python script, call your Python script runcommand-onstart.sh/runcommand-onend.sh and make sure it has the Python shebang at the start. Done.

BuZz

@suprjami Although that won't work in this case since we specifically call bash rather than just trying to execute the script. Intentionally done, so nothing breaks when people decide to move their script to a fat32 usb drive and back or mess with the permissions etc (We do the same with other launch scripts as this problem cropped up before when people had their roms folder on fat32).

As you point out when we autostart ES, we launch a bash script, which launches another bash script which launches ES ;-) Then when launching a port, ES launches a bash script which launches runcommand, which launches something. So really it will make no "difference" and as we are not doing it in a loop 10,000 times, there is no reason to change it.

suprjami

@BuZz I hear Leonadro Di Caprio has signed up for a new movie, it is called Inception 2: Linux Bash Scripts ;)

BuZz

I'm not sure which is more worrying.. your sense of humour or my appreciation of it ;-)

meleu

Maybe it's one of those strange Usopp's diseases (from the One Piece manga).

usoppdisease

http://imgur.com/LTRIHTY

meleu

@corezon putting a little better my point of view...
On my joystick-selection tool, when using the joystick selection by name method the tool adds a single line to the runcommand-onstart.sh and the logic is actually done by another shell script. I did this way because I want to let the runcommand-onstart.sh available to the user tweaking.

I have had this experience of receiving some harsh words from the main developer. It's a bit shocking at first, but then we get used to his tough-guy style. :-) You have to provide really useful use cases and be really careful with your words. At least that's the way I've been doing and have achieved some satisfactory results... ;-)

Can you provide one of those new options that would be possible by adding it to runcommand.cfg that can not be achieved by the current method?

BuZz

@meleu I don't think you got any harsh words (tbh I think I was quite polite) from me but perhaps it was because of you of making unnecessary personal remarks about me like the one above.

Not to mention posting a link where to download roms, making demands, and not accepting when I said I didn't want to do something - eg when I didn't accept your offer to document the code. (That's not how it works - you don't get to dictate where the project is going - if you want it to work differently, you can fork it).

Ideas are welcome, and feel free to put your argument across, but if I think something should be done differently, please accept it.

Drakaen391

@corezon not sure you understand how operating systems work....

scripts run off of scripts.... in Ubuntu for example, the startup scripts are actually ran from systemd and its set of scripts....

unless you change the kernal, you will always run a script from a script...

just how operating systems work

corezon

@Drakaen391 Yes, I am aware that scripts can launch scripts and do quite often. The idea of a single line bash script just to execute a python script is pretty silly though.

The matter is closed though. The devs aren't interested in the idea which is their right.