Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

megaglest startscript gives too much output on error #109

Open
titiger opened this issue Jan 29, 2016 · 4 comments
Open

megaglest startscript gives too much output on error #109

titiger opened this issue Jan 29, 2016 · 4 comments

Comments

@titiger
Copy link
Member

@titiger titiger commented Jan 29, 2016

When you start mg via command line the startscript adds useless output to the console.

example:

this is ok:
./megaglest --?

the output form this is not ok:
./start_megaglest --?

You get informations about libraries on error which are pretty useless in this case. I suggest that these infos are not displayed for every abnormal returncode.

@filux
Copy link
Contributor

@filux filux commented Jan 29, 2016

hehe well, every non 0 exit code mean "not ok" :P, so problem begins there where MG's exit code is wrong,
basically I am not sure about --? but for sure after official --help exit code should be 0 (not like now is 2 in both cases),
...
but still thinking/considering possible workaround I have an important question: does exit code = 2 is unique to situation with "wrong parameters" or may it occur also in other situations?

@filux
Copy link
Contributor

@filux filux commented Jan 29, 2016

digging deeper:

  • g3dviewer is always returning exit code 255 also with official --help ... so my previous question is not so important now (different outputs, different exit codes, one script handles this)
  • editor is always returning 0, with every possible (wrong) parameter,
  • I don't see --? documented anywhere

Summing up I am not so sure is it even worth considering to "fix by workaround inside script", because it will be:

  • quite heavy (e.g. echo $output | grep "Commandline Parameter:")
  • quite slow (e.g. save output to file > 'grep' ^ > display output)
  • will take quite many lines (separate conditions for every binary)

... so by now in my opinion enough is that what we have now, namely exceptions for official -h & --help and in the script area we have ~ stage wontfix

@filux filux added wontfix and removed question labels Jan 29, 2016
@titiger
Copy link
Member Author

@titiger titiger commented Jan 31, 2016

I think a simple ldd and grep would help:
ldd <binary> |grep "not found"

So no need to do anything depending on the exitcode of the binary.
( this should really be fixed as it is pretty annoying so I removed the "won't fix" label)

@titiger titiger removed the wontfix label Jan 31, 2016
@filux
Copy link
Contributor

@filux filux commented Jan 31, 2016

nope, by this you will kill debug for situations where script itself found library but incompatible

e.g. as you reported recently situation with 'wx2.8 & missing wx3.0', after proposed by you changes in this situation we don't have any "not found" so debug (in probably hardest to investigate cases) is killed > imo unacceptable :D
... also don't forget about libraries in the 'lib' directory because they also remove "not found" status and also may be incompatible with something

... besides this who cares so much what output will someone get in situation when he used wrong parameter, if someone is using parameters (with --help exception) then it has to mean he is a "advanced user and know what he is doing" so should use correct parameters or should understand the current output and we are talking about maybe 5% users, seriously I don't see any reason to make script much more heavy for 100% users or kill useful debug to satisfy maybe 2% (because not all of them will use wrong parameter ever)

this fix should be really started as fix inside MG (also because there already exist method of detection for this situation [because you see list of all parameters]), just make a unique exit code for "wrong parameter" (perfect situation will be when every MG's binary will use same unique exit code for this situation)
... and then just few additional characters inside script, in 'lightweight' condition will do the rest

@tomreyn tomreyn added the linux label Feb 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants